Re: [RFC PATCH v2 0/9] bql: Byte Queue Limits

On Tue, 09 Aug 2011 10:06:13 +0200
Eric Dumazet [off-list ref] wrote:

Le mardi 09 août 2011 à 00:41 -0700, David Miller a écrit :

quoted

From: Stephen Hemminger <redacted>
Date: Mon, 8 Aug 2011 11:19:17 -0700

quoted

On Mon, 8 Aug 2011 11:01:57 -0700
Tom Herbert [off-list ref] wrote:

quoted

quoted

Since transmit completion means calling dev_kfree_skb() why not account
there? You could add some info to netdev if necessary to get compile
the statistics.

The algorithm depends on knowing the total number of packets competed
in a single execution of transmit completion (epic based).  We only
want to recalculate the limits once per completion, which happens when
the completion function is called.

So just add some stats to netdev and count the number of dev_kfree_skb
calls and do your work at napi complete.

No, I think what Tom's doing here is reasonable.

First off, drivers have never been required to do specific things if
they return success for ->ndo_start_xmit().  They can kfree_skb(skb)
and return NET_TX_SUCCESS, and that's fine.

This mean we can't use ->ndo_start_xmit() return values to drive the
BQL engine.

So we simply have a way for the driver to say when it really does
queue up a packet, and that might be useful for other things.

Second, you absolutely do not want to run the BQL engine on every
single dev_kfree_skb() call.  You want to batch it, and that's what
Tom's new interface does, and that is therefore quite reasonable
too.

In fact, I think the best part about this revision of the BQL patches
is the device driver interface. :-)

I agree, it permits a smooth transition to selected drivers, even some
non NAPI ones ;)

In some stress situations, NAPI never completes, so it would also mean
adding a dql call in this case...

Ok. then we need to fix all NAPI drivers at once, and get more
drivers converted over to NAPI. It is really annoying how there
is just too much variation among network drivers.