[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1419476521.27992.1@smtp.corp.redhat.com>
Date: Thu, 25 Dec 2014 03:10:01 +0008
From: Jason Wang <jasowang@...hat.com>
To: "Michael S. Tsirkin" <mst@...hat.com>
Cc: Ben Hutchings <ben@...adent.org.uk>,
Vladislav Yasevich <vyasevich@...il.com>,
netdev@...r.kernel.org, stefanha@...hat.com,
virtualization@...ts.linux-foundation.org
Subject: Re: [PATCH 00/10] Split UFO into v4 and v6 versions.
On Thu, Dec 25, 2014 at 2:59 AM, Michael S. Tsirkin <mst@...hat.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 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.
>
>
> Right.
>
> I think a good plan is as follows:
>
> 1. add code generating IDs on rx path for virtio,
> and re-enable UFO (4+6).
>
> 2. Ben's patch doing similar things for tun/macvtap
I wonder whether or not we can do this lazily.
E.g during UFO6 software segment for dodgy packets?
And this can eliminate the effort of duplicating it in all untrusted
sources?
>
> 3. similarly for packet sockets
>
>
> above seem appropriate for stable
>
> 4. 4+6 split, to make it easier for drivers
> to identify when fragment ID is needed
>
> 5. extend vnet header, and add ways to enable it,
> when enabled, use that to pass
> fragment ID for tun/virtio/vhost/macvtap/packet socket
>
> 4 is what this patchset does.
>
>
>> --
>> Ben Hutchings
>> If more than one person is responsible for a bug, no one is at
>> fault.
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists