Re: rte_mbuf.next in 2nd cacheline

[Thomas Monjalon <thomas.monjalon@6wind.com>]

2015-06-17 13:55, Damjan Marion:
> 
> > On 15 Jun 2015, at 16:12, Bruce Richardson <bruce.richardson@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...

Having a build-time configuration of mbuf totally breaks the idea of having
some shared libraries.