Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

gnrc_netif: Add support for internal event loop #9326

Closed

Conversation

jnohlgard
Copy link
Member

@jnohlgard jnohlgard commented Jun 11, 2018

Contribution description

Enabled by the gnrc_netif_events pseudo module. Using an internal event loop eliminates the risk of lost interrupts and lets ISR events always be handled before any send/receive requests from other threads are processed.
The events in the event loop is also a potential hook for MAC layers and other link layer modules which may need a way to inject and process events before any external IPC messages are handled.

Issues/PRs references

@jnohlgard jnohlgard added Area: network Area: Networking Type: new feature The issue requests / The PR implemements a new feature for RIOT GNRC CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR labels Jun 11, 2018
@jnohlgard jnohlgard added this to the Release 2018.07 milestone Jun 11, 2018
@jnohlgard jnohlgard requested a review from miri64 June 11, 2018 14:15
Copy link
Member

@miri64 miri64 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The main conceptual question I have, is why you are under the impression that messages are ordered and synchronous and events are none of those.

@jnohlgard
Copy link
Member Author

@miri64 Perhaps a bad choice of words. The idea is to make sure that ISRs will always be executed before any queued external requests (send/recv/get/set). In the future, it will also be useful to be able to insert other implementation specific events which can be handled first just like the ISR event, for example turning on the radio when it is time for a wake period in a duty cycling MAC, or handling timeouts and other exceptional events.

@jnohlgard
Copy link
Member Author

There's also the concept that there should only ever be a need for exactly one queued ISR event in the event loop, since the radio driver should probably take care of everything that has to be done in one go and the duplicated ISR events will just be no-ops, whereas there may be several queued send events with different data.

@jnohlgard jnohlgard force-pushed the pr/gnrc_netif_async_events branch from 1dfdad0 to db4c8ce Compare June 30, 2018 14:09
@jnohlgard jnohlgard changed the title gnrc_netif: Add support for asynchronous events gnrc_netif: Add support for internal event loop Jun 30, 2018
Copy link
Member Author

@jnohlgard jnohlgard left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@miri64 addressed comments, rebased

Copy link
Member

@miri64 miri64 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@gebart do you have something prepared to test this?

@jnohlgard
Copy link
Member Author

@miri64 rebased, refactored to address comment.
Testing:
Add USEMODULE += gnrc_netif_events to the makefile. I have added a test commit for this change in the gnrc_networking example.

@jnohlgard
Copy link
Member Author

@miri64 The ContikiMAC implementation requires this event loop to be able to schedule waking periods and retransmissions properly, using the message queue would let applications interfere with the timing of wake periods and retransmissions, or we would have to perform tasks from within interrupt context to preempt the normal flow of the thread.

@cladmi cladmi added CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR and removed CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR labels Aug 24, 2018
@miri64
Copy link
Member

miri64 commented Aug 24, 2018

I think apart from the ifdef issue pointed out above, I think I'm alright with this, but I need to see when the diff is better trackable.

@jnohlgard
Copy link
Member Author

@miri64 new version pushed. The block you mentioned was rewritten into a separate function, also the behaviour was slightly altered to let the thread check for events between each successive IPC message, even when more than one msg have been queued. This should make the behaviour more predictable and robust. Events are always processed as soon as possible, and any events which occur as a side effect of one of the processed messages will be handled before the next message is processed.

@miri64
Copy link
Member

miri64 commented Aug 24, 2018

Ok, finally before I give my ACK, some doc on the new behavior would be nice (also mention that events take precedence over messages and ISR events are handled as a event)... I don't know exactly this should go though :-/. Maybe in a newly introduced details section in net/gnrc/netif.h?

@jnohlgard jnohlgard force-pushed the pr/gnrc_netif_async_events branch from ef37898 to 7e873e3 Compare August 25, 2018 13:50
@jnohlgard jnohlgard force-pushed the pr/gnrc_netif_async_events branch from 2338476 to 4462fd5 Compare September 12, 2018 14:37
Joakim Nohlgård added 6 commits December 1, 2018 14:08
Enabled by the gnrc_netif_events pseudo module. Using an internal event
loop within the gnrc_netif thread eliminates the risk of lost interrupts
and lets ISR events always be handled before any send/receive requests
from other threads are processed.
The events in the event loop is also a potential hook for MAC layers and
other link layer modules which may need to inject and process events
before any external IPC messages are handled.
@jnohlgard jnohlgard force-pushed the pr/gnrc_netif_async_events branch from 44c1fc2 to 39a29bb Compare December 1, 2018 13:08
@miri64
Copy link
Member

miri64 commented Jan 28, 2019

If this PR is rebased (and squashed) and #9326 (comment) is addressed optionally, I think we can finally merge this (sorry dropped off my radar again >.<)

@miri64
Copy link
Member

miri64 commented Feb 16, 2019

@gebart ping?

@miri64
Copy link
Member

miri64 commented Mar 21, 2019

Ping @gebart?

/* dispatch netdev, MAC and gnrc_netapi messages */
DEBUG("gnrc_netif: message %u\n", (unsigned)msg.type);
switch (msg.type) {
case NETDEV_MSG_TYPE_EVENT:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe this case can be #ifndef'd

@jia200x
Copy link
Member

jia200x commented Sep 30, 2019

@gebart this is indeed an interesting feature! Thanks

Since there's no activity for some time, mind if I take it?

@stale
Copy link

stale bot commented Apr 10, 2020

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you want me to ignore this issue, please mark it with the "State: don't stale" label. Thank you for your contributions.

@stale stale bot added the State: stale State: The issue / PR has no activity for >185 days label Apr 10, 2020
@miri64
Copy link
Member

miri64 commented Apr 14, 2020

Adopted by @bergzand in #13669.

@miri64 miri64 closed this Apr 14, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area: network Area: Networking CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR State: stale State: The issue / PR has no activity for >185 days Type: new feature The issue requests / The PR implemements a new feature for RIOT
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants