From mboxrd@z Thu Jan 1 00:00:00 1970 From: Patrick McHardy Subject: Re: [PATCH] IPROUTE: Modify tc for new PRIO multiqueue behavior Date: Thu, 26 Apr 2007 18:44:25 +0200 Message-ID: <4630D6E9.7090201@trash.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Cc: hadi@cyberus.ca, Stephen Hemminger , netdev@vger.kernel.org, jgarzik@pobox.com, cramerj , "Kok, Auke-jan H" , "Leech, Christopher" , davem@davemloft.net To: "Waskiewicz Jr, Peter P" Return-path: Received: from stinky.trash.net ([213.144.137.162]:60657 "EHLO stinky.trash.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751627AbXDZQph (ORCPT ); Thu, 26 Apr 2007 12:45:37 -0400 In-Reply-To: Sender: netdev-owner@vger.kernel.org List-Id: netdev.vger.kernel.org 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.