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
