similar to: virtio: wean net driver off NETDEV_TX_BUSY

Herbert tells me that returning NETDEV_TX_BUSY from hard_start_xmit is seen as a poor thing to do; we should cache the packet and stop the queue. Signed-off-by: Rusty Russell <rusty at rustcorp.com.au> --- drivers/net/virtio_net.c | 58 ++++++++++++++++++++++++++++++++--------------- 1 file changed, 40 insertions(+), 18 deletions(-) diff -r 26ba2dd67f46 drivers/net/virtio_net.c ---

Herbert tells me that returning NETDEV_TX_BUSY from hard_start_xmit is seen as a poor thing to do; we should cache the packet and stop the queue. Signed-off-by: Rusty Russell <rusty at rustcorp.com.au> --- drivers/net/virtio_net.c | 58 ++++++++++++++++++++++++++++++++--------------- 1 file changed, 40 insertions(+), 18 deletions(-) diff -r 26ba2dd67f46 drivers/net/virtio_net.c ---

This effectively reverts 99ffc696d10b28580fe93441d627cf290ac4484c "virtio: wean net driver off NETDEV_TX_BUSY". The complexity of queuing an skb (setting a tasklet to re-xmit) is questionable, especially once we get rid of the other reason for the tasklet in the next patch. If the skb won't fit in the tx queue, just return NETDEV_TX_BUSY. It might be frowned upon, but it's

This effectively reverts 99ffc696d10b28580fe93441d627cf290ac4484c "virtio: wean net driver off NETDEV_TX_BUSY". The complexity of queuing an skb (setting a tasklet to re-xmit) is questionable, especially once we get rid of the other reason for the tasklet in the next patch. If the skb won't fit in the tx queue, just return NETDEV_TX_BUSY. It might be frowned upon, but it's

This API change means that virtio_net can tell how much capacity remains for buffers. It's necessarily fuzzy, since VIRTIO_RING_F_INDIRECT_DESC means we can fit any number of descriptors in one, *if* we can kmalloc. Signed-off-by: Rusty Russell <rusty at rustcorp.com.au> Cc: Dinesh Subhraveti <dineshs at us.ibm.com> --- drivers/block/virtio_blk.c | 2 +-

This API change means that virtio_net can tell how much capacity remains for buffers. It's necessarily fuzzy, since VIRTIO_RING_F_INDIRECT_DESC means we can fit any number of descriptors in one, *if* we can kmalloc. Signed-off-by: Rusty Russell <rusty at rustcorp.com.au> Cc: Dinesh Subhraveti <dineshs at us.ibm.com> --- drivers/block/virtio_blk.c | 2 +-

If we fail to transmit a packet, we assume the queue is full and put the skb into last_xmit_skb. However, if more space frees up before we xmit it, we loop, and the result can be transmitting the same skb twice. Fix is simple: set skb to NULL if we've used it in some way, and check before sending. Signed-off-by: Rusty Russell <rusty at rustcorp.com.au> --- drivers/net/virtio_net.c |

If we fail to transmit a packet, we assume the queue is full and put the skb into last_xmit_skb. However, if more space frees up before we xmit it, we loop, and the result can be transmitting the same skb twice. Fix is simple: set skb to NULL if we've used it in some way, and check before sending. Signed-off-by: Rusty Russell <rusty at rustcorp.com.au> --- drivers/net/virtio_net.c |

From c1e1126c39fe107f68adec196d4e558a14540939 Mon Sep 17 00:00:00 2001 From: Anthony Liguori <aliguori@us.ibm.com> Date: Mon, 12 Nov 2007 21:30:26 -0600 Subject: [PATCH] virtio: use an hrtimer for tx coalescing. Not sure why hrtimer's cb_mode only exists with CONFIG_HIGH_RES_TIMERS; that seems like a bug to me. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> ---

From c1e1126c39fe107f68adec196d4e558a14540939 Mon Sep 17 00:00:00 2001 From: Anthony Liguori <aliguori@us.ibm.com> Date: Mon, 12 Nov 2007 21:30:26 -0600 Subject: [PATCH] virtio: use an hrtimer for tx coalescing. Not sure why hrtimer's cb_mode only exists with CONFIG_HIGH_RES_TIMERS; that seems like a bug to me. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> ---

virtio net used to unlink skbs from send queues on error, but ever since 48925e372f04f5e35fec6269127c62b2c71ab794 we do not do this. This causes guest data corruption and crashes with vhost since net core can requeue the skb or free it without it being taken off the list. This patch fixes this by queueing the skb after successfull transmit. Signed-off-by: Michael S. Tsirkin <mst at

virtio net used to unlink skbs from send queues on error, but ever since 48925e372f04f5e35fec6269127c62b2c71ab794 we do not do this. This causes guest data corruption and crashes with vhost since net core can requeue the skb or free it without it being taken off the list. This patch fixes this by queueing the skb after successfull transmit. Signed-off-by: Michael S. Tsirkin <mst at

[PATCH] virtio_net: Delay dropping tx skbs Cc: Mark McLoughlin <markmc at redhat.com>, virtualization at lists.linux-foundation.org, netdev at vger.kernel.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200807151340.00446.rusty at rustcorp.com.au> From: Mark McLoughlin <markmc at redhat.com> On Mon, 2008-05-26 at 17:42 +1000,

[PATCH] virtio_net: Delay dropping tx skbs Cc: Mark McLoughlin <markmc at redhat.com>, virtualization at lists.linux-foundation.org, netdev at vger.kernel.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200807151340.00446.rusty at rustcorp.com.au> From: Mark McLoughlin <markmc at redhat.com> On Mon, 2008-05-26 at 17:42 +1000,

There is a race in virtio_net, dealing with disabling/enabling the callback. I saw the following oops: kernel BUG at /space/kvm/drivers/virtio/virtio_ring.c:218! illegal operation: 0001 [#1] SMP Modules linked in: sunrpc dm_mod CPU: 2 Not tainted 2.6.25-rc1zlive-host-10623-gd358142-dirty #99 Process swapper (pid: 0, task: 000000000f85a610, ksp: 000000000f873c60) Krnl PSW : 0404300180000000

There is a race in virtio_net, dealing with disabling/enabling the callback. I saw the following oops: kernel BUG at /space/kvm/drivers/virtio/virtio_ring.c:218! illegal operation: 0001 [#1] SMP Modules linked in: sunrpc dm_mod CPU: 2 Not tainted 2.6.25-rc1zlive-host-10623-gd358142-dirty #99 Process swapper (pid: 0, task: 000000000f85a610, ksp: 000000000f873c60) Krnl PSW : 0404300180000000

The 'disable_cb' is really just a hint and as such, it's possible for more work to get queued up while callbacks are disabled. Under stress with an SMP guest, this printk triggers very frequently. There is no race here, this is how things are designed to work so let's just remove the printk. Signed-off-by: Anthony Liguori <aliguori at us.ibm.com> Acked-by: Rusty Russell

The 'disable_cb' is really just a hint and as such, it's possible for more work to get queued up while callbacks are disabled. Under stress with an SMP guest, this printk triggers very frequently. There is no race here, this is how things are designed to work so let's just remove the printk. Signed-off-by: Anthony Liguori <aliguori at us.ibm.com> Acked-by: Rusty Russell

Since we want to reset the device to remove them, this is simpler (device is reset for us on driver remove). Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> --- drivers/net/virtio_net.c | 44 +++++++++++++++++++++++++------------------- 1 file changed, 25 insertions(+), 19 deletions(-) diff -r 7e5b3ff06f60 drivers/net/virtio_net.c --- a/drivers/net/virtio_net.c Wed Jan 23 22:53:14

Since we want to reset the device to remove them, this is simpler (device is reset for us on driver remove). Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> --- drivers/net/virtio_net.c | 44 +++++++++++++++++++++++++------------------- 1 file changed, 25 insertions(+), 19 deletions(-) diff -r 7e5b3ff06f60 drivers/net/virtio_net.c --- a/drivers/net/virtio_net.c Wed Jan 23 22:53:14