[dpdk-dev] rte_mbuf.next in 2nd cacheline

Damjan Marion (damarion) damarion at cisco.com
Wed Jun 17 15:55:57 CEST 2015


> On 15 Jun 2015, at 16:12, Bruce Richardson <bruce.richardson at intel.com> wrote:
> 
> The next pointers always start out as NULL when the mbuf pool is created. The
> only time it is set to non-NULL is when we have chained mbufs. If we never have
> any chained mbufs, we never need to touch the next field, or even read it - since
> we have the num-segments count in the first cache line. If we do have a multi-segment
> mbuf, it's likely to be a big packet, so we have more processing time available
> and we can then take the hit of setting the next pointer.

There are applications which are not using rx offload, but they deal with chained mbufs.
Why they are less important than ones using rx offload? This is something people 
should be able to configure on build time.
That should not be too hard to achieve with set of macros. I can come up with the patch...

Thanks,

Damjan


More information about the dev mailing list