similar to: Ufo Aftershock

Hello everyone, I would like to ask a question regarding to disable UFO of virtio vNIC in my guest. I have read the document at https://libvirt.org/formatdomain.html *host* The csum, gso, tso4, tso6, ecn and ufo attributes with possible values on and off can be used to turn off host offloading options. By default, the supported offloads are enabled by QEMU. *Since 1.2.9 (QEMU only)* The

On Wed, 2014-11-19 at 11:14 +0200, Michael S. Tsirkin wrote: > On Thu, Oct 30, 2014 at 06:27:12PM +0000, Ben Hutchings wrote: > > IPv6 does not allow fragmentation by routers, so there is no > > fragmentation ID in the fixed header. UFO for IPv6 requires the ID to > > be passed separately, but there is no provision for this in the virtio > > net protocol. > >

On Wed, 2014-11-19 at 11:14 +0200, Michael S. Tsirkin wrote: > On Thu, Oct 30, 2014 at 06:27:12PM +0000, Ben Hutchings wrote: > > IPv6 does not allow fragmentation by routers, so there is no > > fragmentation ID in the fixed header. UFO for IPv6 requires the ID to > > be passed separately, but there is no provision for this in the virtio > > net protocol. > >

IPv6 does not allow fragmentation by routers, so there is no fragmentation ID in the fixed header. UFO for IPv6 requires the ID to be passed separately, but there is no provision for this in the virtio net protocol. Until recently our software implementation of UFO/IPv6 generated a new ID, but this was a bug. Now we will use ID=0 for any UFO/IPv6 packet passed through a tap, which is even

IPv6 does not allow fragmentation by routers, so there is no fragmentation ID in the fixed header. UFO for IPv6 requires the ID to be passed separately, but there is no provision for this in the virtio net protocol. Until recently our software implementation of UFO/IPv6 generated a new ID, but this was a bug. Now we will use ID=0 for any UFO/IPv6 packet passed through a tap, which is even

I was running the previous version of UFO, the 3.3 one that was based on Swift 1.4.8. Now there is a 3.3.1 based on Swift 1.7.4. The config that I used last time to enable S3 isn't working with the new one, just updated yesterday using yum. I was using tempauth in the old version and I'm still using tempauth. I have a CentOS 6 system and a Fedora 18 system with UFO on them. The

There are several ways that VMs can take advantage of UFO and get the host to do fragmentation for them: drivers/net/macvtap.c: gso_type = SKB_GSO_UDP; drivers/net/tun.c: skb_shinfo(skb)->gso_type = SKB_GSO_UDP; drivers/net/virtio_net.c: skb_shinfo(skb)->gso_type = SKB_GSO_UDP; Our implementation of UFO for IPv6 does: fptr =

There are several ways that VMs can take advantage of UFO and get the host to do fragmentation for them: drivers/net/macvtap.c: gso_type = SKB_GSO_UDP; drivers/net/tun.c: skb_shinfo(skb)->gso_type = SKB_GSO_UDP; drivers/net/virtio_net.c: skb_shinfo(skb)->gso_type = SKB_GSO_UDP; Our implementation of UFO for IPv6 does: fptr =

On Thu, 2014-12-18 at 00:28 -0500, Jason Wang wrote: > > ----- Original Message ----- > > UFO support in the kernel applies to both IPv4 and IPv6 protocols > > with the same device feature. However some devices may not be able > > to support one of the offloads. For this we split the UFO offload > > feature into 2 pieces. NETIF_F_UFO now controlls the IPv4 part

On Thu, 2014-12-18 at 00:28 -0500, Jason Wang wrote: > > ----- Original Message ----- > > UFO support in the kernel applies to both IPv4 and IPv6 protocols > > with the same device feature. However some devices may not be able > > to support one of the offloads. For this we split the UFO offload > > feature into 2 pieces. NETIF_F_UFO now controlls the IPv4 part

On 02/12/2014 07:59 PM, Michael S. Tsirkin wrote: > On Wed, Feb 12, 2014 at 01:43:28PM +0800, Jason Wang wrote: >> > We should alloc big buffers also when guest can receive UFO >> > pakcets. Otherwise the big packets will be truncated when mergeable rx >> > buffer is disabled. > Not truncated, they will be dropped. > Why dropped? We enable the ufo on tap0 if

On 02/12/2014 07:59 PM, Michael S. Tsirkin wrote: > On Wed, Feb 12, 2014 at 01:43:28PM +0800, Jason Wang wrote: >> > We should alloc big buffers also when guest can receive UFO >> > pakcets. Otherwise the big packets will be truncated when mergeable rx >> > buffer is disabled. > Not truncated, they will be dropped. > Why dropped? We enable the ufo on tap0 if

On Mon, 2015-01-26 at 09:37 -0500, Vladislav Yasevich wrote: > If the IPv6 fragment id has not been set and we perform > fragmentation due to UFO, select a new fragment id. > When we store the fragment id into skb_shinfo, set the bit > in the skb so we can re-use the selected id. > This preserves the behavior of UFO packets generated on the > host and solves the issue of id

On Mon, 2015-01-26 at 09:37 -0500, Vladislav Yasevich wrote: > If the IPv6 fragment id has not been set and we perform > fragmentation due to UFO, select a new fragment id. > When we store the fragment id into skb_shinfo, set the bit > in the skb so we can re-use the selected id. > This preserves the behavior of UFO packets generated on the > host and solves the issue of id

commit 3d0ad09412ffe00c9afa201d01effdb6023d09b4 Author: Ben Hutchings <ben at decadent.org.uk> Date: Thu Oct 30 18:27:12 2014 +0000 drivers/net: Disable UFO through virtio Turned off UFO support to virtio-net based devices due to issues with IPv6 fragment id generation for UFO packets. The issue was that IPv6 UFO/GSO implementation expects the fragment id to be supplied in

commit 3d0ad09412ffe00c9afa201d01effdb6023d09b4 Author: Ben Hutchings <ben at decadent.org.uk> Date: Thu Oct 30 18:27:12 2014 +0000 drivers/net: Disable UFO through virtio Turned off UFO support to virtio-net based devices due to issues with IPv6 fragment id generation for UFO packets. The issue was that IPv6 UFO/GSO implementation expects the fragment id to be supplied in

We should alloc big buffers also when guest can receive UFO pakcets to let the big packets be fit into guest rx buffer. Fixes 5c5167515d80f78f6bb538492c423adcae31ad65 (virtio-net: Allow UFO feature to be set and advertised.) Cc: Rusty Russell <rusty at rustcorp.com.au> Cc: Michael S. Tsirkin <mst at redhat.com> Cc: Sridhar Samudrala <sri at us.ibm.com> Signed-off-by: Jason Wang

We should alloc big buffers also when guest can receive UFO pakcets to let the big packets be fit into guest rx buffer. Fixes 5c5167515d80f78f6bb538492c423adcae31ad65 (virtio-net: Allow UFO feature to be set and advertised.) Cc: Rusty Russell <rusty at rustcorp.com.au> Cc: Michael S. Tsirkin <mst at redhat.com> Cc: Sridhar Samudrala <sri at us.ibm.com> Signed-off-by: Jason Wang

On Thu, Dec 25, 2014 at 2:59 AM, Michael S. Tsirkin <mst at redhat.com> wrote: > On Wed, Dec 24, 2014 at 07:11:20PM +0100, Ben Hutchings wrote: >> On Thu, 2014-12-18 at 00:28 -0500, Jason Wang wrote: >> > >> > ----- Original Message ----- >> > > UFO support in the kernel applies to both IPv4 and IPv6 >> protocols >> > > with

On Thu, Dec 25, 2014 at 2:59 AM, Michael S. Tsirkin <mst at redhat.com> wrote: > On Wed, Dec 24, 2014 at 07:11:20PM +0100, Ben Hutchings wrote: >> On Thu, 2014-12-18 at 00:28 -0500, Jason Wang wrote: >> > >> > ----- Original Message ----- >> > > UFO support in the kernel applies to both IPv4 and IPv6 >> protocols >> > > with