> -----Original Message----- > From: Stephen Hemminger [mailto:step...@networkplumber.org] > Sent: Monday, December 10, 2018 9:31 PM
Hi Stephen, > To: Rao, Nikhil <nikhil....@intel.com> > Cc: Dumitrescu, Cristian <cristian.dumitre...@intel.com>; Singh, Jasvinder > <jasvinder.si...@intel.com>; dev@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....@intel.com> wrote: > > > > -----Original Message----- > > > From: Stephen Hemminger [mailto:step...@networkplumber.org] > > > Sent: Thursday, November 29, 2018 11:43 AM > > > To: Rao, Nikhil <nikhil....@intel.com> > > > Cc: Dumitrescu, Cristian <cristian.dumitre...@intel.com>; Singh, > > > Jasvinder <jasvinder.si...@intel.com>; dev@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....@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....@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
