Linux Virtualization - Oct 2014 - IPv6 UFO for VMs

There are several ways that VMs can take advantage of UFO and get the
host to do fragmentation for them:

drivers/net/macvtap.c:                  gso_type = SKB_GSO_UDP;
drivers/net/tun.c:                      skb_shinfo(skb)->gso_type =
SKB_GSO_UDP;
drivers/net/virtio_net.c:                       skb_shinfo(skb)->gso_type =
SKB_GSO_UDP;

Our implementation of UFO for IPv6 does:

		fptr = (struct frag_hdr *)(skb_network_header(skb) + unfrag_ip6hlen);
		fptr->nexthdr = nexthdr;
		fptr->reserved = 0;
		fptr->identification = skb_shinfo(skb)->ip6_frag_id;

which assumes ip6_frag_id has been set.  That's only true if the local
stack constructed the skb; otherwise it appears we get zero.

This seems to be a regression as a result of:

commit 916e4cf46d0204806c062c8c6c4d1f633852c5b6
Author: Hannes Frederic Sowa <hannes at stressinduktion.org>
Date:   Fri Feb 21 02:55:35 2014 +0100

    ipv6: reuse ip6_frag_id from ip6_ufo_append_data

However, that change seems reasonable - we *shouldn't* be choosing IDs
for any other stack.  Any paravirt net driver that can use IPv6 UFO
needs to have some way of passing a fragmentation ID to put in
skb_shared_info::ip6_frag_id.

Ben.

-- 
Ben Hutchings
For every action, there is an equal and opposite criticism. - Harrison
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 811 bytes
Desc: This is a digitally signed message part
URL:
<http://lists.linuxfoundation.org/pipermail/virtualization/attachments/20141022/f3b259b3/attachment.sig>

On Mi, 2014-10-22 at 00:44 +0100, Ben Hutchings wrote:
> There are several ways that VMs can take advantage of UFO and get the
> host to do fragmentation for them:
> 
> drivers/net/macvtap.c:                  gso_type = SKB_GSO_UDP;
> drivers/net/tun.c:                      skb_shinfo(skb)->gso_type =
SKB_GSO_UDP;
> drivers/net/virtio_net.c:                      
skb_shinfo(skb)->gso_type = SKB_GSO_UDP;
> 
> Our implementation of UFO for IPv6 does:
> 
> 		fptr = (struct frag_hdr *)(skb_network_header(skb) + unfrag_ip6hlen);
> 		fptr->nexthdr = nexthdr;
> 		fptr->reserved = 0;
> 		fptr->identification = skb_shinfo(skb)->ip6_frag_id;
> 
> which assumes ip6_frag_id has been set.  That's only true if the local
> stack constructed the skb; otherwise it appears we get zero.
> 
> This seems to be a regression as a result of:
> 
> commit 916e4cf46d0204806c062c8c6c4d1f633852c5b6
> Author: Hannes Frederic Sowa <hannes at stressinduktion.org>
> Date:   Fri Feb 21 02:55:35 2014 +0100
> 
>     ipv6: reuse ip6_frag_id from ip6_ufo_append_data
> 
> However, that change seems reasonable - we *shouldn't* be choosing IDs
> for any other stack.  Any paravirt net driver that can use IPv6 UFO
> needs to have some way of passing a fragmentation ID to put in
> skb_shared_info::ip6_frag_id.
Do we really gain a lot of performance by enabling UFO on those devices
or would it make sense to just drop support? It only helps fragmenting
large UDP packets, so I don't think it is worth it.

Otherwise I agree with Ben, we need to pass a fragmentation id from the
host over to the system segmenting the gso frame. Fragmentation ids must
be generated by the end system.

Hmm...

Bye,
Hannes

On Wed, 2014-10-22 at 11:35 +0200, Hannes Frederic Sowa
wrote:
> On Mi, 2014-10-22 at 00:44 +0100, Ben Hutchings wrote:
> > There are several ways that VMs can take advantage of UFO and get the
> > host to do fragmentation for them:
> > 
> > drivers/net/macvtap.c:                  gso_type = SKB_GSO_UDP;
> > drivers/net/tun.c:                      skb_shinfo(skb)->gso_type =
SKB_GSO_UDP;
> > drivers/net/virtio_net.c:                      
skb_shinfo(skb)->gso_type = SKB_GSO_UDP;
> > 
> > Our implementation of UFO for IPv6 does:
> > 
> > 		fptr = (struct frag_hdr *)(skb_network_header(skb) +
unfrag_ip6hlen);
> > 		fptr->nexthdr = nexthdr;
> > 		fptr->reserved = 0;
> > 		fptr->identification = skb_shinfo(skb)->ip6_frag_id;
> > 
> > which assumes ip6_frag_id has been set.  That's only true if the
local
> > stack constructed the skb; otherwise it appears we get zero.
> > 
> > This seems to be a regression as a result of:
> > 
> > commit 916e4cf46d0204806c062c8c6c4d1f633852c5b6
> > Author: Hannes Frederic Sowa <hannes at stressinduktion.org>
> > Date:   Fri Feb 21 02:55:35 2014 +0100
> > 
> >     ipv6: reuse ip6_frag_id from ip6_ufo_append_data
> > 
> > However, that change seems reasonable - we *shouldn't* be choosing
IDs
> > for any other stack.  Any paravirt net driver that can use IPv6 UFO
> > needs to have some way of passing a fragmentation ID to put in
> > skb_shared_info::ip6_frag_id.
> 
> Do we really gain a lot of performance by enabling UFO on those devices
> or would it make sense to just drop support? It only helps fragmenting
> large UDP packets, so I don't think it is worth it.
It's not been important enough for anyone to bother implementing it in
hardware/firmware aside from Neterion.

I'll shortly post patches to disable it.

Ben.
> Otherwise I agree with Ben, we need to pass a fragmentation id from the
> host over to the system segmenting the gso frame. Fragmentation ids must
> be generated by the end system.
> 
> Hmm...
-- 
Ben Hutchings
Theory and practice are closer in theory than in practice.
                                - John Levine, moderator of comp.compilers
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 811 bytes
Desc: This is a digitally signed message part
URL:
<http://lists.linuxfoundation.org/pipermail/virtualization/attachments/20141027/0c9ae417/attachment.sig>