From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jason Wang Subject: Re: [PATCH 00/10] Split UFO into v4 and v6 versions. Date: Thu, 25 Dec 2014 03:10:01 +0008 Message-ID: <1419476521.27992.1@smtp.corp.redhat.com> References: <1418840455-22598-1-git-send-email-vyasevic@redhat.com> <586203981.237162.1418880532523.JavaMail.zimbra@redhat.com> <1419444680.4705.129.camel@decadent.org.uk> <20141224185922.GA30934@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Cc: netdev@vger.kernel.org, Vladislav Yasevich , Ben Hutchings , stefanha@redhat.com, virtualization@lists.linux-foundation.org To: "Michael S. Tsirkin" Return-path: In-Reply-To: <20141224185922.GA30934@redhat.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: virtualization-bounces@lists.linux-foundation.org Errors-To: virtualization-bounces@lists.linux-foundation.org List-Id: netdev.vger.kernel.org On Thu, Dec 25, 2014 at 2:59 AM, Michael S. Tsirkin 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@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html