Re: [PATCH] IPROUTE: Modify tc for new PRIO multiqueue behavior

[Patrick McHardy <kaber@trash.net>]

Waskiewicz Jr, Peter P wrote:
>>I wouldn't object to putting this into a completely new scheduler
>>(sch_multiqueue) though since the scheduling policy might be 
>>something completely different than strict priority.
> 
> 
> We have plans to write a new qdisc that has no priority given to any
> skb's being sent to the driver.


I'm not sure I understand correctly, "no priority" == single band
qdisc?

> The reasoning for providing a
> multiqueue mode for PRIO is it's a well-known qdisc, so the hope was
> people could quickly associate with what's going on.  The other
> reasoning is we wanted to provide a way to prioritize various network
> flows (ala PRIO), and since hardware doesn't currently exist that
> provides flow prioritization, we decided to allow it to continue
> happening in software.


Any qdisc serving multiple queues needs some scheduling policy to
decide which one to dequeue in case multiple queues are active, so
a new qdisc might as well also use strict priority. Two reasons
why it might make sense to add a new qdisc are a) the hardware
scheduling policy could be something different than prio, like WRR,
so a neutral name like sch_multiqueue seems more fitting and b)
you don't have to figure out how to pass the new parameter to prio
without breaking compatibility.

>>The wireless multiqueue scheduler is pratically identical to 
>>this one, modulo the wireless classifier that should be a 
>>seperate module anyway.
> 
> 
> Yi Zhu from the wireless world has been active with me in this
> development effort.  He and I are copresenting a paper at OLS on this
> specific topic, so I have been getting a perspective from the wireless
> world.
> 
> I'd like to know if anyone has looked at the actual kernel patches,
> instead of the tiny patch to tc here, since that might answer many
> questions or concerns being presented here.  :-)


I did and I'm fine with the current patches if you get rid of the prio
ABI breakage. Using a new scheduler is just a suggestion, but I think
it would be cleaner to do so.