similar to: [PATCH] Use memset(0) instead of setting cb_mode explicitly

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

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)

commit 763769621d271d92204ed27552d75448587c1ac0 Author: Dor Laor <dor.laor@qumranet.com> Date: Wed Dec 12 14:52:00 2007 +0200 [virtio-net][PATCH] Don't arm tx hrtimer with a constant 50us 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

commit 763769621d271d92204ed27552d75448587c1ac0 Author: Dor Laor <dor.laor@qumranet.com> Date: Wed Dec 12 14:52:00 2007 +0200 [virtio-net][PATCH] Don't arm tx hrtimer with a constant 50us 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

The virtio_net driver is complicated by the two methods of freeing old xmit buffers (in addition to freeing old ones at the start of the xmit path). The original code used a 1/10 second timer attached to xmit_free(), reset on every xmit. Before we orphaned skbs on xmit, the transmitting userspace could block with a full socket until the timer fired, the skb destructor was called, and they were

The virtio_net driver is complicated by the two methods of freeing old xmit buffers (in addition to freeing old ones at the start of the xmit path). The original code used a 1/10 second timer attached to xmit_free(), reset on every xmit. Before we orphaned skbs on xmit, the transmitting userspace could block with a full socket until the timer fired, the skb destructor was called, and they were

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: Mark McLoughlin <markmc at redhat.com> hdr->csum_start is the offset from the start of the ethernet header to the transport layer checksum field. skb->csum_start is the offset from skb->head. skb_partial_csum_set() assumes that skb->data points to the ethernet header - i.e. it computes skb->csum_start by adding the headroom to hdr->csum_start. Since

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

On Thursday 01 May 2008 00:31:46 Mark McLoughlin wrote: > virtio_net currently only frees old transmit skbs just > before queueing new ones. If the queue is full, it then > enables interrupts and waits for notification that more > work has been performed. Hi Mark, This patch is fine, but it's better to do it from skb_xmit_done(). Of course, this is usually called from an

On Thursday 01 May 2008 00:31:46 Mark McLoughlin wrote: > virtio_net currently only frees old transmit skbs just > before queueing new ones. If the queue is full, it then > enables interrupts and waits for notification that more > work has been performed. Hi Mark, This patch is fine, but it's better to do it from skb_xmit_done(). Of course, this is usually called from an

The kvmalloc function tries to use kmalloc and falls back to vmalloc if kmalloc fails. Unfortunatelly, some kernel code has bugs - it uses kvmalloc and then uses DMA-API on the returned memory or frees it with kfree. Such bugs were found in the virtio-net driver, dm-integrity or RHEL7 powerpc-specific code. These bugs are hard to reproduce because kvmalloc falls back to vmalloc only if memory is

On Tue, 24 Apr 2018, Michal Hocko wrote: > On Mon 23-04-18 20:06:16, Mikulas Patocka wrote: > [...] > > @@ -404,6 +405,12 @@ void *kvmalloc_node(size_t size, gfp_t f > > */ > > WARN_ON_ONCE((flags & GFP_KERNEL) != GFP_KERNEL); > > > > +#ifdef CONFIG_DEBUG_SG > > + /* Catch bugs when the caller uses DMA API on the result of kvmalloc. */ >

fwd_cnt is written with rx_lock, so we should read it using the same spinlock also if we are in the TX path. Move also buf_alloc under rx_lock and add a missing locking when we modify it. Signed-off-by: Stefano Garzarella <sgarzare at redhat.com> --- include/linux/virtio_vsock.h | 2 +- net/vmw_vsock/virtio_transport_common.c | 6 ++++-- 2 files changed, 5 insertions(+), 3