[dpdk-dev] segmented recv ixgbevf
laswell at infiniteio.com
Wed Nov 5 15:48:50 CET 2014
I ran into the same issue that Alex is describing here, and I wanted to
expand just a little bit on his comments, as the documentation isn't very
Per the documentation, the two arguments to rte_pktmbuf_pool_init() are a
pointer to the memory pool that contains the newly-allocated mbufs and an
opaque pointer. The docs are pretty vague about what the opaque pointer
should point to or what it's contents mean; all of the examples I looked at
just pass a NULL pointer. The docs for this function describe the opaque
pointer this way:
"A pointer that can be used by the user to retrieve useful information for
mbuf initialization. This pointer comes from the init_arg parameter of
This is a little bit misleading. Under the covers, rte_pktmbuf_pool_init()
doesn't threat the opaque pointer as a pointer at all. Rather, it just
converts it to a uint16_t which contains the desired mbuf size. If it
receives 0 (in other words, if you passed in a NULL pointer), it will use
2048 bytes + RTE_PKTMBUF_HEADROOM. Hence, incoming jumbo frames will be
segmented into 2K chunks.
Any chance we could get an improvement to the documentation about this
parameter? It seems as though the opaque pointer isn't a pointer and
probably shouldn't be opaque.
Hope this helps the next person who comes across this behavior.
infinite io, inc.
On Thu, Oct 30, 2014 at 7:48 AM, Alex Markuze <alex at weka.io> wrote:
> For posterity.
> 1.When using MTU larger then 2K its advised to provide the value
> to rte_pktmbuf_pool_init.
> 2.ixgbevf rounds down the ("MBUF size" - RTE_PKTMBUF_HEADROOM) to the
> nearest 1K multiple when deciding on the receiving capabilities [buffer
> size]of the Buffers in the pool.
> The function SRRCTL register, is considered here for some reason?
More information about the dev