similar to: [PATCH net-next V2 0/2] virtio-net: don't busy poll for cvq command

Hi all: The code used to busy poll for cvq command which turns out to have several side effects: 1) infinite poll for buggy devices 2) bad interaction with scheduler So this series tries to use sleep + timeout instead of busy polling. Please review. Thanks Changes since RFC: - switch to use BAD_RING in virtio_break_device() - check virtqueue_is_broken() after being woken up - use

Hi all: The code used to busy poll for cvq command which turns out to have several side effects: 1) infinite poll for buggy devices 2) bad interaction with scheduler So this series tries to use cond_resched() in the waiting loop. Before doing this we need first make sure the cvq command is not executed in atomic environment, so we need first convert rx mode handling to a workqueue. Please

Hi all: The code used to busy poll for cvq command which turns out to have several side effects: 1) infinite poll for buggy devices 2) bad interaction with scheduler So this series tries to use cond_resched() in the waiting loop. Before doing this we need first make sure the cvq command is not executed in atomic environment, so we need first convert rx mode handling to a workqueue. Note that,

On Fri, Apr 14, 2023 at 3:21?PM Michael S. Tsirkin <mst at redhat.com> wrote: > > On Fri, Apr 14, 2023 at 01:04:15PM +0800, Jason Wang wrote: > > Forget to cc netdev, adding. > > > > On Fri, Apr 14, 2023 at 12:25?AM Michael S. Tsirkin <mst at redhat.com> wrote: > > > > > > On Thu, Apr 13, 2023 at 02:40:26PM +0800, Jason Wang wrote: > >

This patch convert rx mode setting to be done in a workqueue, this is a must for allow to sleep when waiting for the cvq command to response since current code is executed under addr spin lock. Signed-off-by: Jason Wang <jasowang at redhat.com> --- Changes since V1: - use RTNL to synchronize rx mode worker --- drivers/net/virtio_net.c | 55 +++++++++++++++++++++++++++++++++++++--- 1 file

On Thu, 13 Apr 2023 14:40:27 +0800, Jason Wang <jasowang at redhat.com> wrote: > We used to busy waiting on the cvq command this tends to be > problematic since there no way for to schedule another process which > may serve for the control virtqueue. This might be the case when the > control virtqueue is emulated by software. This patch switches to use > completion to allow

On Thu, Apr 13, 2023 at 3:31?PM Xuan Zhuo <xuanzhuo at linux.alibaba.com> wrote: > > On Thu, 13 Apr 2023 14:40:27 +0800, Jason Wang <jasowang at redhat.com> wrote: > > We used to busy waiting on the cvq command this tends to be > > problematic since there no way for to schedule another process which > > may serve for the control virtqueue. This might be the case

From: Andy Lutomirski <luto at amacapital.net> Once virtio starts using the DMA API, we won't be able to safely DMA from the stack. virtio-net does a couple of config DMA requests from small stack buffers -- switch to using dynamically-allocated memory. This should have no effect on any performance-critical code paths. Cc: netdev at vger.kernel.org Cc: "Michael S. Tsirkin"

From: Andy Lutomirski <luto at amacapital.net> Once virtio starts using the DMA API, we won't be able to safely DMA from the stack. virtio-net does a couple of config DMA requests from small stack buffers -- switch to using dynamically-allocated memory. This should have no effect on any performance-critical code paths. Cc: netdev at vger.kernel.org Cc: "Michael S. Tsirkin"

The virtio_net driver never sends the multicast address list to the host. This is because send command takes a pointer to scatter list to send but only inserts that one entry into the outgoing scatter list. This bug has been there since: commit f565a7c259d71cc186753653d978c646d2354b36 Author: Alex Williamson <alex.williamson at hp.com> Date: Wed Feb 4 09:02:45 2009 +0000 virtio_net:

The virtio_net driver never sends the multicast address list to the host. This is because send command takes a pointer to scatter list to send but only inserts that one entry into the outgoing scatter list. This bug has been there since: commit f565a7c259d71cc186753653d978c646d2354b36 Author: Alex Williamson <alex.williamson at hp.com> Date: Wed Feb 4 09:02:45 2009 +0000 virtio_net:

This switches virtio to use the DMA API unconditionally. I'm sure it breaks things, but it seems to work on x86 using virtio-pci, with and without Xen, and using both the modern 1.0 variant and the legacy variant. Changes from v2: - Fix really embarrassing bug. This version actually works. Changes from v1: - Fix an endian conversion error causing a BUG to hit. - Fix a DMA ordering issue

This switches virtio to use the DMA API unconditionally. I'm sure it breaks things, but it seems to work on x86 using virtio-pci, with and without Xen, and using both the modern 1.0 variant and the legacy variant. Changes from v2: - Fix really embarrassing bug. This version actually works. Changes from v1: - Fix an endian conversion error causing a BUG to hit. - Fix a DMA ordering issue

From: Amos Kong <akong at redhat.com> Currenly mac is programmed byte by byte. This means that we have an intermediate step where mac is wrong. Second patch introduced a new vq control command to set mac address in one time. Amos Kong (2): move virtnet_send_command() above virtnet_set_mac_address() virtio-net: introduce a new control to set macaddr drivers/net/virtio_net.c |

From: Amos Kong <akong at redhat.com> Currenly mac is programmed byte by byte. This means that we have an intermediate step where mac is wrong. Second patch introduced a new vq control command to set mac address in one time. Amos Kong (2): move virtnet_send_command() above virtnet_set_mac_address() virtio-net: introduce a new control to set macaddr drivers/net/virtio_net.c |

From: Amos Kong <akong at redhat.com> Currenly mac is programmed byte by byte. This means that we have an intermediate step where mac is wrong. Second patch introduced a new vq control command to set mac address in one time. V2: check return of sending command, delay eth_mac_addr() Amos Kong (2): move virtnet_send_command() above virtnet_set_mac_address() virtio-net: introduce a new

From: Amos Kong <akong at redhat.com> Currenly mac is programmed byte by byte. This means that we have an intermediate step where mac is wrong. Second patch introduced a new vq control command to set mac address in one time. V2: check return of sending command, delay eth_mac_addr() Amos Kong (2): move virtnet_send_command() above virtnet_set_mac_address() virtio-net: introduce a new

Hi Jason, On 4/13/23 08:40, Jason Wang wrote: > Hi all: > > The code used to busy poll for cvq command which turns out to have > several side effects: > > 1) infinite poll for buggy devices > 2) bad interaction with scheduler > > So this series tries to use sleep instead of busy polling. In this > version, I take a step back: the hardening part is not implemented

When sending control commands, virtio net sets up several buffers for DMA. The buffers are all part of the net device which means it's actually allocated by kvmalloc so it's in theory (on extreme memory pressure) possible to get a vmalloc'ed buffer which on some platforms means we can't DMA there. Fix up by moving the DMA buffers into a separate structure. Reported-by: Mikulas

Use per-cpu variables to maintain 64 bit statistics. Compile tested only. Signed-off-by: Stephen Hemminger <shemminger at vyatta.com> --- a/drivers/net/virtio_net.c 2011-06-14 15:18:46.448596355 -0400 +++ b/drivers/net/virtio_net.c 2011-06-15 09:54:22.914426067 -0400 @@ -40,6 +40,15 @@ module_param(gso, bool, 0444); #define VIRTNET_SEND_COMMAND_SG_MAX 2 +struct virtnet_stats { +