Thread (8 messages) 8 messages, 5 authors, 2011-05-02

Re: [PATCH 0/3] net: Byte queue limit patch series

From: David Miller <davem@davemloft.net>
Date: 2011-05-02 03:50:11

From: Tom Herbert <redacted>
Date: Sun, 1 May 2011 19:41:34 -0700
On Fri, Apr 29, 2011 at 11:54 AM, David Miller [off-list ref] wrote:
quoted
Add new interface, netdev_free_tx_skb(txq, skb) which can do the
completion accounting.  Actually the 'txq' argument is probably
superfluous as it can be obtained from the skb itself.
Okay, but I think the call at the end of TX completion processing is
still probably needed.  The algorithm is trying to determine the
number of bytes that completed at each interrupt.
Ok, then call it something generic like netdev_tx_complete() which
can serve other purposes in the future and not be bql specific.
quoted
Finally, you manage the bql limit logic in the existing generic netdev
TX start/stop interfaces.  If the user asks for "start" but the bql
is overlimit, simply ignore the request.  The driver will just signal
another "start" when the next TX packet completes.

Similarly, when the qdisc is queuing up a packet to
dev_hard_start_xmit() you can, for example, preemptively do a "stop"
on the queue if you find bql is overlimit.
Unfortunately, there is still an additional complexity if we don't
piggy back on the logic in the driver to stop the queue.  I believe
that either this would require another queue state for queue being
stopped for bql which looks pretty cumbersome, so that wrapping this
in a qdisc might be a better possibility.
I'll leave it up to you what approach to try next.

Even thought I sort of side with you that bql is a largely seperate
facility from what we usually do with qdiscs, this TX completion
event could be very useful as an input to qdisc decision making.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help