Re: Problems managing NBUF DATA pool in the networking stack
Geoff Thorpe <geoff.thorpe@...>
While I don't personally have answers to these buffer-management questions, I am certain they are well-studied, because they are intermingled with lots of other well-studied questions and use-cases that influence buffer handling, like flow-control, QoS, order-restoration, order-preservation, bridging, forwarding, tunneling, VLANs, and so on. If I recall, the "obvious solutions" usually aren't - i.e. they're either not obvious or not (general) solutions. The buffer-handling change to remediate one problematic use-case usually causes some other equally valid use-case to degenerate.toggle quoted messageShow quoted text
I guess I'm just saying that we should find prior art and best practice, rather than trying to derive it from first principles and experimentation.
Do we already have in our midst anyone who has familiarity with NPUs, OpenDataPlane, etc? If not, I can put out some feelers.
From: email@example.com [mailto:firstname.lastname@example.org] On Behalf Of Jukka Rissanen
Sent: February-14-17 8:46 AM
To: Piotr Mieńkowski <email@example.com>; firstname.lastname@example.org
Subject: Re: [Zephyr-devel] Problems managing NBUF DATA pool in the networking stack
On Tue, 2017-02-14 at 02:26 +0100, Piotr Mieńkowski wrote:
Hi,I agree that having too fine grained setup for the buffers is bad andSo, what should be the final solution to the NBUF DATA issue? Do weIf you read the entire email it would be clearer that I did notWhile I agree we should prevent the remote to consume all theIndeed the echo server could perhaps be optimized not to deep
should be avoided. The current setup of RX, TX and shared DATA buffers
has worked for UDP quite well. For TCP the situation gets much more
difficult as TCP might hold the nbuf for a while until an ack is
received for those pending packets. TCP code should not affect the
other part of the IP stack and starve the buffers from other part of
One option is to have a separate pool for TCP data nbuf's that could be
shared by all the TCP contexts. The TCP code could allocate all the
buffers that need to wait ack from this pool instead of global data
pool. This would avoid allocating a separate pool for each context
which is sub-optimal for memory consumption.
Zephyr-devel mailing list