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