https://bugs.linaro.org/show_bug.cgi?id=2151
Bug ID: 2151
Summary: Packet pool runs out of blocks for irregular traffic
patterns
Product: OpenDataPlane - linux- generic reference
Version: 1.8
Hardware: All
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: Buffers & Packets
Assignee: bill.fischo...@linaro.org
Reporter: or...@starflownetworks.com
CC: lng-odp@lists.linaro.org
Created attachment 495
--> https://bugs.linaro.org/attachment.cgi?id=495&action=edit
Pool block patch (1.6)
I will attempt to describe the bug based on my observations of the buffer
allocator.
The current packet pool (versions 1.8 and older) is based on buffers and blocks
(groups of buffers for oversized packets). It also has a cache mechanism to
optimize the recycling of buffers on the same CPU.
When initialized, the pool will list all the possible buffers and blocks in two
linked lists. If the number of free buffers is low (as defined by the "low
buffer watermark", which is 25%), instead of recycling the buffers
(ret_local_buf()), the pool will start to properly free the resources
(ret_buf()).
For blocks of buffers, the difference is that the "fast path" frees the buffer
objects, but not the block objects, while the slow path properly frees the
buffer AND the block objects.
In a typical pool configuration, buffers may have the same size as blocks
(seg_len and len, respectively), leading to an equal number of available buffer
and block objects. An irregular traffic pattern, which interleaves oversized
packets with regular packets, will force the consumption of block resources
faster than buffer resources. Before the low buffer watermark is reached (which
would enable recycling blocks as well), the pool may run out of block
resources, blocking the pool.
To reproduce this behavior:
1. Define a packet pool with the same buffer and block lengths. The size of the
pool does not matter (I tried 4 MB and 64 MB, same behavior).
2. Inject TCP traffic with periodical oversized packets. For instance, 30% of
packets > 1500 bytes.
Actual Results:
The block count of the pool will decrease faster than the buffer count,
reaching 0 before the low buffer watermark has been asserted. At this point,
the pool will not be able to provide free blocks, and new packets will be
dropped.
Expected Results:
The pool should have started freeing block resources before it reached zero,
not blocking.
Additional Information:
I provide a patch for the pool, with a watermark mechanism for blocks. As with
buffers, it will start using the slow "buffer free" path when blocks reach the
low watermark (25% of blocks) until it reaches the high watermark (75%).
This patch is for ODP 1.6, but works for 1.7, 1.8 and newer.
--
You are receiving this mail because:
You are on the CC list for the bug._______________________________________________
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp
