[dpdk-dev] [PATCH v5] sched: make RED scaling configurable

Dumitrescu, Cristian cristian.dumitrescu at intel.com
Fri Jan 12 12:09:19 CET 2018


...<snip>
 
> > > diff --git a/lib/librte_sched/rte_red.c b/lib/librte_sched/rte_red.c
> > > +int
> > > +rte_red_set_scaling(uint16_t max_red_queue_length) {
> > > +	int8_t count;
> > > +
> > > +	if (rte_red_init_done)
> > > +		/**
> > > +		 * Can't change the scaling once the red table has been
> > > +		 * computed.
> > > +		 */
> > > +		return -1;
> >
> > Is there a reason why we cannot simply reset the scaling here?
> 
> Actually we could, but I was originally thinking that you might be happier
> keeping with a one-time RED initialization function, but then had to
> introduce the rte_reset_red_scaling function for the unit-tests. I'm happy to
> do RED reinitialization here, if you are.
> 

Hi Alan,

What is the intention of the new rte_red_set_scaling() function?
	1. Is it to be called only once, before any RED object gets created?
	2. Is it possible to call it post-init, but in this case any RED object already created are not impacted (they continue to work)?

If the answer is 2, then yes, we could simply drop the __rte_red_reset() and do the RED globals reset as part of the rte_red_set_scaling() function transparently.

If the answer is 1, then we probably need to keep your approach: we need a global rte_red_init_done flag, and rte_red_set_scaling() could only be called at init time before any red objects are created.

I probably need to spend more time assessing all the code implications.

Regards,
Cristian



More information about the dev mailing list