[dpdk-dev] [RFC] mbuf: support dynamic fields and flags

[Jerin Jacob Kollanukkaran]

> -----Original Message-----
> From: dev <dev-bounces at dpdk.org> On Behalf Of Olivier Matz
> Sent: Thursday, July 11, 2019 1:07 PM
> To: Stephen Hemminger <stephen at networkplumber.org>
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] [RFC] mbuf: support dynamic fields and flags
> 
> On Wed, Jul 10, 2019 at 10:49:17AM -0700, Stephen Hemminger wrote:
> > On Wed, 10 Jul 2019 11:29:07 +0200
> > Olivier Matz <olivier.matz at 6wind.com> wrote:
> >
> > >  /**
> > >   * Indicate that the metadata field in the mbuf is in use.
> > > @@ -738,6 +741,8 @@ struct rte_mbuf {
> > >  	 */
> > >  	struct rte_mbuf_ext_shared_info *shinfo;
> > >
> > > +	uint64_t dynfield1; /**< Reserved for dynamic fields. */
> > > +	uint64_t dynfield2; /**< Reserved for dynamic fields. */

Since the mbuf size is fixed, What is the downside of union scheme[1] vs upside of proposed scheme

[1] Example like:
        RTE_STD_C11
        union {
                void *userdata;   /**< Can be used for external metadata */
                uint64_t udata64; /**< Allow 8-byte userdata on 32-bit */
        };

# The fields like mbuf: hash.usr, used in variety  of use case together
Like libraries like distributor() and Eventdev using it. If we switch
to dynamic mbuf scheme, We wil take those field using rte_mbuf_dynfield_register()
on library init?

# I see an upside of dynamic mbuf if we can add rte_mbuf_dynfield_unregister API.
But can we ever do that? Because it will be complex if we need introduce notification mechanism etc.

# In the real world use case, if with union scheme, fastpath API can simply deference 
specific element (say mbuf->fieldx). With dynamic scheme, the offset need to store
in some other data structure  and de reference in fastpath before assessing the interested field.
Right?