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

Marian Buschsieweke notifications at github.com
Thu Jan 21 14:44:31 CET 2021

> > As a result, IRQs are no longer been lost. Hence, it provides the feature gnrc_netif_events provides, but with less ROM. Consequently, gnrc_netif_events is dropped
> BTW, there are some MAC layers that get some benefits when using such a mechanism.

Sure. But the IRQ should remain at higher priority, as e.g. some radios have an RX/TX FIFO that is smaller than the maximum length of the PDU. Hence, an ISR needs to feed into the TX FIFO while sending, or drain the RX FIFO while receiving - this has very strict time requirements.

Hence, the current implementation cannot be used to also hook in MAC events. Since recently, we [do have priority support](https://api.riot-os.org/group__sys__event.html#gaf549606f1a9059f0b1b0cef87ca6a95b) in the event queue mechanism by providing one event queue per priority. But IMO we should for now just go with `core/thread_flags` until a second user becomes ready.

Generally speaking, unless all use of `core/msg` would be replaced by `sys/event` in the network interface, we need to `core/thread_flags` anyway - this is the only mechanism that can wait for both messages and events. So there is (for now) no RAM/ROM penalty in just also using this `core/thread_flags` directly for signaling IRQs or TX_DONE and the like events. So it might turn out that even when other users of `sys/event` in the network interface pop up, keeping `core/thread_flags` remains the lowest overhead option for ISRs and low level "events" like signaling TX_DONE.

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/20210121/a5f8df39/attachment-0001.htm>

More information about the notifications mailing list