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. _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
