From: David Miller <davem@davemloft.net>
To: therbert@google.com
Cc: netdev@vger.kernel.org
Subject: Re: [PATCH 0/3] net: Byte queue limit patch series
Date: Fri, 29 Apr 2011 11:54:43 -0700 (PDT) [thread overview]
Message-ID: <20110429.115443.28811990.davem@davemloft.net> (raw)
In-Reply-To: <alpine.DEB.2.00.1104252128001.5889@pokey.mtv.corp.google.com>
From: Tom Herbert <therbert@google.com>
Date: Mon, 25 Apr 2011 21:38:06 -0700 (PDT)
> This patch series implements byte queue limits (bql) for NIC TX queues.
I like the idea, I don't like how much drivers have to be involved
in this.
TX queue handling is already too involved for driver writers, so
having them need to get all of these new hooks right is a non-starter.
I don't even think it's necessary to be honest, I think you can hide
to bulk of it.
alloc_etherdev_mq() can initialize the per-txq bql instances.
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.
dev_hard_start_xmit() can do the "sent" processing.
Then the only thing you're doing is replacing dev_kfree_skb*()
in the TX path of the driver with the new netdev_free_tx_skb()
thing.
Maybe you can add a "netdev_tx_queue_reset()" hook for asynchronous
device resets. Otherwise the bql reset can occur in generic code
right at ->ndo_open().
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.
Thanks Tom.
next prev parent reply other threads:[~2011-04-29 18:55 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-04-26 4:38 [PATCH 0/3] net: Byte queue limit patch series Tom Herbert
2011-04-26 5:56 ` Bill Fink
2011-04-26 6:17 ` Eric Dumazet
2011-04-26 6:14 ` Eric Dumazet
2011-04-26 16:57 ` Rick Jones
2011-04-29 18:54 ` David Miller [this message]
2011-05-02 2:41 ` Tom Herbert
2011-05-02 3:49 ` David Miller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20110429.115443.28811990.davem@davemloft.net \
--to=davem@davemloft.net \
--cc=netdev@vger.kernel.org \
--cc=therbert@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).