From: Ben Greear <greearb@candelatech.com>
To: Eric Dumazet <eric.dumazet@gmail.com>
Cc: David Miller <davem@davemloft.net>, netdev@vger.kernel.org
Subject: Re: [net-next 1/2] qdisc: Allow qdiscs to provide backpressure up the stack.
Date: Fri, 27 Aug 2010 10:00:50 -0700 [thread overview]
Message-ID: <4C77EF42.6020600@candelatech.com> (raw)
In-Reply-To: <1282924797.5208.31.camel@edumazet-laptop>
On 08/27/2010 08:59 AM, Eric Dumazet wrote:
> Le vendredi 27 août 2010 à 08:26 -0700, Ben Greear a écrit :
>
>> For the trivial case, I can just kfree_skb when BUSY is returned, for the
>> same overall behaviour as today. For something like UDP, I might be able
>> to poke the SKB back into the queue instead of freeing it.
>
> Its not trivial at all. Actually I bet this is not possible.
Ughh, I'll quit bothering with higher level protocols then.
Dave: Is there any reason to pursue the qdisc BUSY return code
so that it can be used for macvlans, vlans, bonding, etc, or
is that idea just DOA.
There are calls to dev_queue_xmit all over, and many don't
check return codes at all. I could still fix those up to
free the skb when BUSY is returned.
Or, I could stay with adding a new try_dev_queue_xmit method
so that the few callers that care can deal with error codes
properly.
Based on my slightly improved understanding of how UDP and others
do queue backoff, I don't see how the changes to macvlan that
I posted could cause any additional opportunities for queue
deadlock.
If someone manages to add a qdisc to a macvlan, there could
be issues since there is no way to wake up a macvlan queue,
but that issue exists with or without my patch.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
prev parent reply other threads:[~2010-08-27 17:00 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-08-25 19:00 [net-next 1/2] qdisc: Allow qdiscs to provide backpressure up the stack Ben Greear
2010-08-25 19:00 ` [net-next 2/2] macvlan: Enable qdisc backoff logic Ben Greear
2010-08-25 19:24 ` Arnd Bergmann
2010-08-25 19:27 ` Ben Greear
2010-08-25 19:38 ` Hagen Paul Pfeifer
2010-08-25 19:49 ` Ben Greear
2010-08-25 19:59 ` Arnd Bergmann
2010-08-25 20:49 ` Ben Greear
2010-08-26 13:55 ` Arnd Bergmann
2010-08-26 15:33 ` Ben Greear
2010-08-26 17:45 ` Ben Greear
2010-08-27 13:16 ` Arnd Bergmann
2010-08-25 20:44 ` [net-next 1/2] qdisc: Allow qdiscs to provide backpressure up the stack Stephen Hemminger
2010-08-25 20:56 ` Ben Greear
2010-08-26 22:59 ` David Miller
2010-08-27 4:14 ` Ben Greear
2010-08-27 4:34 ` David Miller
2010-08-27 5:22 ` Ben Greear
2010-08-27 5:36 ` David Miller
2010-08-27 5:58 ` Ben Greear
2010-08-27 6:11 ` David Miller
2010-08-27 15:26 ` Ben Greear
2010-08-27 15:59 ` Eric Dumazet
2010-08-27 17:00 ` Ben Greear [this message]
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=4C77EF42.6020600@candelatech.com \
--to=greearb@candelatech.com \
--cc=davem@davemloft.net \
--cc=eric.dumazet@gmail.com \
--cc=netdev@vger.kernel.org \
/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).