From: Rusty Russell <rusty@rustcorp•com.au>
To: Herbert Xu <herbert@gondor•apana.org.au>
Cc: netdev@vger•kernel.org,
virtualization@lists•linux-foundation.org,
David Miller <davem@davemloft•net>,
Matt Carlson <mcarlson@broadcom•com>
Subject: Re: [PATCH 2/4] virtio_net: return NETDEV_TX_BUSY instead of queueing an extra skb.
Date: Fri, 19 Jun 2009 23:20:44 +0930 [thread overview]
Message-ID: <200906192320.44904.rusty@rustcorp.com.au> (raw)
In-Reply-To: <20090619043613.GA15163@gondor.apana.org.au>
On Fri, 19 Jun 2009 02:06:13 pm Herbert Xu wrote:
> On Fri, Jun 19, 2009 at 01:07:19PM +0930, Rusty Russell wrote:
> > You didn't comment on my patch which tried to fix NETDEV_TX_BUSY tho?
> However, that is still wrong for many packet schedulers. For
> example, if the requeued packet is of a lower priority, and a
> higher priority packet comes along, we want the higher priority
> packet to preempt the requeued packet. Right now it just doesn't
> happen.
>
> This is not as trivial as it seems because on a busy host this can
> happen many times a second. With TX_BUSY the QoS guarantees are
> simply not workable.
Your use of the word guarantee here indicates an idealized concept of QoS
which cannot exist on any NIC which has a queue. We should try to approach
the ideal, but understand we cannot reach it.
AFAICT, having a non-resortable head entry in the queue is exactly like having
one-packet slightly longer queue on the NIC. A little further from the ideal,
but actually *less* damaging to QoS idea unless it happens on every second
packet.
On the other hand, we're underutilizing the queue to avoid it. I find that a
little embarrassing.
> > We provided an API, people used it. Constantly trying to disclaim our
> > responsibility for the resulting mess makes me fucking ANGRY.
>
> Where have I disclaimed responsibility? If we were doing that
> then we wouldn't be having this discussion.
"Anyway, I don't think we should reshape our APIs based on how
broken the existing users are."
Perhaps I was reading too much into it, but the implication that we should
blame the driver authors for writing their drivers in what I consider to be
the most straightforward and efficient way.
I feel we're being horribly deceptive by giving them a nice API, and upon
review, telling them "don't use that". And it's been ongoing for far too
long.
> In fact queueing it in the driver is just as bad as return TX_BUSY!
Agreed (modulo the tcpdump issue). And worse, because it's ugly and complex!
Thanks,
Rusty.
next prev parent reply other threads:[~2009-06-19 13:50 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-05-29 14:16 [PATCH 2/4] virtio_net: return NETDEV_TX_BUSY instead of queueing an extra skb Rusty Russell
2009-06-02 8:07 ` Mark McLoughlin
2009-06-02 14:04 ` Rusty Russell
2009-06-02 9:05 ` Herbert Xu
2009-06-02 13:55 ` Rusty Russell
2009-06-02 23:45 ` Herbert Xu
2009-06-03 3:17 ` Rusty Russell
2009-06-08 5:22 ` Herbert Xu
2009-06-13 12:30 ` Rusty Russell
2009-06-14 6:45 ` Herbert Xu
2009-06-18 7:17 ` Rusty Russell
2009-06-18 7:34 ` Herbert Xu
2009-06-19 3:37 ` Rusty Russell
2009-06-19 4:36 ` Herbert Xu
2009-06-19 13:50 ` Rusty Russell [this message]
2009-06-19 14:10 ` Herbert Xu
2009-06-22 2:39 ` Rusty Russell
2009-06-22 5:46 ` Krishna Kumar2
2009-06-22 7:34 ` Herbert Xu
2009-06-22 13:41 ` Krishna Kumar2
2009-06-22 18:25 ` Matt Carlson
2009-06-23 2:54 ` Herbert Xu
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=200906192320.44904.rusty@rustcorp.com.au \
--to=rusty@rustcorp$(echo .)com.au \
--cc=davem@davemloft$(echo .)net \
--cc=herbert@gondor$(echo .)apana.org.au \
--cc=mcarlson@broadcom$(echo .)com \
--cc=netdev@vger$(echo .)kernel.org \
--cc=virtualization@lists$(echo .)linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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