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

[Olivier Matz <olivier.matz@6wind.com>]

On Fri, Jul 12, 2019 at 12:23:19PM +0000, Jerin Jacob Kollanukkaran wrote:
> > -----Original Message-----
> > From: dev <dev-bounces@dpdk.org> On Behalf Of Olivier Matz
> > Sent: Thursday, July 11, 2019 1:07 PM
> > To: Stephen Hemminger <stephen@networkplumber.org>
> > Cc: dev@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@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 */
>         };

In the particular case of userdata, the union is not an issue, it
just means that there are several ways to represent the same data.
If needed, it is possible to register a union as a dynamic field.

In other case, like m->hash, having a union makes it impossible to
use several features of the union at the same time. This would be
solved by dynamic fields.

> # 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?

If we decide that these fields must be converted to a dynamic field,
yes, each library/application will call rte_mbuf_dynfield_register().

> # 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.

An unregister mechanism seems hard to implement, or we can leave the
hard part to the user: either ensure that no mbuf is in use anywhere, or
that removing the dynamic field won't have any impact. But I'd prefer
not introducing an unregistration function until we have a real use-case
for it.

> # 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?

Yes, with dynamic fields, the offset is stored in a variable. A global
variable (static to the file or module using it) does the job. This may
have a small performance impact.