Skip to content

update 2022 dplane incoming events description. #8

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.

Sign up for GitHub

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

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

update 2022 dplane incoming events description. #8

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 2 additions & 2 deletions year-2022/projects/dplane-pthread-listener.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -22,9 +22,9 @@ skills:
### Details
350hrs project - Medium Difficulty

In FRR we interact with the linux kernel through 2 different pthreads in zebra (main and dplane). For the dplane pthread, we have spent a lot of time moving most of our route/neighbors/etc. installs into this pthread via context object "snapshots" we take of the object we want to install into the kernel. We take a route or other object we want to install/update and create a context object for it to be passed to our dplane pthread and installed. This goes through to be handled by our dplane specific code (`zebra/rt_netlink` for linux as an example). Moving our kernel installs to a separate pthread has proven to significantly improve our processing time since it alleviates zebra's main thread to continue handling other things like messages from our protocols.
In FRR we interact with the linux kernel through 2 different pthreads in zebra (main and dplane). For the dplane pthread, we have spent a lot of time moving most of our route/neighbors/etc. installs into this pthread via context object "snapshots" we take of the object we want to install into the kernel. We take a route or other object we want to install/update and create a context object for it to be passed to our dplane pthread and installed. This goes through to be handled by our dplane specific code (`zebra/rt_netlink` for linux as an example). Moving our kernel installs to a separate pthread has proven to significantly improve our processing time since it allows zebra's main thread to continue handling other things like messages from our protocol daemons.

However, all of our incoming messages from our netlink listening socket (`zns->netlink`) still happen on the main pthread. This netlink socket listens for notifications from the kernel about events external to FRR (interface link downs/ups and others). These are events we did not initiate but have to handle in FRR by updating our internal state and responding however appropriate.
However, many of our incoming messages from our netlink listening socket (`zns->netlink`) still happen on the main pthread. This netlink socket listens for notifications from the kernel about events external to FRR (interface link downs/ups and others). These are events we did not initiate but have to handle in FRR by updating our internal state and responding however appropriate. We've taken the first steps towards migrating the handling of these messages to the dplane pthread.

For this project, you will be moving all of the netlink listening to be handled in the dplane pthread. In zebra we have an abstracted API for all dataplanes (linux, bsd, others) in `zebra/zebra_dplane.c` Your code should be tightly integrated with that. You will need to modify the code to take an update and turn it into a context object that can be passed onto the main pthread to be eventually handled. It will be architectured very similar to how we communicate INTO the kernel and should re-use some common code where applicable.

Expand Down