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 <[email protected]> wrote:
> > > On 6 February 2017 at 16:46, Yang, Yi Y <[email protected]> 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().
diff --git a/datapath/linux/compat/include/linux/if_vlan.h
b/datapath/linux/compat/include/linux/if_vlan.h
index ff55fb8641b9..a3a25df46248 100644
--- a/datapath/linux/compat/include/linux/if_vlan.h
+++ b/datapath/linux/compat/include/linux/if_vlan.h
@@ -24,8 +24,9 @@
* acceptable.
*/
#define vlan_insert_tag_set_proto(skb, proto, vlan_tci) \
- rpl_vlan_insert_tag_set_proto(skb, vlan_tci)
+ rpl_vlan_insert_tag_set_proto(skb, proto, vlan_tci)
static inline struct sk_buff *rpl_vlan_insert_tag_set_proto(struct sk_buff
*skb,
+ __be16 vlan_proto,
u16 vlan_tci)
{
struct vlan_ethhdr *veth;
@@ -41,12 +42,12 @@ static inline struct sk_buff
*rpl_vlan_insert_tag_set_proto(struct sk_buff *skb,
skb->mac_header -= VLAN_HLEN;
/* first, the ethernet type */
- veth->h_vlan_proto = htons(ETH_P_8021Q);
+ veth->h_vlan_proto = vlan_proto;
/* now, the TCI */
veth->h_vlan_TCI = htons(vlan_tci);
- skb->protocol = htons(ETH_P_8021Q);
+ skb->protocol = vlan_proto;
return skb;
}
_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
