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

zebra: Only notify dplane work pthread when needed #17062

Open
wants to merge 3 commits into
base: master
Choose a base branch
from

Conversation

donaldsharp
Copy link
Member

The fpm_nl_process function was getting the count
of the total number of ctx's processed. This leads to after having processed 1 context to always signal the dataplane that there is work to do. Change the code to only notify the dplane worker when a context was actually added to the outgoing context queue.

@@ -1512,8 +1514,12 @@ static void fpm_process_queue(struct event *t)

/* Re-schedule if we ran out of buffer space */
if (no_bufs) {
event_add_event(fnc->fthread->master, fpm_process_queue, fnc, 0,
&fnc->t_dequeue);
if (wrote_data)
Copy link
Member

Choose a reason for hiding this comment

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

Isn't enough to rely on processed_contexts instead of this additional wrote_data variable?

Copy link
Member Author

Choose a reason for hiding this comment

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

yeah I'll do that

The fpm_nl_process function was getting the count
of the total number of ctx's processed.  This leads
to after having processed 1 context to always signal
the dataplane that there is work to do.  Change the
code to only notify the dplane worker when a context
was actually added to the outgoing context queue.

Signed-off-by: Donald Sharp <sharpd@nvidia.com>
When the fpm_process_queue has run out of space
but has written to the fpm output buffer, schedule
it to wake up immediately, as that the write will go out
pretty much immediately, since it was scheduled first.
If the fpm_process_queue has not written to the output
buffer then delay the processing by 10 milliseconds to
allow a possibly backed up write processing to have a
chance to complete it's work.

Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Currently the max message size is 4k.  With a 256 way
ecmp FRR is seeing message sizes that are in the
6k size.  There is desire to allow this to increase as
well to 512.  Since the multipath size directly effects
how big the message may be when sending the routes ecmp
let's give a bit of headroom for this value when compiling
FRR at greater sizes.  Additionally since we know not everyone
is using such large ecmp, allow them to build as appropriate
for their use cases.

Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants