From: "Michael S. Tsirkin" <mst@redhat.com>
To: Vladislav Yasevich <vyasevich@gmail.com>
Cc: eric.dumazet@gmail.com, netdev@vger.kernel.org,
virtualization@lists.linux-foundation.org,
hannes@stressinduktion.org, ben@decadent.org.uk,
David Miller <davem@davemloft.net>
Subject: Re: [PATCH v2 0/3] Restore UFO support to virtio_net devices
Date: Sat, 31 Jan 2015 19:17:43 +0200 [thread overview]
Message-ID: <20150131171743.GE31871@redhat.com> (raw)
In-Reply-To: <1422646047-13168-1-git-send-email-vyasevic@redhat.com>
On Fri, Jan 30, 2015 at 02:27:24PM -0500, Vladislav Yasevich wrote:
> commit 3d0ad09412ffe00c9afa201d01effdb6023d09b4
> Author: Ben Hutchings <ben@decadent.org.uk>
> Date: Thu Oct 30 18:27:12 2014 +0000
>
> drivers/net: Disable UFO through virtio
>
> Turned off UFO support to virtio-net based devices due to issues
> with IPv6 fragment id generation for UFO packets. The issue
> was that IPv6 UFO/GSO implementation expects the fragment id
> to be supplied in skb_shinfo(). However, for packets generated
> by the VMs, the fragment id is not supplied which causes all
> IPv6 fragments to have the id of 0.
>
> The problem is that turning off UFO support on tap/macvtap
> as well as virtio devices caused issues with migrations.
> Migrations would fail when moving a vm from a kernel supporting
> expecting UFO to work to the newer kernels that disabled UFO.
>
> This series provides a partial solution to address the migration
> issue. The series allows us to track whether skb_shinfo()->ip6_frag_id
> has been set by treating value of 0 as unset.
> This lets GSO code to generate fragment ids if they are necessary
> (ex: packet was generated by VM or packet socket).
>
> Since v1:
> - Removed the skb bit and use value of 0 as tracker.
> - Used Eric's suggestion to set fragment id as 0x80000000 if id
> generation procedure yeilded a 0 result.
> - Consolidated ipv6 id genration code.
Looks good to me
Acked-by: Michael S. Tsirkin <mst@redhat.com>
Seems appropriate for stable as well.
> Vladislav Yasevich (3):
> ipv6: Select fragment id during UFO segmentation if not set.
> Revert "drivers/net, ipv6: Select IPv6 fragment idents for virtio UFO
> packets"
> Revert "drivers/net: Disable UFO through virtio"
>
> drivers/net/macvtap.c | 16 ++++++++--------
> drivers/net/tun.c | 25 +++++++++----------------
> drivers/net/virtio_net.c | 24 ++++++++++--------------
> include/net/ipv6.h | 3 +++
> net/ipv6/ip6_output.c | 10 ++++------
> net/ipv6/output_core.c | 28 ++++++++++++++++++++++------
> net/ipv6/udp_offload.c | 10 +++++++++-
> 7 files changed, 65 insertions(+), 51 deletions(-)
>
> --
> 1.9.3
next prev parent reply other threads:[~2015-01-31 17:17 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-30 19:27 [PATCH v2 0/3] Restore UFO support to virtio_net devices Vladislav Yasevich
2015-01-30 19:27 ` [PATCH v2 1/3] ipv6: Select fragment id during UFO segmentation if not set Vladislav Yasevich
2015-01-30 19:27 ` Vladislav Yasevich
2015-01-31 17:11 ` Michael S. Tsirkin
2015-01-30 19:27 ` [PATCH v2 2/3] Revert "drivers/net, ipv6: Select IPv6 fragment idents for virtio UFO packets" Vladislav Yasevich
2015-01-30 19:27 ` Vladislav Yasevich
2015-01-31 17:11 ` Michael S. Tsirkin
2015-01-30 19:27 ` [PATCH v2 3/3] Revert "drivers/net: Disable UFO through virtio" Vladislav Yasevich
2015-01-31 17:11 ` Michael S. Tsirkin
2015-01-30 19:27 ` Vladislav Yasevich
2015-01-31 17:17 ` Michael S. Tsirkin [this message]
2015-02-02 6:19 ` [PATCH v2 0/3] Restore UFO support to virtio_net devices David Miller
2015-02-02 6:28 ` David Miller
2015-02-02 15:04 ` Vlad Yasevich
2015-02-02 6:28 ` David Miller
-- strict thread matches above, loose matches on Subject: below --
2015-01-30 19:27 Vladislav Yasevich
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150131171743.GE31871@redhat.com \
--to=mst@redhat.com \
--cc=ben@decadent.org.uk \
--cc=davem@davemloft.net \
--cc=eric.dumazet@gmail.com \
--cc=hannes@stressinduktion.org \
--cc=netdev@vger.kernel.org \
--cc=virtualization@lists.linux-foundation.org \
--cc=vyasevich@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.