On Tue, Sep 30, 2014 at 8:26 AM, Florian Westphal [off-list ref] wrote:

Eric Dumazet [off-list ref] wrote:

quoted

On Tue, 2014-09-30 at 15:46 +0200, Florian Westphal wrote:

quoted

Eric Dumazet [off-list ref] wrote:

quoted

From: Eric Dumazet <edumazet@google.com>

Add a new dql attribute, to control how much packets we are allowed to
burst from qdisc to device.

I understand the motivation for this, but I find it a bit out-of-place
to have a 'packet' type counter in bql context?

Would it perhaps make more sense to restrict bulk dequeues by an upper
(possibly changeable from userspace) byte counter limit?

The byte count is already provided : its the BQL limit.
We already have ways to tune it (limit_min & limit_max)
We do not think we need something else here.

So you're saying that a bulk dequeue should just grab as many skbs
as possible until no more available or dql_avail exhausted?

The "magic" value was just to be conservative and not induce any
hol blocking, which is also why Jesper reduced it again in the latest
submission.

Then, we might later be able to remove the TSO restriction and switch
to a pure byte-based limit.

(I don't think having a packet-based count makes sense once tso/gso
 skbs can be bulk dequeued).

Sorry for the confusion.

I still have some hope that we can one day fix wifi packet aggregation,
which is a limit of 42 packets or 64k bytes per aggregate (best case),
with something BQL-like.

As for the size of the tx ring problem vs GSO, there is at least one
driver with a very limited tx ring that I can think of that tears apart
GSO packets in the driver... but I'm not sure if it's mainlined.

I would not mind at all if TSO/GSO were banned on devices running
slower than 100Mbit.

Perhaps exporting the tx-ring size would be saner than a burst
parameter?

-- 
Dave Täht

https://www.bufferbloat.net/projects/make-wifi-fast