On Wed, Aug 10, 2016 at 04:54:08PM -0700, Joe Stringer wrote:
> On 10 August 2016 at 14:55, Eric Garver <e...@erig.me> wrote:
> > Hi,
> >
> > See two replies below.
> >
> > Thanks again!
> >
> > On Fri, Aug 05, 2016 at 10:03:24AM -0400, Eric Garver wrote:
> >> Joe,
> >>
> >> Thanks for further review. I'll add the changes you have below to the
> >> series.
> >>
> >> I'll take a look at the "check-system-userspace" failure. The "802.1ad
> >> - push/pop outer tag" test fails on at least one of my setups.
> >
> > I fixed the remaining test failures.
> > There is some work to feature flag 802.1ad support to preserve backwards
> > compatibility. I'll hold off on sending out another revision until I can
> > make the necessary test changes to support the feature flag. The feature
> > flag probably also means additional tests to cover both operating modes.
> 
> OK, fair enough. Whenever you're ready, CC me and I can provide
> feedback or apply these as appropriate.
> 
> >> On Thu, Aug 04, 2016 at 05:53:59PM -0700, Joe Stringer wrote:
> >> > Thanks for updating the series.
> >> >
> >> > With the incremental patch below this is looking pretty reliable for
> >> > check-kmod/check-kernel on the platforms I can test on, although
> >> > there's still some issue with "make check-system-userspace". It seems
> >> > like the userspace datapath cannot receive double-tagged packets from
> >> > AF_PACKET properly; it's unclear where the issue is yet.
> >
> > The frames were being sent with the wrong TPID, 0x8100 instead of
> > 0x88a8. So the kernel's VLAN device with proto 802.1ad was dropping
> > them.
> > With the below kernel commit, it works as expected.
> >
> >     a0cdfcf39362 ("packet: deliver VLAN TPID to userspace")
> >
> > I believe this commit went into the 3.14 kernel release.
> 
> OK, this would affect Ubuntu14.04 (kernel 3.13) for all of the cvlan
> tests and I see that those tests fail on that kernel.
> 
> I also see the failure below in the IPv6 case, with >MTU size packets
> on more recent kernels, do you see this also?

Yes. I've addressed it. See next comment.

> 2016-08-04T23:39:12.846Z|00029|netdev_linux|WARN|error sending
> Ethernet packet on ovs-p1: Message too long
> 
> Daniele and I took a bit of a look at this, and the simplest path
> forward is just to drop the MTU on the CVLAN interfaces to 1492. For
> some reason, some part of the netdev transmit path for AF_PACKET
> socket doesn't understand the cvlan and is appears to be treating both
> VLAN tags + the payload as the ethernet payload for MTU calculation,
> then because 1508 > 1500, returning -EMSGSIZE. For the OVS testsuite,
> we should probably adjust the MTU like this. If you'd like to follow
> up on why this is and whether a better fix can be made, that would be
> great too and a better long-term solution.

I forgot to mention it, but dropping the MTU to 1492 is exactly what I did.
There were also a couple spots in the 802.1ad tests that were using ADD_VLAN().
I replaced those with ADD_CVLAN() to make sure the MTU is set.

# ADD_CVLAN([port], [namespace], [vlan-id], [ip-addr])
#
# Similar to ADD_VLAN(), but sets MTU. Lower MTU here instead of increase MTU
# on bridge/SVLAN because older kernels didn't work.
#
m4_define([ADD_CVLAN],
    [ ADD_VLAN([$1], [$2], [$3], [$4])
      NS_CHECK_EXEC([$2], [ip link set $1.$3 mtu 1492])
    ]
)

> > This can probably be fixed in OVS userspace dataplane by detecting the
> > double tag by peaking at the ethertype. If the ethertype is 0x8100 and
> > the packet auxdata says there is another tag, then we know it's double
> > tagged and can push the 802.1ad tag. Currently this code just assumes
> > 0x8100 if the kernel didn't pass the TPID. This is all within
> > netdev_linux_rxq_recv_sock().
> 
> Thanks for the detailed investigation!

Another note, I believe this means simple port to port forwarding of 802.1ad
frames is broken in current OVS userspace dataplane (on < 3.14 kernels). It
mistakenly changes the outer TPID.

I'll have a go at fixing it independent of the full 802.1ad effort.
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Reply via email to