[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1419444680.4705.129.camel@decadent.org.uk>
Date: Wed, 24 Dec 2014 19:11:20 +0100
From: Ben Hutchings <ben@...adent.org.uk>
To: Jason Wang <jasowang@...hat.com>
Cc: Vladislav Yasevich <vyasevich@...il.com>, netdev@...r.kernel.org,
mst@...hat.com, stefanha@...hat.com,
virtualization@...ts.linux-foundation.org
Subject: Re: [PATCH 00/10] Split UFO into v4 and v6 versions.
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 and
> > this series introduces NETIF_F_UFO6.
> >
> > As a result of this work, we can now re-enable NETIF_F_UFO on
> > virtio_net devices and restore UDP over IPv4 performance for guests.
> > We also continue to support legacy guests that assume that UFO6
> > support included into UFO(4).
> >
> > Without this work, migrating a guest to a 3.18 kernel fails.
> >
>
> This series eliminate the ambiguous NETIF_F_UFO.
>
> But VIRTIO_NET_F_{HOST|GUEST}_UFO and VIRTIO_NET_F_HDR_GSO_UDP is still
> ambigious. I know it was used to keep compatibility for legacy guest. But
> what's the future plan? Differentiate UFOv4 and UFOv6 in virtio features and
> gso type in vnet header looks sufficient?
[...]
The IPv6 fragmentation ID needs to be added to the vnet header, to do
UFOv6 properly. If it wasn't for that lack, we wouldn't have to split
the feature flag.
Ben.
--
Ben Hutchings
If more than one person is responsible for a bug, no one is at fault.
Download attachment "signature.asc" of type "application/pgp-signature" (812 bytes)
Powered by blists - more mailing lists