> Commit dfaf00e started using the result of dpdk_buf_size() to calculate > the available size on each mbuf, as opposed to using the previous > MBUF_SIZE macro. However, this was calculating the mbuf size by adding up > the MTU with RTE_PKTMBUF_HEADROOM and only then aligning to > NETDEV_DPDK_MBUF_ALIGN. Instead, the accounting for the > RTE_PKTMBUF_HEADROOM should only happen after alignment, as per below. > > Before alignment: > ROUNDUP(MTU(1500) + RTE_PKTMBUF_HEADROOM(128), 1024) = 2048 > > After aligment: > ROUNDUP(MTU(1500), 1024) + 128 = 2176 > > This might seem insignificant, however, it might have performance > implications in DPDK, where each mbuf is expected to have 2k + > RTE_PKTMBUF_HEADROOM of available space. This is because not only some > NICs have course grained alignments of 1k, they will also take > RTE_PKTMBUF_HEADROOM bytes from the overall available space in an mbuf > when setting up their Rx requirements. Thus, only the "After alignment" > case above would guarantee a 2k of available room, as the "Before > alignment" would report only 1920B. > > Some extra information can be found at: > https://mails.dpdk.org/archives/dev/2018-November/119219.html > > Note: This has been found by Ian Stokes while going through some af_packet > checks. > > Reported-by: Ian Stokes <[email protected]> > Fixes: dfaf00e ("netdev-dpdk: fix mbuf sizing") > Signed-off-by: Tiago Lam <[email protected]>
Thanks Tiago, I've applied this to master. If I'm not mistaken I believe it should be back ported also, previous releases were using the incorrect calculation for dpdk_buf_size Thoughts? Ian _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
