[riot-notifications] [RIOT-OS/RIOT] WIP: sys/net/gnrc/netif: make use of confirm_send (#15821)
notifications at github.com
Thu Jan 21 12:22:49 CET 2021
> I'm afraid these might introduce a regression in some cases. For IEEE 802.15.4 for instance, this could easily take 50~70 ms in some configurations (long frames=~4ms ToA plus IFS, CSMA-CA backoff is 20 symbols = 320 us and the backoff exponent can be 7 => up to 2^7*320us = up to 40ms, several retransmissions).
> This would affect the upper layers trying to fetch information for the interfaces and any existing MAC layer that requires some housekeeping (GoMACH, lwmac, gnrc_lorawan and the [upcoming IEEE 802.15.4 MAC](https://github.com/RIOT-OS/RIOT/issues/15313)).
I see. I think we have the following options here:
1. If any only if `gnrc_netif_pktq` is used, fetch IPC messages also during TX. During TX, send requests will be queued up, rather than being processed. Some network devices will then hard depend on `gnrc_netit_pktq`. Without pktq, IPC messages will not be received during TX.
2. Adapt the upper layers to not generate send requests while TX is still ongoing. I have started some preliminary work in this direction with https://github.com/RIOT-OS/RIOT/pull/15694 - but this PR only blocks at the very top (the SOCK API), so any user directly interacting with GNRC would not sync at all. So that (still WIP PR) is only a step in that direction, not the full solution.
3. Fetch msgs during TX, but re-enqueue send requests (by sending these msgs to one self). Once a single send request enters the message queue, this will become a busy waiting loop :-/
4. Fetch msgs during TX, but drop send requests. This would break L2 fragmentation, as all but the first fragment would be dropped. I'd say we can rule this one out.
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...
More information about the notifications