Hi Jeremy, I implemented this functionality in Devicescape's 802.11 stack.
The approach I took was for the driver to install a device specific qdisc as the root qdisc on the device. This root qdisc's purpose is to expose the hardware queues directly, so other qdiscs can be attached as leaf qdiscs. This hardware specific root qdisc cannot be deleted or changed. This makes it possible to use tc to inspect/set/modify per hardware queue statistics and parameters. In order for this to work my device driver never calls netif_stop. Instead the qdisc dequeue function for the root qdisc looks to see which hardware queues can accept a frame, and if none then it returns no data. The driver's frame completion function calls __netif_schedule appropriately too to ensure the queue runs when it should. This allows Devicescape's 802.11 stack to properly integrate with the Linux tc framework. I don't think any other 802.11 drivers achieve this. In the future I plan to extend Devicescape's 802.11 root qdisc to further expose the 802.11 MAC's internal queues, in cases where this is useful (e.g. the scheduled access implementation). The same principle could apply to Intel's e1000. Simon -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jeremy Jackson Sent: Wednesday, December 14, 2005 2:31 PM To: netdev@vger.kernel.org Subject: netif_stop_queue() and multiple hardware queues Hi, I posted this briefly on linux-net, before being redirected here. Two pieces of hardware now have Linux driver support for multiple hardware queues: Intel's e1000 (two queues from what I can see in the code) and Atheros's 5212 and up, in support of 802.11e and WME (four hardware queues). In the GigE case, this just reduces latency due to hardware queueing. In the WiFi case, the queues actually have significance in access to the shared medium. (ACKs can be disabled as well) It is also worthy of note that ADSL2, VDSL, and ADSL2+ have 4 different latency "queues". These last two are significant; real-time applications suffer the most from low speed, shared, and/or non-deterministic media. I wonder where DOCSIS 2 is in this regard. Anyone? Beuler? So my question is, what's it going to take to get dev->hard_start_xmit() to hook up tc queues directly to hardware/driver queues? Right now, it seems no matter how elaborate a tc setup you have, everything funnels through one queue, where the only thing that survives from the classifying/queueing is skb-> priority (ie nothing). The hardware driver can then try to reclassify packets. I suppose you could hack up an iptables classifyer to set skb->priority... The Atheros driver tries to do it's own classifying by first wiping out skb->priority, then hard-coding a mapping (tsk - policy is for the sysadmin!) between VLAN tag priority, IP TOS/DSCP, and skb->priority, then to one of the 4 queues and ACK states, blithely ignoring any fine work done by tc. It's be sweet to head this nonsense off at the pass, before others discover the rabbit trail and make it into a trade route. -- Jeremy Jackson Coplanar Networks W:(519)489-4903 MSN: [EMAIL PROTECTED] ICQ: 43937409 http://www.coplanar.net - 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 - 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
