Am Mittwoch 25 Januar 2006 07:55 schrieb James Ketrenos: > The purpose for this code ever coming into existence within ieee80211 > was based on discussions at OLS this past year in how to support for the > ability to start/stop independent Tx queues within a single net device > in order to support 802.11e QoS.
QoS. I was expecting that answer. But actually it isn't about QoS, it is about supporting multiple hardware queues at driver level. If you just want to do QoS, you can achieve it with ONE small queue in the hardware (just the opposite of what I did during my tests with bug 825 ;-) and then let the network qdiscs do the work. This is not totally without headaches because you might need to inject management packets at high priority, but after all, at typical 802.11 rates a modern CPU should be able to do QoS in software. Supporting multiple hardware queues is a problem. The elegant way from an API perspective would be expanding linux qdiscs so that netif_stop_queue() and netif_wake_queue() also could take a queue number as an argument. It doesn't look easy to me but I'm far from understanding all secrets of the networking core. > We need to be able to indicate to the > upper layers that packets of a given priority can not be sent any more > with out halting transmission of all packets, and without rescheduling > high priority packets down to the next priority level. For the hacky way, look at the devicescape driver. They have two qdiscs, one fifo for every hardware queue and one root qdisc that polls the fifos for all hardware queues that have space available and halts otherwise (even though my short glance at this part didn't provide me all the details how it restarts a stopped queue, but Jiri should know better). > Jamal indicated we should just return NETDEV_TX_BUSY and the stack would > take care of rescheduling... well so even Jamal can be wrong sometimes ;-) But after all, it isn't Jamals fault, it is your development model. For me, you Intel people seem to be sitting in your ivory tower, programming stuff, dropping new releases onto the ipw and 802.11 web sites every couple of weeks. Then someone of you has the job to split up the work into patches and submit it to the kernel. I must admit that you submit it at least, different to other driver developers. But after all, this just invites things like this to happen. Someone comes up and says "patch 1/18 is totally busted, I told you". Bad luck. So after all I'd suggest that we move at least development of ieee80211 into the kernel and that everybody, including you, submit their changes frequently and is willing to discuss them. So bugs like this can be spotted in a shorter time. Right now, there is a discussion about how a wireless subsystem/stack for linux should look like, and regular input from you would be very appreciated! > To put the code back to the way it was before we made these changes we > can put the call netif_queue_stop back in ipw_tx_skb. This effectively > disables multiple priority based transmit queues for 802.11e, but given > that its broken anyway... For now, I must admit this solutions seems the best to me. Btw, last time I tried to compile the ipw driver with multiple hardware queues and firmware 2.3 / 2.4, even with my patch transfer speeds were dropping to 200k/sec so firmware support for this feature doesn't seem to be stable enough for production use anyway. Stefan - 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
