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

Marian Buschsieweke notifications at github.com
Fri Jan 29 10:12:48 CET 2021


> Note that we have several radios that are non blocking by nature (e.g LoRa radios, where packets can easily spend 2 seconds on air). I'm not sure if it's the right way to go to force blocking the thread for a couple of seconds by default.

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.

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.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/RIOT-OS/RIOT/pull/15821#issuecomment-769680086
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.riot-os.org/pipermail/notifications/attachments/20210129/9c62de01/attachment-0001.htm>


More information about the notifications mailing list