From: "Michael S. Tsirkin" <mst@redhat.com>
To: Vlad Yasevich <vyasevic@redhat.com>
Cc: netdev@vger.kernel.org, Vladislav Yasevich <vyasevich@gmail.com>,
virtualization@lists.linux-foundation.org, stefanha@redhat.com,
ben@decadent.org.uk, David Miller <davem@davemloft.net>
Subject: Re: [PATCH 01/10] core: Split out UFO6 support
Date: Sat, 20 Dec 2014 23:03:59 +0200 [thread overview]
Message-ID: <20141220210359.GA23262@redhat.com> (raw)
In-Reply-To: <549486E0.7090600@redhat.com>
On Fri, Dec 19, 2014 at 03:13:20PM -0500, Vlad Yasevich wrote:
> On 12/18/2014 12:50 PM, Michael S. Tsirkin wrote:
> > On Thu, Dec 18, 2014 at 07:35:46PM +0200, Michael S. Tsirkin wrote:
> >>>> We should either generate our own ID,
> >>>> like we always did, or make sure we don't accept
> >>>> these packets.
> >>>> Second option is almost sure to break userspace,
> >>>> so it seems we must do the first one.
> >>>>
> >>>
> >>> Right. This was missing from packet sockets. I can fix it.
> >>>
> >>> -vlad
> >>
> >> Also, this can't be a patch on top, since we don't
> >> want bisect to give us configurations which
> >> can BUG().
> >
> > So how doing this in stages:
> >
> > 1. add helper that checks skb GSO type.
> > If it is SKB_GSO_UDP, check for IPv6, and
> > generate the fragment ID.
> >
> > Call this helper in
> > - virtio net rx path
>
> Why do we need id on rx path? Fragment ID should only be generated on tx.
So that all GSO_UDP6 packets have fragment ID as appropriate.
It's similar to how we fill it on rx in tun, is it not?
> > - tun rx path (get user)
> > - macvtap tx patch (get user)
> > - packet socket tx patch (get user)
>
> The reset makes sense.
> >
> > 2. Put back UFO flag everywhere: virtio,tun,macvtap,packet,
> > since we can handle IPv6 now even if it's suboptimal.
> >
> > Above two seem like smalling patches, appropriate for stable.
>
> OK.
>
> >
> > Next, work on a new feature to pass
> > fragment ID in virtio header:
> >
> > 3. split UFO/UFO6 as you did here, but add code
> > in above 4 places to convert UDP to UDP6,
>
> Doing so will adversely impact IPv6 UFO performance for legacy
> guests. I know how many times I've seen mail wrt patch xyz caused
> %X regression in my setup and how we've reverted or tried to fixed
> things to solve this. If we go with approach, the only "fix' would be
> to upgrade the guest and that's not available to some users.
>
> -vlad
I think there's some misunderstanding here.
I merely mean that after split, host should always have
SKB_GSO_UDP6 set for IPv6.
To make sure legacy userspace/guests don't notice changes,
whenever we detect SKB_GSO_UDP6 we should set VIRTIO_NET_HDR_GSO_UDP,
and whenever we get VIRTIO_NET_HDR_GSO_UDP we should set either
SKB_GSO_UDP6 or SKB_GSO_UDP depending on IP type.
Given this clarification there's no reason to think
old guests will regress, correct?
> > additionally, add code in
> > - virtio net tx path
> > - tun tx path (get user)
> > - macvtap rx patch (put user)
> > - packet socket rx patch (put user)
> > to convert UDP6 to UDP.
> >
> > step 3 needs to be bisect-clean, somehow.
> >
> > 4. add new field in header, new feature bit for virtio net to gate it,
> > new ioctls to tun,macvtap,packet socket.
> >
> > These two are more like optimizations, so not stable material.
> >
> >
next prev parent reply other threads:[~2014-12-20 21:03 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-17 18:20 [PATCH 00/10] Split UFO into v4 and v6 versions Vladislav Yasevich
2014-12-17 18:20 ` [PATCH 01/10] core: Split out UFO6 support Vladislav Yasevich
2014-12-17 20:10 ` Ben Hutchings
2014-12-17 20:43 ` Vlad Yasevich
2014-12-17 22:45 ` Michael S. Tsirkin
2014-12-17 23:31 ` Vlad Yasevich
2014-12-18 7:54 ` Michael S. Tsirkin
2014-12-18 15:01 ` Vlad Yasevich
2014-12-18 17:35 ` Michael S. Tsirkin
2014-12-18 17:50 ` Michael S. Tsirkin
2014-12-19 20:13 ` Vlad Yasevich
2014-12-20 21:03 ` Michael S. Tsirkin [this message]
2014-12-22 4:06 ` Vlad Yasevich
2014-12-19 19:55 ` Vlad Yasevich
2014-12-17 18:20 ` [PATCH 02/10] net: Correctly mark IPv6 UFO offload type Vladislav Yasevich
2014-12-17 18:20 ` [PATCH 03/10] ovs: Enable handling of UFO6 packets Vladislav Yasevich
2014-12-17 20:17 ` Sergei Shtylyov
2014-12-17 20:44 ` Vlad Yasevich
2014-12-17 22:26 ` Michael S. Tsirkin
2014-12-17 18:20 ` [PATCH 04/10] loopback: Turn on UFO6 support Vladislav Yasevich
2014-12-17 18:20 ` [PATCH 05/10] veth: Enable " Vladislav Yasevich
2014-12-17 18:20 ` [PATCH 06/10] macvlan: " Vladislav Yasevich
2014-12-17 18:20 ` [PATCH 07/10] s2io: " Vladislav Yasevich
2014-12-17 18:20 ` [PATCH 08/10] tun: Re-uanble UFO support Vladislav Yasevich
2014-12-17 22:33 ` Michael S. Tsirkin
2014-12-18 5:51 ` Jason Wang
2014-12-18 15:12 ` Vlad Yasevich
2014-12-19 4:37 ` Jason Wang
2014-12-17 18:20 ` [PATCH 09/10] macvtap: Re-enable " Vladislav Yasevich
2014-12-17 22:41 ` Michael S. Tsirkin
2014-12-18 2:43 ` Vlad Yasevich
2014-12-18 7:55 ` Michael S. Tsirkin
2014-12-18 15:15 ` Vlad Yasevich
2014-12-17 18:20 ` [PATCH 10/10] Revert "drivers/net: Disable UFO through virtio" Vladislav Yasevich
2014-12-17 22:44 ` Michael S. Tsirkin
2014-12-18 5:28 ` [PATCH 00/10] Split UFO into v4 and v6 versions Jason Wang
2014-12-24 18:11 ` Ben Hutchings
2014-12-24 18:59 ` Michael S. Tsirkin
2014-12-25 3:02 ` Jason Wang
2014-12-25 7:14 ` Michael S. Tsirkin
2014-12-25 9:50 ` Jason Wang
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=20141220210359.GA23262@redhat.com \
--to=mst@redhat.com \
--cc=ben@decadent.org.uk \
--cc=davem@davemloft.net \
--cc=netdev@vger.kernel.org \
--cc=stefanha@redhat.com \
--cc=virtualization@lists.linux-foundation.org \
--cc=vyasevic@redhat.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).