Hey Folks, 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 clear.
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 rte_mempool_create() <http://www.dpdk.org/doc/api/rte__mempool_8h.html#a7dc1d01a45144e3203c36d1800cb8f17> ." 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. -- Matt Laswell 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? >