[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20141218175002.GA5539@redhat.com>
Date: Thu, 18 Dec 2014 19:50:02 +0200
From: "Michael S. Tsirkin" <mst@...hat.com>
To: Vlad Yasevich <vyasevic@...hat.com>
Cc: Vladislav Yasevich <vyasevich@...il.com>, netdev@...r.kernel.org,
virtualization@...ts.linux-foundation.org, ben@...adent.org.uk,
stefanha@...hat.com, David Miller <davem@...emloft.net>
Subject: Re: [PATCH 01/10] core: Split out UFO6 support
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
- tun rx path (get user)
- macvtap tx patch (get user)
- packet socket tx patch (get user)
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.
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,
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.
--
MST
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists