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. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
