mbuf: split mbuf across two cache lines.
authorBruce Richardson <bruce.richardson@intel.com>
Thu, 11 Sep 2014 13:15:44 +0000 (14:15 +0100)
committerThomas Monjalon <thomas.monjalon@6wind.com>
Wed, 17 Sep 2014 16:57:19 +0000 (18:57 +0200)
commitf867492346bd271742dd34974e9cf8ac55ddb869
treee17ca46449753eaca01317839fbb81769900da3b
parent587c63cea9c8ec0c2e742b94436a31aa04bfde33
mbuf: split mbuf across two cache lines.

This change splits the mbuf in two to move the pool and next pointers to
the second cache line. This frees up 16 bytes in first cache line.

The reason for this change is that we believe that there is no possible
way that we can ever fit all the fields we need to fit into a 64-byte
mbuf, and so we need to start looking at a 128-byte mbuf instead. Examples
of new fields that need to fit in, include -
* 32-bits more for filter information for support for the new filters in
  the i40e driver (and possibly other future drivers)
* an additional 2-4 bytes for storing info on a second vlan tag to allow
  drivers to support double Vlan/QinQ
* 4-bytes for storing a sequence number to enable out of order packet
  processing and subsequent packet reordering
as well as potentially a number of other fields or splitting out fields
that are superimposed over each other right now, e.g. for the qos scheduler.
We also want to allow space for use by other non-Intel NIC drivers that may
be open-sourced to dpdk.org in the future too, where they support fields
and offloads that currently supported hardware doesn't.

If we accept the fact of a 2-cache-line mbuf, then the issue becomes
how to rework things so that we spread our fields over the two
cache lines while causing the lowest slow-down possible. The general
approach that we are looking to take is to focus the first cache
line on fields that are updated on RX , so that receive only deals
with one cache line. The second cache line can be used for application
data and information that will only be used on the TX leg. This would
allow us to work on the first cache line in RX as now, and have the
second cache line being prefetched in the background so that it is
available when necessary. Hardware prefetches should help us out
here. We also may move rarely used, or slow-path RX fields e.g. such
as those for chained mbufs with jumbo frames, to the second
cache line, depending upon the performance impact and bytes savings
achieved.

Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
Acked-by: Thomas Monjalon <thomas.monjalon@6wind.com>
app/test/test_mbuf.c
lib/librte_eal/linuxapp/eal/include/exec-env/rte_kni_common.h
lib/librte_mbuf/rte_mbuf.h