On Tue, 2014-09-30 at 17:26 +0200, Florian Westphal wrote:

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

This was certainly the intent.

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.

Think about whats happening here.

BQL controls the optimal queue _in_ the NIC TX ring, given latencies and
throughput goals.

Once packets are queued in the NIC TX ring, there is no way a high prio
packet can be injected ahead of them, unless NIC has separate TX ring
for different prio already.

There is no need redoing this in another layer. BQL logic was hard to
setup and tune, I have no idea why you want to reinvent it.

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

Why later ? If it is not needed now, it should not be added 'to be safe'

.

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

So do not add this limit, so that we can spot bugs ahead of time.

If some NIC wants a 'doorbell at least once every 8 packets', then the
NIC driver should be fixed.