Thank you all, I'll try to backport 802.1ad patches. -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Eric Garver Sent: Friday, January 20, 2017 7:53 AM To: Joe Stringer <[email protected]> Cc: ovs dev <[email protected]>; Jan Scheurich <[email protected]> Subject: Re: [ovs-dev] [PATCH v2 14/17] datapath: Fix skb->protocol for vlan frames
On Thu, Jan 19, 2017 at 03:12:20PM -0800, Joe Stringer wrote: > On 19 January 2017 at 12:17, Pravin Shelar <[email protected]> wrote: > > On Wed, Jan 18, 2017 at 4:53 PM, Yang, Yi <[email protected]> wrote: > >> On Wed, Jan 18, 2017 at 01:29:14PM -0800, Joe Stringer wrote: > >>> On 18 January 2017 at 11:54, Eric Garver <[email protected]> wrote: > >>> > On Tue, Jan 17, 2017 at 12:37:19AM +0000, Yang, Yi Y wrote: > >>> >> What userspace do "802.1ad patches" depend on? Per Pravin's statement, > >>> >> we just backport 802.1ad patches to ovs, then the below patch can be > >>> >> applied to ovs. > >>> > > >>> > Userspace does not yet have support for 802.1ad. I'm still > >>> > working on it. You can check the list archives for a recent RFC version. > >>> > > >>> > I don't know if it's acceptable to backport the datapath (kernel > >>> > module) support before the userspace support is accepted. If > >>> > not, you'll have to wait on the userspace. > >>> > Perhaps Pravin can answer. > >>> > >>> IMO the general method of: > >>> 1) Add support upstream > >>> 2) Add userspace support > >>> 3) Add backport > >>> > >>> ...works nicely because we get feedback for all interested parties > >>> for the APIs in (1), (2) can add tests and be easily tested > >>> against a version that works (upstream kernel) and a version that > >>> doesn't (version in tree) to ensure both cases are handled in a > >>> reasonable way, then (3) allows people on older kernels to gain > >>> access to the newer features. > >>> > >>> That said, if other people are blocking on (3) then I think that > >>> piece should be expedited. Let's say (2) and (3) were swapped, it > >>> just means we need to be a bit more careful when reviewing/testing > >>> to check that the newer userspace still handles old kernels (that > >>> lack support) fine. > >>> > >>> The nice thing about getting the backport earlier is, the closer > >>> to upstream we are, the sooner we may find issues that affect the > >>> latest code. > >> > >> If so, I think the below patch is the best solution to current > >> situation, it will be automatically overwritten once userspace part > >> and 802.1ad backport are ready to merge. > >> > > It is much easier to backport and review patches when it is done in > > same sequence as applied on upstream kernel. It is not just about > > this patch. by changing backport order the implementation and review > > of both L3 patch series and 802.1AD patch series becomes harder than > > necessary. > > Sorry, yes, my earlier explanation was regarding a particular feature > and ordering of userspace implementation vs. backport patches. > > With regards to the overall kernel backport, I agree the upstream > patches should be backported in sequence according to upstream. Then > we know we haven't missed anything. Also, dependencies from one patch > to the next are less likely to cause trouble while rebasing, so it > makes the backporter's life easier. Sounds good to me. Yi is welcome to try the 802.1ad datapath backport. Otherwise I'll get to when I can. Thanks everyone. _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
