[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