similar to: [virtio-net][PATCH] Don't arm tx hrtimer with a constant 500us each transmit

From 7354db58f496b06369e57d9be87e9c84db087690 Mon Sep 17 00:00:00 2001 From: Dor Laor <dor.laor@qumranet.com> Date: Wed, 12 Dec 2007 14:52:00 +0200 Subject: [PATCH] Don't arm tx hrtimer with a constant 500us each transmit The current start_xmit sets 500us hrtimer to kick the host. The problem is that if another xmit happens before the timer was fired then the first xmit will have to

From 7354db58f496b06369e57d9be87e9c84db087690 Mon Sep 17 00:00:00 2001 From: Dor Laor <dor.laor@qumranet.com> Date: Wed, 12 Dec 2007 14:52:00 +0200 Subject: [PATCH] Don't arm tx hrtimer with a constant 500us each transmit The current start_xmit sets 500us hrtimer to kick the host. The problem is that if another xmit happens before the timer was fired then the first xmit will have to

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> ---

hrtimer's only have a cb_mode if CONFIG_HIGH_RES_TIMER is enabled. This patch memset()s the tx_timer structure to 0 which has the same effect as setting cb_mode to HRTIMER_CB_SOFTIRQ without requiring CONFIG_HIGH_RES_TIMER to be set. This seems to be what other drivers do. Signed-off-by: Anthony Liguori <aliguori@us.ibm.com> diff --git a/drivers/net/virtio_net.c

hrtimer's only have a cb_mode if CONFIG_HIGH_RES_TIMER is enabled. This patch memset()s the tx_timer structure to 0 which has the same effect as setting cb_mode to HRTIMER_CB_SOFTIRQ without requiring CONFIG_HIGH_RES_TIMER to be set. This seems to be what other drivers do. Signed-off-by: Anthony Liguori <aliguori@us.ibm.com> diff --git a/drivers/net/virtio_net.c

Hello all: This seires is an update of last version of multiqueue support to add multiqueue capability to both tap and virtio-net. Some kinds of tap backends has (macvatp in linux) or would (tap) support multiqueue. In such kind of tap backend, each file descriptor of a tap is a qeueu and ioctls were prodived to attach an exist tap file descriptor to the tun/tap device. So the patch let qemu to

Hello all: This seires is an update of last version of multiqueue support to add multiqueue capability to both tap and virtio-net. Some kinds of tap backends has (macvatp in linux) or would (tap) support multiqueue. In such kind of tap backend, each file descriptor of a tap is a qeueu and ioctls were prodived to attach an exist tap file descriptor to the tun/tap device. So the patch let qemu to

Hello all: This seires is an update of last version of multiqueue support to add multiqueue capability to both tap and virtio-net. Some kinds of tap backends has (macvatp in linux) or would (tap) support multiqueue. In such kind of tap backend, each file descriptor of a tap is a qeueu and ioctls were prodived to attach an exist tap file descriptor to the tun/tap device. So the patch let qemu to

Hello all: This seires is an update of last version of multiqueue support to add multiqueue capability to both tap and virtio-net. Some kinds of tap backends has (macvatp in linux) or would (tap) support multiqueue. In such kind of tap backend, each file descriptor of a tap is a qeueu and ioctls were prodived to attach an exist tap file descriptor to the tun/tap device. So the patch let qemu to

Now that we have a host timer based tx wakeup it waits for 64 packets or timeout before processing them. This might cause the guest to run out of tx buffers while the host holds them up. This is a temporal solution to quickly bring back performance to 800mbps. But a better fix will soon be sent (its not the only problem). Signed-off-by: Dor Laor <dor.laor@qumranet.com> ---

Now that we have a host timer based tx wakeup it waits for 64 packets or timeout before processing them. This might cause the guest to run out of tx buffers while the host holds them up. This is a temporal solution to quickly bring back performance to 800mbps. But a better fix will soon be sent (its not the only problem). Signed-off-by: Dor Laor <dor.laor@qumranet.com> ---

From 20a01e0c24f47e9805a88bebc9310163f99b5e99 Mon Sep 17 00:00:00 2001 From: Dor Laor <dor.laor@qumranet.com> Date: Sun, 16 Dec 2007 23:35:35 +0200 Subject: [PATCH] Handle module unload Add the device release function. Signed-off-by: Dor Laor <dor.laor@qumranet.com> --- drivers/virtio/virtio.c | 7 +++++++ drivers/virtio/virtio_pci.c | 7 +++++++ 2 files changed, 14

From 20a01e0c24f47e9805a88bebc9310163f99b5e99 Mon Sep 17 00:00:00 2001 From: Dor Laor <dor.laor@qumranet.com> Date: Sun, 16 Dec 2007 23:35:35 +0200 Subject: [PATCH] Handle module unload Add the device release function. Signed-off-by: Dor Laor <dor.laor@qumranet.com> --- drivers/virtio/virtio.c | 7 +++++++ drivers/virtio/virtio_pci.c | 7 +++++++ 2 files changed, 14

From 9f5a551d7e2a00eb019b158f8f3130e8176ec27c Mon Sep 17 00:00:00 2001 From: Dor Laor <dor.laor@qumranet.com> Date: Mon, 17 Dec 2007 01:40:15 +0200 Subject: [PATCH] Update all status fields on driver unload Both VIRTIO_CONFIG_S_DRIVER and VIRTIO_CONFIG_S_DRIVER_OK should be cleaned upon driver unload. Signed-off-by: Dor Laor <dor.laor@qumranet.com> --- drivers/virtio/virtio.c | 3

From 9f5a551d7e2a00eb019b158f8f3130e8176ec27c Mon Sep 17 00:00:00 2001 From: Dor Laor <dor.laor@qumranet.com> Date: Mon, 17 Dec 2007 01:40:15 +0200 Subject: [PATCH] Update all status fields on driver unload Both VIRTIO_CONFIG_S_DRIVER and VIRTIO_CONFIG_S_DRIVER_OK should be cleaned upon driver unload. Signed-off-by: Dor Laor <dor.laor@qumranet.com> --- drivers/virtio/virtio.c | 3

From f244bcad756c4f761627557bb7f315b1d8f22fb2 Mon Sep 17 00:00:00 2001 From: Dor Laor <dor.laor@qumranet.com> Date: Thu, 20 Dec 2007 13:26:30 +0200 Subject: [PATCH] [VIRTIO-NET] Rx performance improvement The current performance are not good enough, the problem lies in qemu tap handling code that caused to pass packets one at a time and also to copy them to a temporal buffer. This patch

From f244bcad756c4f761627557bb7f315b1d8f22fb2 Mon Sep 17 00:00:00 2001 From: Dor Laor <dor.laor@qumranet.com> Date: Thu, 20 Dec 2007 13:26:30 +0200 Subject: [PATCH] [VIRTIO-NET] Rx performance improvement The current performance are not good enough, the problem lies in qemu tap handling code that caused to pass packets one at a time and also to copy them to a temporal buffer. This patch

skb is only NULL the first time around: it's more correct to test for being under-budget. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> diff -r 2a94425ac7d5 drivers/net/virtio_net.c --- a/drivers/net/virtio_net.c Thu Nov 15 13:47:28 2007 +1100 +++ b/drivers/net/virtio_net.c Thu Nov 15 23:10:44 2007 +1100 @@ -198,8 +198,8 @@ again: if (vi->num < vi->max / 2)

skb is only NULL the first time around: it's more correct to test for being under-budget. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> diff -r 2a94425ac7d5 drivers/net/virtio_net.c --- a/drivers/net/virtio_net.c Thu Nov 15 13:47:28 2007 +1100 +++ b/drivers/net/virtio_net.c Thu Nov 15 23:10:44 2007 +1100 @@ -198,8 +198,8 @@ again: if (vi->num < vi->max / 2)