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>