All of lore.kernel.org
 help / color / mirror / Atom feed
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>
Subject: Re: [PATCH 2/4] virtio_net: return NETDEV_TX_BUSY instead of queueing an extra skb.
Date: Sat, 13 Jun 2009 22:00:37 +0930	[thread overview]
Message-ID: <200906132200.38034.rusty@rustcorp.com.au> (raw)
In-Reply-To: <20090608052247.GA19826@gondor.apana.org.au>

On Mon, 8 Jun 2009 02:52:47 pm Herbert Xu wrote:
> No you've misunderstood my complaint.  I'm not trying to get you
> to replace NETDEV_TX_BUSY by the equally abhorrent queue in the
> driver, I'm saying that you should stop the queue before you get
> a packet that overflows by looking at the amount of free queue
> space after transmitting each packet.
>
> For most drivers this is easy to do.  What's so different about
> virtio-net that makes this impossible?

If we assume the worst case; ie. that the next packet will use max frags, we 
get close (make add_buf take a "unsigned int *descs_left" arg).  Obviously, 
this is suboptimal use of the ring.  We can still get kmalloc failures w/ 
indirect descriptors, but dropping a packet then isn't a huge deal IMHO.

But re your comment that the 67 drivers using TX_BUSY are doing it because of 
driver bugs, that's hard to believe.  It either hardly ever happens (in which 
case just drop the packet), or it happens (in which case we should handle it 
correctly).

TX_BUSY makes me queasy:  you haven't convinced me it shouldn't be killed or 
fixed.

Did you look at my attempted fix?
Rusty.









  reply	other threads:[~2009-06-13 12:30 UTC|newest]

Thread overview: 44+ 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  8:07 ` Mark McLoughlin
2009-06-02 14:04   ` Rusty Russell
2009-06-02 14:04   ` Rusty Russell
2009-06-02  9:05 ` Herbert Xu
2009-06-02  9:05 ` Herbert Xu
2009-06-02 13:55   ` Rusty Russell
2009-06-02 23:45     ` Herbert Xu
2009-06-02 23:45     ` Herbert Xu
2009-06-03  3:17       ` Rusty Russell
2009-06-03  3:17       ` Rusty Russell
2009-06-08  5:22         ` Herbert Xu
2009-06-08  5:22         ` Herbert Xu
2009-06-13 12:30           ` Rusty Russell [this message]
2009-06-14  6:45             ` Herbert Xu
2009-06-14  6:45             ` Herbert Xu
2009-06-18  7:17               ` Rusty Russell
2009-06-18  7:17               ` Rusty Russell
2009-06-18  7:34                 ` Herbert Xu
2009-06-19  3:37                   ` Rusty Russell
2009-06-19  3:37                   ` Rusty Russell
2009-06-19  4:36                     ` Herbert Xu
2009-06-19  4:36                     ` Herbert Xu
2009-06-19 13:50                       ` Rusty Russell
2009-06-19 13:50                       ` Rusty Russell
2009-06-19 14:10                         ` Herbert Xu
2009-06-19 14:10                         ` Herbert Xu
2009-06-22  2:39                           ` Rusty Russell
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 13:41                           ` Krishna Kumar2
2009-06-22 18:25                           ` Matt Carlson
2009-06-23  2:54                             ` Herbert Xu
2009-06-23  2:54                             ` Herbert Xu
2009-06-22 18:25                           ` Matt Carlson
2009-06-22  7:34                         ` Herbert Xu
2009-06-22  5:46                       ` Krishna Kumar2
2009-06-18  7:34                 ` Herbert Xu
2009-06-13 12:30           ` Rusty Russell
2009-06-02 13:55   ` Rusty Russell
  -- strict thread matches above, loose matches on Subject: below --
2009-05-29 14:16 Rusty Russell

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=200906132200.38034.rusty@rustcorp.com.au \
    --to=rusty@rustcorp.com.au \
    --cc=davem@davemloft.net \
    --cc=herbert@gondor.apana.org.au \
    --cc=netdev@vger.kernel.org \
    --cc=virtualization@lists.linux-foundation.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.