[dpdk-dev] [PATCH] ethdev: support double precision RED queue weight

[Rao, Nikhil]

> -----Original Message-----
> From: Stephen Hemminger [mailto:stephen at networkplumber.org]
> Sent: Monday, December 10, 2018 9:31 PM

Hi Stephen,

> To: Rao, Nikhil <nikhil.rao at intel.com>
> Cc: Dumitrescu, Cristian <cristian.dumitrescu at intel.com>; Singh, Jasvinder
> <jasvinder.singh at intel.com>; dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH] ethdev: support double precision RED queue
> weight
> 
> On Mon, 10 Dec 2018 05:43:37 +0000
> "Rao, Nikhil" <nikhil.rao at intel.com> wrote:
> 
> > > -----Original Message-----
> > > From: Stephen Hemminger [mailto:stephen at networkplumber.org]
> > > Sent: Thursday, November 29, 2018 11:43 AM
> > > To: Rao, Nikhil <nikhil.rao at intel.com>
> > > Cc: Dumitrescu, Cristian <cristian.dumitrescu at intel.com>; Singh,
> > > Jasvinder <jasvinder.singh at intel.com>; dev at dpdk.org
> > > Subject: Re: [dpdk-dev] [PATCH] ethdev: support double precision RED
> > > queue weight
> > >
> > > On Thu, 29 Nov 2018 11:24:42 +0530
> > > Nikhil Rao <nikhil.rao at intel.com> wrote:
> > >
> > > > RED queue weight is currently specified as a negated log of 2.
> > > >
> > > > Add support for RED queue weight to be specified in double
> > > > precision and TM capability flags for double precision and negated
> > > > log2 RED queue weight support.
> > > >
> > > > Signed-off-by: Nikhil Rao <nikhil.rao at intel.com>
> > >
> > > Since this is an ABI break anyway, why not just commit to the new format?
> >
> > Hi Stephen,
> >
> > Can you please provide more detail on your comment ?  are you suggesting
> replacing the wq_log2/wq_dp with a double ?
> >
> > Thanks,
> > Nikhil
> 
> 
> My comment is that since you are changing a structure layout, which would
> break existing users; why not go farther and just fix the API to a better
> version. I don't think any projects use this code anyway, see my talk
> (https://github.com/shemminger/dpdk-metrics).

Sorry for the delay.  I don't get your reference to a better version,  the structure supports both formats using a union,
 similar to how it's done in other DPDK APIs (struct rte_crypto_sym_xform for example).  If you have a suggestion for a better layout,
please let me know.
 
> 
> Isn't floating point going to be expensive. Or is it only during the setup
> process, not enqueue/dequeue.

Yes, floating point may end up to be more expensive (and the RED computation is invoked at every enqueue)

Nikhil