search for: guest_csum

From: Thomas Huth <thuth at linux.vnet.ibm.com> Date: Tue, 27 Aug 2013 17:09:02 +0200 > If the VIRTIO_NET_F_GUEST_CSUM virtio feature is available, the guest > does not have to calculate the checksums on all received packets. This > is pretty much the same feature as RX checksum offloading on real > network cards, so the virtio-net driver should report this by setting > the NETIF_F_RXCSUM flag. When the...

If the VIRTIO_NET_F_GUEST_CSUM virtio feature is available, the guest does not have to calculate the checksums on all received packets. This is pretty much the same feature as RX checksum offloading on real network cards, so the virtio-net driver should report this by setting the NETIF_F_RXCSUM flag. When the user now runs &quot...

If the VIRTIO_NET_F_GUEST_CSUM virtio feature is available, the guest does not have to calculate the checksums on all received packets. This is pretty much the same feature as RX checksum offloading on real network cards, so the virtio-net driver should report this by setting the NETIF_F_RXCSUM flag. When the user now runs &quot...

...ical machine. Each VM has two VCPUs and vhost enabled. All VMs and vhost threads run in a single 4 CPU cgroup cpuset, using cgroups to ensure that other processes in the system will not be scheduled on the benchmark CPUs. Transmit offloads and mergeable receive buffers are enabled, but guest_tso4 / guest_csum are explicitly disabled to force MTU-sized packets on the receiver. next-net trunk before 2613af0ed18a (PAGE_SIZE buf): 3861.08Gb/s net-next trunk (MTU 1500- packet uses two buf due to size bug): 4076.62Gb/s net-next trunk (MTU 1480- packet fits in one buf): 6301.34Gb/s net-next trunk w/ size fix...

...ical machine. Each VM has two VCPUs and vhost enabled. All VMs and vhost threads run in a single 4 CPU cgroup cpuset, using cgroups to ensure that other processes in the system will not be scheduled on the benchmark CPUs. Transmit offloads and mergeable receive buffers are enabled, but guest_tso4 / guest_csum are explicitly disabled to force MTU-sized packets on the receiver. next-net trunk before 2613af0ed18a (PAGE_SIZE buf): 3861.08Gb/s net-next trunk (MTU 1500- packet uses two buf due to size bug): 4076.62Gb/s net-next trunk (MTU 1480- packet fits in one buf): 6301.34Gb/s net-next trunk w/ size fix...

We have found it useful to be able to set the linkspeed and duplex settings from the host-side for virtio_net. This obviates the need for guest changes and settings for these fields, and does not require custom ethtool commands for virtio_net. The ability to set linkspeed and

...0x03' function='0x0'/> </interface> 2. after start the vm, check the qemu command line: *-netdev tap,fds=26:28:29:30:31,id=hostnet0,vhost=on,vhostfds=32:33:34:35:36* -device virtio-net-pci,csum=off,gso=off,host_tso4=off,host_tso6=off,host_ecn=off,host_ufo=off,mrg_rxbuf=off,guest_csum=off,guest_tso4=off,guest_tso6=off,guest_ecn=off,guest_ufo=off, *mq=on,vectors=12,rx_queue_size=512,tx_queue_size=512* ,netdev=hostnet0,id=net0,mac=52:54:00:00:b5:99,bus=pci.0,addr=0x3 3. check on guest # ethtool -g eth0 Ring parameters for eth0: Pre-set maximums: RX: *512 ==> rx_queue_size work...

We don't disable VIRTIO_NET_F_GUEST_CSUM if XDP was set. This means we can receive partial csumed packets with metadata kept in the vnet_hdr. This may have several side effects: - It could be overridden by header adjustment, thus is might be not correct after XDP processing. - There's no way to pass such metadata information throug...

We don't disable VIRTIO_NET_F_GUEST_CSUM if XDP was set. This means we can receive partial csumed packets with metadata kept in the vnet_hdr. This may have several side effects: - It could be overridden by header adjustment, thus is might be not correct after XDP processing. - There's no way to pass such metadata information throug...

...t; > </interface> > > 2. after start the vm, check the qemu command line: > *-netdev > tap,fds=26:28:29:30:31,id=hostnet0,vhost=on,vhostfds=32:33:34:35:36* > -device virtio-net-pci,csum=off,gso=off,host_tso4=off,host_tso6= > off,host_ecn=off,host_ufo=off,mrg_rxbuf=off,guest_csum=off, > guest_tso4=off,guest_tso6=off,guest_ecn=off,guest_ufo=off, > *mq=on,vectors=12,rx_queue_size=512,tx_queue_size=512*,netdev= > hostnet0,id=net0,mac=52:54:00:00:b5:99,bus=pci.0,addr=0x3 > > 3. check on guest > # ethtool -g eth0 > Ring parameters for eth0: > Pre-set maxi...

...check the qemu command line: >>>>> *-netdev >>>>> tap,fds=26:28:29:30:31,id=hostnet0,vhost=on,vhostfds=32:33:34:35:36* >>>>> -device virtio-net-pci,csum=off,gso=off,host_tso4=off,host_tso6=off, >>>>> host_ecn=off,host_ufo=off,mrg_rxbuf=off,guest_csum=off,guest >>>>> _tso4=off,guest_tso6=off,guest_ecn=off,guest_ufo=off, >>>>> *mq=on,vectors=12,rx_queue_size=512,tx_queue_size=512*,netdev=hostnet >>>>> 0,id=net0,mac=52:54:00:00:b5:99,bus=pci.0,addr=0x3 >>>>> >>>>> 3. check...

We drop csumed packet when do XDP for packets. This breaks XDP_PASS when GUEST_CSUM is supported. Fix this by allowing csum flag to be set. With this patch, simple TCP works for XDP_PASS. Cc: John Fastabend <john.r.fastabend at intel.com> Signed-off-by: Jason Wang <jasowang at redhat.com> --- drivers/net/virtio_net.c | 4 ++-- 1 file changed, 2 insertions(+), 2 delet...

We don't support partial csumed packet since its metadata will be lost or incorrect during XDP processing. So fail the XDP set if guest_csum feature is negotiated. Fixes: f600b6905015 ("virtio_net: Add XDP support") Reported-by: Jesper Dangaard Brouer <brouer at redhat.com> Cc: Jesper Dangaard Brouer <brouer at redhat.com> Cc: Pavel Popa <pashinho1990 at gmail.com> Cc: David Ahern <dsahern at gmail.com&gt...

...M has two VCPUs and > vhost enabled. All VMs and vhost threads run in a single 4 CPU cgroup > cpuset, using cgroups to ensure that other processes in the system will not > be scheduled on the benchmark CPUs. Transmit offloads and mergeable receive > buffers are enabled, but guest_tso4 / guest_csum are explicitly disabled to > force MTU-sized packets on the receiver. > > next-net trunk before 2613af0ed18a (PAGE_SIZE buf): 3861.08Gb/s > net-next trunk (MTU 1500- packet uses two buf due to size bug): 4076.62Gb/s > net-next trunk (MTU 1480- packet fits in one buf): 6301.34Gb/s &g...

...r start the vm, check the qemu command line: >>>> *-netdev >>>> tap,fds=26:28:29:30:31,id=hostnet0,vhost=on,vhostfds=32:33:34:35:36* >>>> -device virtio-net-pci,csum=off,gso=off,host_tso4=off,host_tso6=off, >>>> host_ecn=off,host_ufo=off,mrg_rxbuf=off,guest_csum=off,guest >>>> _tso4=off,guest_tso6=off,guest_ecn=off,guest_ufo=off, >>>> *mq=on,vectors=12,rx_queue_size=512,tx_queue_size=512*,netdev=hostnet >>>> 0,id=net0,mac=52:54:00:00:b5:99,bus=pci.0,addr=0x3 >>>> >>>> 3. check on guest >>&gt...

...ical machine. Each VM has two VCPUs and vhost enabled. All VMs and vhost threads run in a single 4 CPU cgroup cpuset, using cgroups to ensure that other processes in the system will not be scheduled on the benchmark CPUs. Transmit offloads and mergeable receive buffers are enabled, but guest_tso4 / guest_csum are explicitly disabled to force MTU-sized packets on the receiver. next-net trunk before 2613af0ed18a (PAGE_SIZE buf): 3861.08Gb/s net-next trunk (MTU 1500- packet uses two buf due to size bug): 4076.62Gb/s net-next trunk (MTU 1480- packet fits in one buf): 6301.34Gb/s net-next trunk w/ size fix...

...ical machine. Each VM has two VCPUs and vhost enabled. All VMs and vhost threads run in a single 4 CPU cgroup cpuset, using cgroups to ensure that other processes in the system will not be scheduled on the benchmark CPUs. Transmit offloads and mergeable receive buffers are enabled, but guest_tso4 / guest_csum are explicitly disabled to force MTU-sized packets on the receiver. next-net trunk before 2613af0ed18a (PAGE_SIZE buf): 3861.08Gb/s net-next trunk (MTU 1500- packet uses two buf due to size bug): 4076.62Gb/s net-next trunk (MTU 1480- packet fits in one buf): 6301.34Gb/s net-next trunk w/ size fix...

...ommand line: >>>>>> *-netdev >>>>>> tap,fds=26:28:29:30:31,id=hostnet0,vhost=on,vhostfds=32:33:34:35:36* >>>>>> -device virtio-net-pci,csum=off,gso=off,host_tso4=off,host_tso6=off, >>>>>> host_ecn=off,host_ufo=off,mrg_rxbuf=off,guest_csum=off,guest >>>>>> _tso4=off,guest_tso6=off,guest_ecn=off,guest_ufo=off, >>>>>> *mq=on,vectors=12,rx_queue_size=512,tx_queue_size=512*,netdev=hostnet >>>>>> 0,id=net0,mac=52:54:00:00:b5:99,bus=pci.0,addr=0x3 >>>>>> >>>&g...

This patchset is pre-requisite to export and provision device config attributes and features for vdpa live migration, in a way backward and forward compatibility can be retained. The follow up work [1] will need to be built around the new feature provisioning uAPI, with which it's easier to formalize migration compatibility support at the driver level. Thanks, -Siwei [1] [PATCH v3 0/4] vDPA:

Hi Michal, What I found was that when I restarted the machine and did a virsh edit command to see the xml config, I see that it is was not actually changed. This suggests why I saw 256 again after restarting. So now I tried again to edit the xml via virsh edit command and used the following to set the parameters. <driver name='qemu' txmode='iothread' ioeventfd='on'