From: Rusty Russell <rusty@xxxxxxxxxxxxxxx> Date: Mon, 19 May 2008 13:08:13 +1000 > The bit I can't see is what to do about qdisc if the driver manages its own > queue(s). Leave the qdisc as currently in place and have the driver call > dev_dequeue_skb() (or some wrapper) directly? Modulo locking issues, that > should be a fairly simple change. I'd like to approach a state where the device is just a black hole that the qdisc injects packets into. At least theoretically, that's what the network is once the packet leaves the device anyways. Nobody really notices as long as flows don't get reordered. I realize it isn't feasible to retain many of the qualities that some qdiscs want (rates, qfull handling, etc.), so we'll have to provide some handling for that, ideally in some cheap slowpath test. But for things like tx queue backlog overflow the behavior would be essentially the same. The only change is that the txqueuelen parameter is handled inside of the driver (again, perhaps via helpers). Our TX path is way too complicated and, frankly, restrictive. This is why we don't have real parallel TX multiqueue support as a simple patch to some drivers. We have fundamental restrictions that keep that from happening. -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
