[riot-notifications] [RIOT-OS/RIOT] sys/net/gnrc/netif: make use of confirm_send (#15821)

José Alamos notifications at github.com
Fri Jan 29 11:45:59 CET 2021

> Maybe it is worth pointing out that gnrc_tx_sync blocks the thread at the SOCK API during transmission - which IMO is how it should be in the first place, as e.g. sock_udp_send() is expected to return an error on transmission failures. Obviously, this is difficult to comply with without actually waiting for the TX to fail or complete. What gnrc_tx_sync provides is a mechanism that allows to synchronize with TX, but which is fully optional and can be used on a per-packet basis. (E.g. the ping6 shell command is not using the SOCK API and is currently bypassing the synchronization.)


> With the current implementation, there is one exception to that, though: When 6LoWPAN fragmentation is used, the 6LoWPAN thread additionally blocks during the transmission of each fragment. This is however an implementation detail. It would be possible to just issue all fragments (almost) instantly as is currently done, and just strip the tx_sync info from the IPv6 packet and attach it to last fragment instead. This way again only the SOCK API would block, not the 6LoWPAN thread.

That would be ideal. As described above, this could be handled with a queue or with a signal mechanism from the MAC layer.

> Still, IMO blocking the 6LoWPAN thread during TX of a fragment is the best of all options currently implemented to not overwhelm the transceiver. So IMO we should keep it like this, until a better approach is translated to code. Also: Is there really anything that the 6LoWPAN thread is expected to do during TX? I'd assume the MAC is running in a different context.

But what happens if you have more than one IEEE 802.15.4 radio? (e.g the common use case of having a SubGHz radio for star topology and a 2.4 GHz radio for management/firmware update). How would this be handled?
I agree these stuff are implementation details, but I'm afraid blocking the 6LowPAN thread would degrade the performance when having multiple interfaces.

Can't we try to add a signal from the MAC layer? (msg, semaphore, event_loop or something). This way we could still "block" for a given network interface but the others are still responsive

You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.riot-os.org/pipermail/notifications/attachments/20210129/ed14da3d/attachment.htm>

More information about the notifications mailing list