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

José Alamos notifications at github.com
Thu Jan 28 11:10:56 CET 2021


> #15694 is now seemingly working (at least the test passes) for 6LoWPAN fragmentation (without selective fragment recovery, as of now). I believe that gnrc_tx_sync has lower resource requirements than gnrc_pktq. I believe both should be able to allow fragmentation to continue to work with a non-blocking send() function.

Just a side note here:
Although this is true for certain scenarios (simple CSMA-CA senders like `gnrc_netif_ieee802154`), note that most MAC layers can be in a huge order of magnitude slower than the network stack (e.g TSCH) or might have priority mechanisms (standard IEEE 802.15.4 with GTS, DSME, etc).

I agree that we save resources as it is now, but these 2 modules are not interchangeable. We will need queues for the latter anyway.

> My point is: We need a mechanism like gnrc_tx_sync to issue fragments one at a time anyway for reliable use of fragmentation. So I don't see much of an issue with making that a hard dependency when using non-blocking send.

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.

IMO this problem is there because 6LowPAN is trying to push messages to a bottle neck. I think it's fine to block at sock level, but I don't think smashing the MAC layers is sustainable (when TSCH is there, we would expect higher latencies). This would be solved if the MAC layer is able to pull frames from 6LowPAN. We can skip the queues if 6LowPAN has a signal mechanism to indicate the MAC layer finished (for IEEE 802.15.4 this would be MCPS-DATA.indication).

-- 
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-768945843
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.riot-os.org/pipermail/notifications/attachments/20210128/1890fb07/attachment.htm>


More information about the notifications mailing list