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

lib, zebra: Ensure route encoding has enough space #4435

Merged
merged 1 commit into from
May 31, 2019

Conversation

donaldsharp
Copy link
Member

When you have compiled FRR with a large multipath number
then encoding large ecmp routes between zebra and the
routing daemons. There exists a theoritical size
of multipath that will cause the encoding to be larger
than the ZEBRA_MAX_PACKET_SIZ. In the cases where
we have allocated streams that will encode routes
then let's ensure that whatever size we have will
auto-fit what we say we can send.

Signed-off-by: Donald Sharp sharpd@cumulusnetworks.com

@donaldsharp
Copy link
Member Author

I'm going to put this into 6 and 7 and 7.1 dev once approved

@donaldsharp donaldsharp force-pushed the zclient_buffer_sizing branch from 7c1e168 to d215f62 Compare May 31, 2019 13:49
@LabN-CI
Copy link
Collaborator

LabN-CI commented May 31, 2019

💚 Basic BGPD CI results: SUCCESS, 0 tests failed

Results table
_ _
Result SUCCESS git merge/4435 7c1e168
Date 05/31/2019
Start 09:52:24
Finish 10:15:12
Run-Time 22:48
Total 1813
Pass 1813
Fail 0
Valgrind-Errors 0
Valgrind-Loss 0
Details vncregress-2019-05-31-09:52:24.txt
Log autoscript-2019-05-31-09:53:40.log.bz2
Memory 427 434 360

For details, please contact louberger

When you have compiled FRR with a large multipath number
then encoding large ecmp routes between zebra and the
routing daemons.  There exists a theoritical size
of multipath that will cause the encoding to be larger
than the ZEBRA_MAX_PACKET_SIZ.  In the cases where
we have allocated streams that will encode routes
then let's ensure that whatever size we have will
auto-fit what we say we can send.

Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
@donaldsharp donaldsharp force-pushed the zclient_buffer_sizing branch from d215f62 to f3f4562 Compare May 31, 2019 14:25
@FRRouting FRRouting deleted a comment from NetDEF-CI May 31, 2019
@FRRouting FRRouting deleted a comment from NetDEF-CI May 31, 2019
@LabN-CI
Copy link
Collaborator

LabN-CI commented May 31, 2019

💚 Basic BGPD CI results: SUCCESS, 0 tests failed

Results table
_ _
Result SUCCESS git merge/4435 f3f4562
Date 05/31/2019
Start 11:07:00
Finish 11:29:42
Run-Time 22:42
Total 1813
Pass 1813
Fail 0
Valgrind-Errors 0
Valgrind-Loss 0
Details vncregress-2019-05-31-11:07:00.txt
Log autoscript-2019-05-31-11:08:07.log.bz2
Memory 435 433 360

For details, please contact louberger

@NetDEF-CI
Copy link
Collaborator

Continuous Integration Result: SUCCESSFUL

Congratulations, this patch passed basic tests

Tested-by: NetDEF / OpenSourceRouting.org CI System

CI System Testrun URL: https://ci1.netdef.org/browse/FRR-FRRPULLREQ-7904/

This is a comment from an automated CI system.
For questions and feedback in regards to this CI system, please feel free to email
Martin Winter - mwinter (at) opensourcerouting.org.


CLANG Static Analyzer Summary

  • Github Pull Request 4435, comparing to Git base SHA 4cc1365

No Changes in Static Analysis warnings compared to base

11 Static Analyzer issues remaining.

See details at
https://ci1.netdef.org/browse/FRR-FRRPULLREQ-7904/artifact/shared/static_analysis/index.html

Copy link
Contributor

@mjstapp mjstapp left a comment

Choose a reason for hiding this comment

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

good catch ...
but I'm a bit concerned about having to repeat the correct comparison/max expression. couldn't you do something like:

#define ZEBRA_MAX_PACKET_SIZ MAX(16384U, sizeof(struct zapi_route))

that'd put the operation in just one place?

@donaldsharp
Copy link
Member Author

so for a long time I've been ruminating about revamping the stream allocation sizes across the board. Which is why I tried to point fix this as much as possible. This is especially true when we have a bunch of data to pass back and forth between daemons. We have poorly sized buffers and we end up with a large amount of memory allocated and stored waiting to be sent.

@mjstapp
Copy link
Contributor

mjstapp commented May 31, 2019

so for a long time I've been ruminating about revamping the stream allocation sizes [...]

I'm fine with the change - just wanted to ask the question

Copy link
Contributor

@mjstapp mjstapp left a comment

Choose a reason for hiding this comment

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

Approving, understand the issue better now!

@mjstapp mjstapp merged commit 32e4ce5 into FRRouting:master May 31, 2019
@donaldsharp donaldsharp deleted the zclient_buffer_sizing branch December 9, 2019 16:46
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.

5 participants