similar to: [PATCH net] virtio-net: alloc big buffers also when guest can receive UFO

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 Fri, Feb 21, 2014 at 01:08:04PM +0800, Jason Wang wrote: > We should alloc big buffers also when guest can receive UFO > pakcets to let the big packets be fit into guest rx buffer. s/pakcets/packets/ s/be fit/fit/ otherwise: Acked-by: Michael S. Tsirkin <mst at redhat.com> > > Fixes 5c5167515d80f78f6bb538492c423adcae31ad65 > (virtio-net: Allow UFO feature to be set

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. > Fixes 5c5167515d80f78f6bb538492c423adcae31ad65 > (virtio-net: Allow UFO feature to be set and advertised.) > > Cc: Rusty

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 Thu, Feb 13, 2014 at 11:02:13AM +0800, Jason Wang wrote: > 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. >

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

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

This reverts commit 3d0ad09412ffe00c9afa201d01effdb6023d09b4. Now that we've split UFO into v4 and v6 version, we can turn back UFO support for ipv4. Full IPv6 support will come later as it requires extending vnet header structure. Any older VM that assumes IPv6 support is included in UFO will continue to use UFO and the host will generate fragment ids for it, thus preserving connectivity.

This reverts commit 3d0ad09412ffe00c9afa201d01effdb6023d09b4. Now that we've split UFO into v4 and v6 version, we can turn back UFO support for ipv4. Full IPv6 support will come later as it requires extending vnet header structure. Any older VM that assumes IPv6 support is included in UFO will continue to use UFO and the host will generate fragment ids for it, thus preserving connectivity.

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

On 16-12-23 06:37 AM, Jason Wang wrote: > When VIRTIO_NET_F_GUEST_UFO is negotiated, host could still send UFO > packet that exceeds a single page which could not be handled > correctly by XDP. So this patch forbids setting XDP when GUEST_UFO is > supported. While at it, forbid XDP for ECN (which comes only from GRO) > too to prevent user from misconfiguration. > > Cc: John

On 16-12-23 06:37 AM, Jason Wang wrote: > When VIRTIO_NET_F_GUEST_UFO is negotiated, host could still send UFO > packet that exceeds a single page which could not be handled > correctly by XDP. So this patch forbids setting XDP when GUEST_UFO is > supported. While at it, forbid XDP for ECN (which comes only from GRO) > too to prevent user from misconfiguration. > > Cc: John

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

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