On Fri, Jul 13, 2018 at 11:17:18AM -0700, Cong Wang wrote: ... > > > > > Isn't the whole point of sch_prio offloading the queueing to > > > > > each class? If you need a limit, there is one for each child > > > > > qdisc if you use for example pfifo or bfifo (depending on you > > > > > want to limit bytes or packets). > > > > > > > > Yes, but Michel wants to drop from other lower priorities if needed, > > > > and that's not possible if you handle the limit already in a child > > > > qdisc as they don't know about their siblings. The idea in the example > > > > above is to discard it from whatever lower priority is needed, then > > > > queue it. (ok, the example missed to check the priority level) > > > > > > So it disproves your point of adding a flag to sch_prio, right? > > > > I don't see how? > > Interesting, you said "Michel wants to drop from other lower > priorities if needed", but sch_prio has no knowledge of this, > you confirmed with "...if you handle the limit already in a child > qdisc as they don't know about their siblings." > > The if clause is true as the limit is indeed handled by its child > qdiscs as designed. > > Therefore, a simple of adding a flag to sch_prio, as you > suggested and demonstrated above, doesn't work, as > confirmed by your own words.
Well, it would help if you didn't cut out key parts of my words. > > What am I missing here? > > Are you go further by suggesting moving the limit out of prio? > Or are you going to expand your definition of "adding a flag"? > Perhaps two flags? :) > > I am very open for discussion to see how far we can go. I am not keen on continuing this discussion if you keep twisting my words just for fun.