[dpdk-users] Compatibly adding metadata to mbufs?

[dpdk-users] Compatibly adding metadata to mbufs?

[Mike Playle]

Hello,

I've recently started looking into DPDK.

We're interested in adding our own metadata to DPDK's mbuf structures
by setting the 'priv_size' parameter to rte_pktmbuf_pool_create().  An
example application which does this is Open vSwitch, and we would like
to do something similar.

When initialising a PMD, rte_eth_rx_queue_setup() takes a pointer to a
mempool which is used to allocate receive buffers; packets returned
from rte_eth_rx_burst() will be stored in mbufs allocated from this
pool. This means that we can easily alter their layout to add our own
metadata region.

However it's not clear that this will work in all cases. For instance,
the "rings-based" PMD doesn't appear to work like this.  Instead the
sender's mbufs are passed directly to the receiver. This means that if
we connect to Open vSwitch instead of a physical NIC, we will have no
control over the layout of the mbufs we receive, and so we can't
guarantee to be able to store our metadata.

Conversely, any mbufs that we send back to Open vSwitch will have to
be allocated from its pool rather than ours, otherwise it will be
unable to store its own metadata.

Do we have to copy the packet data to/from our own mbufs to ensure
compatibility here? We'd like to avoid copies as far as possible.

Or am I misunderstanding something about how metadata works?

Regards,

Mike Playle
Solarflare Communications

Re: [dpdk-users] Compatibly adding metadata to mbufs?

[Stephen Hemminger]

On Fri, 18 Nov 2016 16:46:29 +0000
Mike Playle <mplayle@solarflare.com> wrote:

> Hello,
> 
> I've recently started looking into DPDK.
> 
> We're interested in adding our own metadata to DPDK's mbuf structures
> by setting the 'priv_size' parameter to rte_pktmbuf_pool_create().  An
> example application which does this is Open vSwitch, and we would like
> to do something similar.
> 
> When initialising a PMD, rte_eth_rx_queue_setup() takes a pointer to a
> mempool which is used to allocate receive buffers; packets returned
> from rte_eth_rx_burst() will be stored in mbufs allocated from this
> pool. This means that we can easily alter their layout to add our own
> metadata region.
> 
> However it's not clear that this will work in all cases. For instance,
> the "rings-based" PMD doesn't appear to work like this.  Instead the
> sender's mbufs are passed directly to the receiver. This means that if
> we connect to Open vSwitch instead of a physical NIC, we will have no
> control over the layout of the mbufs we receive, and so we can't
> guarantee to be able to store our metadata.
> 
> Conversely, any mbufs that we send back to Open vSwitch will have to
> be allocated from its pool rather than ours, otherwise it will be
> unable to store its own metadata.
> 
> Do we have to copy the packet data to/from our own mbufs to ensure
> compatibility here? We'd like to avoid copies as far as possible.
> 
> Or am I misunderstanding something about how metadata works?
> 
> Regards,
> 
> Mike Playle
> Solarflare Communications

Don't overload mbuf with metadata. It guarantees that you won't
be able to stay current with upstream, and use distro packages.

Standard practice is to use the prepend area in the mbuf.
Look at FD.io project and some of the examples