From: Rusty Russell <rusty@rustcorp.com.au>
Date: Mon, 19 May 2008 13:08:13 +1000

quoted text
> 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 netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html