Eric and Joe, thank you so much for your verification and fix, I'll resubmit a new version including this fix and missing part.
-----Original Message----- From: Eric Garver [mailto:e...@erig.me] Sent: Saturday, February 11, 2017 9:22 PM To: Joe Stringer <j...@ovn.org>; Yang, Yi Y <yi.y.y...@intel.com> Cc: ovs dev <d...@openvswitch.org> Subject: Re: [ovs-dev] [PATCH v3 00/16] port Jiri Benc's L3 patchset to ovs On Fri, Feb 10, 2017 at 01:33:04PM -0800, Joe Stringer wrote: > On 10 February 2017 at 12:25, Eric Garver <e...@erig.me> wrote: > > On Fri, Feb 10, 2017 at 11:24:58AM -0500, Eric Garver wrote: > >> On Tue, Feb 07, 2017 at 02:30:46PM -0800, Joe Stringer wrote: > >> > On 7 February 2017 at 09:44, Joe Stringer <j...@ovn.org> wrote: > >> > > On 6 February 2017 at 16:46, Yang, Yi Y <yi.y.y...@intel.com> wrote: > >> > >> Joe, I checked current ovs and net-next kernel, obviously some > >> > >> patches from net-next are selectively backported to ovs, but others > >> > >> are not, I'm not sure what the policy is for a new patch. It will be > >> > >> better that the person who did the patch backports it to ovs at the > >> > >> same time, but nobody did so. > >> > > > >> > > That's supposed to be the policy; However, depending on the > >> > > patch sometimes openvswitch isn't even the main target of the > >> > > change, so the contributor may not be aware they should do so. > >> > > There may be added difficulty if the previous contributor > >> > > didn't do their backport. I think that lately there hasn't been > >> > > particularly close co-ordination between the trees, but ideally > >> > > I think that as we approach an OVS release, we would try to sync them > >> > > up. > >> > > > >> > >> My 802.1ad backport has included all the things l3 patch set > >> > >> depends on, so I think you can give it a go :-) > >> > > > >> > > Kicking off a build on my local tester, I can at least report > >> > > back on that. I see you've tested on a few platforms as well, that's > >> > > great. > >> > > >> > Reporting back, I suspect that some of the older kernels don't > >> > treat the double-tagged vlans right with this series? > >> > > >> > I was using an Ubuntu trusty VM with kernel 3.13.0-92-generic > >> > plus this backport and it seems to be consistently failing this test: > >> > > >> > 4: datapath - ping between two ports on cvlan FAILED > >> > (system-traffic.at:88) > >> > > >> > The test output just shows that a ping tries about 10 times and > >> > fails all of the times. I didn't investigate further. > >> > >> Hi Joe, > >> > >> Thanks for testing those backports. > >> > >> I ran them on debian with 3.16 kernel. I see the same failures. > >> Interestingly, if when the test hangs (when waiting on the ping) I > >> ping in a different window namespace to namespace it will work as expected. > >> This ping should be equivalent to what the test is doing. I can't > >> explain this yet, but I'll keep investigating. > > > > I found the cause. The upcall re-inserts the VLAN back into the raw > > packet data, but the TPID is hard coded to 0x8100. > > This affects kernels for which HAVE_VLAN_INSERT_TAG_SET_PROTO is not > > set. > > > > The below patch allows the cvlan and 802.ad tests (not upstream yet) > > to pass on debian with 3.16 kernel. However, it may be better > > backport a modern version of vlan_insert_tag_set_proto(). > > Thanks for figuring this out. Will you or Yi submit this? I think it makes sense for it to be submitted with the 802.1ad series. Yi, Can you add the fix I suggest above to your 802.1ad series? _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev