[dpdk-dev] rte_mbuf.next in 2nd cacheline
Thomas Monjalon
thomas.monjalon at 6wind.com
Wed Jun 17 16:04:16 CEST 2015
2015-06-17 13:55, Damjan Marion:
>
> > 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...
Having a build-time configuration of mbuf totally breaks the idea of having
some shared libraries.
More information about the dev
mailing list