[ovs-dev] [PATCH v4 01/15] netdev-dpdk: Differentiate between mtu/mbuf size.

Lam, Tiago tiago.lam at intel.com
Tue Jul 10 11:09:23 UTC 2018


On 10/07/2018 12:06, Tiago Lam wrote:
> When configuring a mempool, in netdev_dpdk_mempool_configure(), the
> result of a call to dpdk_buf_size() is being used as the MTU. This,
> however, is not the MTU but a ROUND_UP aligned number based on the MTU,
> which could lead to the reuse of mempools even when the real MTUs
> between different ports differ but somehow round up to the same mbuf
> size.
> 
> To support multi-segment mbufs, which is coming in later commits, this
> distinction is important. For multi-segment mbufs the mbuf size is
> always the same (multiple mbufs are chained together to hold the
> packet's data), which means that using the mbuf size as the mtu would
> lead to reusing always the same mempool, independent of the MTU set.
> 
> To fix this, two fields are now passed to dpdk_mp_create(), the mtu and
> the mbuf_size, thus creating a distinction between the two. The latter
> is used for telling rte_pktmbuf_pool_create() the size of each mbuf,
> while the former is used for tracking purposes in struct dpdk_mp and as
> an input to create a unique hash for the mempool's name.
> 
> Signed-off-by: Tiago Lam <tiago.lam at intel.com>
> ---
>  lib/netdev-dpdk.c | 22 +++++++++++++---------
>  1 file changed, 13 insertions(+), 9 deletions(-)
> 

Hi Ian,

This patch changes the way the dpdk_mp struct tracks the "mtu", which
was introduced in "Support both shared and per port mempools". Instead
of assigning the "buf_size" to the "mtu" member in the dpdk_mp struct,
we assign the "requested_mtu".

This was needed because for multi-segment mbufs the "mbuf_size" may end
up being always the same even for different MTUs (as the mbufs are
chained together to hold all data), which meant the same mempool would
end up being reused.

I don't expect this to change the functionality (ran a few tests myself
to confirm the correct behavior), but does this sound OK to you? Any
thoughts here?

Thanks,
Tiago.



More information about the dev mailing list