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

["Damjan Marion (damarion)" <damarion@cisco.com>]

> 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...

Thanks,

Damjan