> -----Original Message-----
> From: Ananyev, Konstantin
> Sent: Tuesday, December 18, 2018 5:07 PM
> To: Thomas Monjalon <tho...@monjalon.net>; Dumitrescu, Cristian
> <cristian.dumitre...@intel.com>
> Cc: Pattan, Reshma <reshma.pat...@intel.com>; dev@dpdk.org;
> jerin.ja...@caviumnetworks.com; Singh, Jasvinder
> <jasvinder.si...@intel.com>; david.march...@redhat.com;
> olivier.m...@6wind.com
> Subject: RE: [dpdk-dev] [PATCH v2 2/3] eal: add new rte color definition
>
>
>
> > -----Original Message-----
> > From: Thomas Monjalon [mailto:tho...@monjalon.net]
> > Sent: Tuesday, December 18, 2018 1:39 PM
> > To: Dumitrescu, Cristian <cristian.dumitre...@intel.com>
> > Cc: Pattan, Reshma <reshma.pat...@intel.com>; dev@dpdk.org; Ananyev,
> Konstantin <konstantin.anan...@intel.com>;
> > jerin.ja...@caviumnetworks.com; Singh, Jasvinder
> <jasvinder.si...@intel.com>; david.march...@redhat.com;
> olivier.m...@6wind.com
> > Subject: Re: [dpdk-dev] [PATCH v2 2/3] eal: add new rte color definition
> >
> > 18/12/2018 14:19, Dumitrescu, Cristian:
> > > From: Thomas Monjalon [mailto:tho...@monjalon.net]
> > > > 18/12/2018 12:18, Dumitrescu, Cristian:
> > > > > > > I replied in v3 that it should stay in rte_meter.h.
> > > > > > > You can include rte_meter.h in ethdev.
> > > > > >
> > > > > > OK, thanks Thomas, makes sense to me as well.
> > > > > >
> > > > >
> > > > > Thomas,
> > > > >
> > > > > I agree with your input, but just want to make sure we are on the
> same
> > > > page:
> > > > >
> > > > > Besides including rte_meter.h in ethdev (which you are fine with), we
> > > > would also need to include rte_meter.h in mbuf.
> > > > >
> > > > > Are you OK with this as well?
> > > >
> > > > Why do we need rte_meter.h in mbuf?
> > > >
> > >
> > > You probably looked at V2 only, but in V3 we have functions to set/get
> the color within the mbuf->hash.sched field.
> > >
> > > For space compression reasons, the mbuf->hash.sched stores the color
> on 8-bit variable, while for the outside world the set/get functions
> > work with the 32-bit enum type. We do same thing in other places in DPDK,
> such as rte_crypto_op, etc.
> >
> > So it's a different discussion.
> > We need to review this v3 and check how relevant this mbuf API is.
> >
> > If the API is accepted, yes the include should not be an issue.
>
> Personally, I don't think it is a good idea to add extra dependency for
> librte_mbuf.
> I'd prefer either to keep rte_color definition inside librte_mbuf,
> or move corresponding function definitions out of it.
> Konstantin
Konstantin,
As you see, the number of options is limited, and none of them is
perfect:
1/ color enum in EAL/common/include: still my favorite, as it does not
create any new library dependencies, and it is already used to store lots of
similar generic items
2/ color enum in rte_meter.h: results in creating new librte_mbuf
dependency to librte_meter
3/ color enum in rte_mbuf.h: results in creating new librte_meter
dependency to librte_mbuf (yes, currently librte_meter does not depend on
librte_mbuf)
Personally, I can live with any of these options.
Thomas,
It would be good to have your input as well, Reshma just sent V4
implementing your proposal based on having the color enum defined in
rte_meter.h, which gets included into rte_mbuf.h.
We need to make progress for RC1 deadline.
Thanks,
Cristian
