[dpdk-dev] [PATCH v2 04/15] node: switch IPv4 metadata to dynamic mbuf field

Nithin Dabilpuram nithind1988 at gmail.com
Tue Oct 27 16:33:53 CET 2020


On Tue, Oct 27, 2020 at 03:33:35PM +0100, Thomas Monjalon wrote:
> 27/10/2020 15:23, Nithin Dabilpuram:
> > On Mon, Oct 26, 2020 at 11:20:02PM +0100, Thomas Monjalon wrote:
> > > The node_mbuf_priv1 was stored in the deprecated mbuf field udata64.
> > > It is moved to a dynamic field in order to allow removal of udata64.
> > > 
> > > Signed-off-by: Thomas Monjalon <thomas at monjalon.net>
> > > ---
> > > --- a/lib/librte_node/ip4_lookup.c
> > > +++ b/lib/librte_node/ip4_lookup.c
> > > +int node_mbuf_priv1_dynfield_offset;
> > > +
> > 
> > This change doesn't work in secondary as it is process local memory.
> 
> Yes that's an issue.
> Can we copy the value when starting a secondary process?

Currently there is no call back which will be called only in secondary.

Can you move this value to node->ctx 8'th byte offset ? Node context is of size
16 bytes and should be sufficient.
Currently first 8 B of node->ctx is used to store that socket's lpm pointer.

> 
> [...]
> > >  static __rte_always_inline struct node_mbuf_priv1 *
> > >  node_mbuf_priv1(struct rte_mbuf *m)
> > >  {
> > > -	return (struct node_mbuf_priv1 *)&m->udata64;
> > > +	return RTE_MBUF_DYNFIELD(m,
> > > +		node_mbuf_priv1_dynfield_offset, struct node_mbuf_priv1 *);
> > 
> > There is a performance regression of ~1.4% in our platform (Octeontx2) because
> > of this	change.
> 
> Yes that's the price to pay for a more extensible DPDK.
> It is much cheaper than not having room for new features,
> or having features conflicting on the same mbuf field like here.
> 
> 


More information about the dev mailing list