[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <1413935045.5994.2.camel@decadent.org.uk>
Date: Wed, 22 Oct 2014 00:44:05 +0100
From: Ben Hutchings <ben@...adent.org.uk>
To: netdev <netdev@...r.kernel.org>
Cc: virtualization@...ts.linux-foundation.org,
Hannes Frederic Sowa <hannes@...essinduktion.org>
Subject: 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@...essinduktion.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
Download attachment "signature.asc" of type "application/pgp-signature" (812 bytes)
Powered by blists - more mailing lists