[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <200906132200.38034.rusty@rustcorp.com.au>
Date: Sat, 13 Jun 2009 22:00:37 +0930
From: Rusty Russell <rusty@...tcorp.com.au>
To: Herbert Xu <herbert@...dor.apana.org.au>
Cc: netdev@...r.kernel.org, virtualization@...ts.linux-foundation.org,
David Miller <davem@...emloft.net>
Subject: Re: [PATCH 2/4] virtio_net: return NETDEV_TX_BUSY instead of queueing an extra skb.
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.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists