Bluetooth: Mesh: Add support prioritized message relay #52072
Conversation
PavelVPV
left a comment
PavelVPV
left a comment
There was a problem hiding this comment.
This change broke 3 bsim tests
zephyrbot
requested review from
Thalley,
alwa-nordic,
asbjornsabo,
hermabe,
jori-nordic and
sjanc
LingaoM
force-pushed
the
enhance_bt_mesh
branch
2 times, most recently
from
0e5133c to
5ec0211
Compare
LingaoM
force-pushed
the
enhance_bt_mesh
branch
8 times, most recently
from
49bd1e6 to
e5beea0
Compare
@PavelVPV All tests passed, Please take a look. |
LingaoM
force-pushed
the
enhance_bt_mesh
branch
3 times, most recently
from
86bbf32 to
1f013cc
Compare
|
@PavelVPV @alxelax @omkar3141 Please take a look, thanks. |
Apologize for the delay. I'm a bit busy right now with some other stuff. I remember about this PR. I'll try to look at it next week. Thanks! |
PavelVPV
left a comment
PavelVPV
left a comment
There was a problem hiding this comment.
One thing that we missed and found recently. Using multiple adv sets it is not guaranteed that the messages will be sent in the order they pushed to the adv sets. So even if we change order in the relay buffer, the messages can (and most likely will) be sent to the air in a wrong order.
subsys/bluetooth/mesh/net.c
Outdated
There was a problem hiding this comment.
I still not convinced with using main adv buffer for relaying messages over proxy. My concern is the same as explained in the first message in this thread.
Maybe a compromise would be to use a separate buffer for messages that should be relayed over Proxy. But we need to investigate the consequences of this approach. And this is actually may not be a bad approach because adv relay bearer works faster than proxy. So a node will be able to keep the relay performance over adv bearer. On the other hand, we won't be able to control order of the messages sent over proxy. Maybe there are more things to consider.
This reordering may not be a problem on ZLL when num_events = 1, but it happens with SDC in some mesh configurations. |
Sure, the multiple advertising sets may schedule advertising events at link layers and not control by mesh layer, so it will happens, but I'm think not important. |
Add support foreach queue nodes. Signed-off-by: Lingao Meng <menglingao@xiaomi.com>
Since net_buf api not support insert operation, also for save some ram footprint, use memslab may be suitable. Signed-off-by: Lingao Meng <menglingao@xiaomi.com>
Reconstruct relay logic, Since Mesh Profile defines many types of Relays, including Proxy and Friend, the previous Zephyr implementations are confused, which is very annoying, so refactoring. Signed-off-by: Lingao Meng <menglingao@xiaomi.com>
In our use scenario, the gateway needs to control a large number of light bulbs in real time, which can exceed 100, and a large number of light bulbs will return the status to the user every time the status changes, which will cause a temporary mesh network storm in the whole network. We optimized the time of status return, which does not happen immediately, but will return the status for a random number of seconds, but during the status return, Each status message may be relayed by all nodes in the entire network. If the gateway sends a new control message at this time, the message obviously needs to be queued, resulting in poor consistency of the entire network control. The prioritized relay messages will be send before other lower priority relay message to ensure that higher priority messages can be sent in time. When considering the message latency, also consider the values of BT_MESH_RELAY_RETRANSMIT_COUNT and BT_MESH_RELAY_RETRANSMIT_INTERVAL. A higher number of BT_MESH_RELAY_ADV_SETS allows the increase in the number of buffers while maintaining the latency. Note: To enable this option, the application layer needs to register a callback function to determine the priority of each relay message. If it is not registered, the default priority is the same as the lowest. Signed-off-by: Lingao Meng <menglingao@xiaomi.com>
Add init support for priority relay. Signed-off-by: Lingao Meng <menglingao@xiaomi.com>
`struct bt_mesh_adv` is more like about adv metadata and could ideally be renamed to `bt_mesh_adv_meta`. `struct bt_mesh_buf` could be renamed to `bt_mesh_adv` as it keeps adv plus metadata Signed-off-by: Lingao Meng <menglingao@xiaomi.com>
LingaoM
force-pushed
the
enhance_bt_mesh
branch
from
1f013cc to
6c3e7eb
Compare
PavelVPV
left a comment
PavelVPV
left a comment
There was a problem hiding this comment.
This change was discussed again within our team. As it was pointed earlier (#52072 (comment)) we still tend to think that we don't want to have the priorisation code in the upstream as is as it is not a Bluetooth mesh specification feature. But (as it was also pointed earlier) we are agree to have a hook in the advertiser bearer to pass the relay buffer to a user application and let the user reorder messages as they want. This will also allow to make the reordering more flexible (not just by priorities). And it seems to me this suggestion is not far from your current implementation.
The proxy issue (#52072 (comment)) is still a problem and needs to be fixed. We should not use the main adv buffer for relaying messages over proxy.
|
In our recent testing, the ability to prioritize relay significantly improved the control experience for devices that do not support extended advertising, although this PR closed. Link another PR(separate local queue & relay queue for legacy adv) :#65043 |
7 participants
For Mesh Message, should only process by model layer when dst is unicast address of this nodes or model subscrip on.
The prioritized relay messages will be send before other lower
priority relay message to ensure that higher priority messages
can be sent in time. When considering the message latency, also
consider the values of BT_MESH_RELAY_RETRANSMIT_COUNT and
BT_MESH_RELAY_RETRANSMIT_INTERVAL.
A higher number of BT_MESH_RELAY_ADV_SETS allows the increase in
the number of buffers while maintaining the latency.
Note: To enable this option, the application layer needs to register
a callback function to determine the priority of each relay message.
If it is not registered, the default priority is the same as the lowest.
Signed-off-by: Lingao Meng menglingao@xiaomi.com