similar to: [0/6] [NET]: virtio SG/TSO patches

1) Turn GSO on virtio net into an all-or-nothing (keep checksumming separate). Having multiple bits is a pain: if you can't support something you should handle it in software, which is still a performance win. 2) Make VIRTIO_NET_HDR_GSO_ECN a flag in the header, so it can apply to IPv6 or v4. 3) Rename VIRTIO_NET_F_NO_CSUM to VIRTIO_NET_F_CSUM (ie. means we do checksumming). 4)

1) Turn GSO on virtio net into an all-or-nothing (keep checksumming separate). Having multiple bits is a pain: if you can't support something you should handle it in software, which is still a performance win. 2) Make VIRTIO_NET_HDR_GSO_ECN a flag in the header, so it can apply to IPv6 or v4. 3) Rename VIRTIO_NET_F_NO_CSUM to VIRTIO_NET_F_CSUM (ie. means we do checksumming). 4)

Hi, This patches introduce virtio_net_hdr_{from,to}_skb functions for conversion of GSO information between skb and virtio_net_hdr. Mike Rapoport (6): virtio_net: add _UAPI prefix to virtio_net header guards virtio_net: introduce virtio_net_hdr_{from,to}_skb macvtap: use common code for virtio_net_hdr and skb GSO conversion tuntap: use common code for virtio_net_hdr and skb GSO

Hi, This patches introduce virtio_net_hdr_{from,to}_skb functions for conversion of GSO information between skb and virtio_net_hdr. Mike Rapoport (6): virtio_net: add _UAPI prefix to virtio_net header guards virtio_net: introduce virtio_net_hdr_{from,to}_skb macvtap: use common code for virtio_net_hdr and skb GSO conversion tuntap: use common code for virtio_net_hdr and skb GSO

On Tue, Nov 11, 2014 at 12:17:26PM +0000, Ben Hutchings wrote: > On Tue, 2014-11-11 at 10:58 +0000, Stefan Hajnoczi wrote: > > Commit 3d0ad09412ffe00c9afa201d01effdb6023d09b4 ("drivers/net: Disable > > UFO through virtio") breaks live migration of KVM guests from older to > > newer host kernels: > > > >

On Tue, Nov 11, 2014 at 12:17:26PM +0000, Ben Hutchings wrote: > On Tue, 2014-11-11 at 10:58 +0000, Stefan Hajnoczi wrote: > > Commit 3d0ad09412ffe00c9afa201d01effdb6023d09b4 ("drivers/net: Disable > > UFO through virtio") breaks live migration of KVM guests from older to > > newer host kernels: > > > >

On Thu, Feb 13, 2020 at 07:44:06AM -0800, Eric Dumazet wrote: > > > On 2/13/20 2:00 AM, Michael S. Tsirkin wrote: > > On Wed, Feb 12, 2020 at 05:38:09PM +0000, Anton Ivanov wrote: > >> > >> > >> On 11/02/2020 10:37, Michael S. Tsirkin wrote: > >>> On Tue, Feb 11, 2020 at 07:42:37AM +0000, Anton Ivanov wrote: > >>>> On

On Thu, Feb 13, 2020 at 07:44:06AM -0800, Eric Dumazet wrote: > > > On 2/13/20 2:00 AM, Michael S. Tsirkin wrote: > > On Wed, Feb 12, 2020 at 05:38:09PM +0000, Anton Ivanov wrote: > >> > >> > >> On 11/02/2020 10:37, Michael S. Tsirkin wrote: > >>> On Tue, Feb 11, 2020 at 07:42:37AM +0000, Anton Ivanov wrote: > >>>> On

From: Anton Ivanov <anton.ivanov at cambridgegreys.com> Some of the frames marked as GSO which arrive at virtio_net_hdr_from_skb() have no GSO_TYPE, no fragments (data_len = 0) and length significantly shorter than the MTU (752 in my experiments). This is observed on raw sockets reading off vEth interfaces in all 4.x and 5.x kernels I tested. These frames are reported as invalid while

On Tue, Feb 11, 2020 at 07:42:37AM +0000, Anton Ivanov wrote: > On 11/02/2020 02:51, Jason Wang wrote: > > > > On 2020/2/11 ??12:55, Anton Ivanov wrote: > > > > > > > > > On 09/12/2019 10:48, anton.ivanov at cambridgegreys.com wrote: > > > > From: Anton Ivanov <anton.ivanov at cambridgegreys.com> > > > > > > >

On Tue, Feb 11, 2020 at 07:42:37AM +0000, Anton Ivanov wrote: > On 11/02/2020 02:51, Jason Wang wrote: > > > > On 2020/2/11 ??12:55, Anton Ivanov wrote: > > > > > > > > > On 09/12/2019 10:48, anton.ivanov at cambridgegreys.com wrote: > > > > From: Anton Ivanov <anton.ivanov at cambridgegreys.com> > > > > > > >

On Wed, Feb 12, 2020 at 05:38:09PM +0000, Anton Ivanov wrote: > > > On 11/02/2020 10:37, Michael S. Tsirkin wrote: > > On Tue, Feb 11, 2020 at 07:42:37AM +0000, Anton Ivanov wrote: > > > On 11/02/2020 02:51, Jason Wang wrote: > > > > > > > > On 2020/2/11 ??12:55, Anton Ivanov wrote: > > > > > > > > > > > >

On Wed, Feb 12, 2020 at 05:38:09PM +0000, Anton Ivanov wrote: > > > On 11/02/2020 10:37, Michael S. Tsirkin wrote: > > On Tue, Feb 11, 2020 at 07:42:37AM +0000, Anton Ivanov wrote: > > > On 11/02/2020 02:51, Jason Wang wrote: > > > > > > > > On 2020/2/11 ??12:55, Anton Ivanov wrote: > > > > > > > > > > > >

On 2020/2/11 ??12:55, Anton Ivanov wrote: > > > On 09/12/2019 10:48, anton.ivanov at cambridgegreys.com wrote: >> From: Anton Ivanov <anton.ivanov at cambridgegreys.com> >> >> Some of the frames marked as GSO which arrive at >> virtio_net_hdr_from_skb() have no GSO_TYPE, no >> fragments (data_len = 0) and length significantly shorter >> than the

On 2020/2/11 ??12:55, Anton Ivanov wrote: > > > On 09/12/2019 10:48, anton.ivanov at cambridgegreys.com wrote: >> From: Anton Ivanov <anton.ivanov at cambridgegreys.com> >> >> Some of the frames marked as GSO which arrive at >> virtio_net_hdr_from_skb() have no GSO_TYPE, no >> fragments (data_len = 0) and length significantly shorter >> than the

On Wed, Dec 17, 2014 at 01:20:54PM -0500, Vladislav Yasevich wrote: > Now that UFO is split into v4 and v6 parts, we can bring > back v4 support. Continue to handle legacy applications > by selecting the ipv6 fagment id but do not change the > gso type. This allows 2 legacy VMs to continue to communicate. > > Based on original work from Ben Hutchings. > > Fixes:

On Wed, Dec 17, 2014 at 01:20:54PM -0500, Vladislav Yasevich wrote: > Now that UFO is split into v4 and v6 parts, we can bring > back v4 support. Continue to handle legacy applications > by selecting the ipv6 fagment id but do not change the > gso type. This allows 2 legacy VMs to continue to communicate. > > Based on original work from Ben Hutchings. > > Fixes:

The virtio net protocol supports UFO but does not provide for passing a fragment ID for fragmentation of IPv6 packets. We used to generate a fragment ID wherever such a packet was fragmented, but currently we always use ID=0! v2: Add blank lines after declarations Ben. Ben Hutchings (2): drivers/net: Disable UFO through virtio drivers/net,ipv6: Select IPv6 fragment idents for virtio UFO

The virtio net protocol supports UFO but does not provide for passing a fragment ID for fragmentation of IPv6 packets. We used to generate a fragment ID wherever such a packet was fragmented, but currently we always use ID=0! v2: Add blank lines after declarations Ben. Ben Hutchings (2): drivers/net: Disable UFO through virtio drivers/net,ipv6: Select IPv6 fragment idents for virtio UFO

The virtio net protocol supports UFO but does not provide for passing a fragment ID for fragmentation of IPv6 packets. We used to generate a fragment ID wherever such a packet was fragmented, but currently we always use ID=0! Ben. Ben Hutchings (2): drivers/net: Disable UFO through virtio drivers/net,ipv6: Select IPv6 fragment idents for virtio UFO packets drivers/net/macvtap.c | 16