[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAPWQB7G8RekHoTMNR5jAJGu7n2i8fNZ1=Fvj4XX_tXVSovpGug@mail.gmail.com>
Date: Thu, 25 Aug 2016 17:33:57 -0700
From: Joe Stringer <joe@....org>
To: Simon Horman <simon.horman@...ronome.com>
Cc: pravin shelar <pshelar@....org>, ovs dev <dev@...nvswitch.org>,
Linux Kernel Network Developers <netdev@...r.kernel.org>,
Jiri Benc <jbenc@...hat.com>
Subject: Re: [ovs-dev] [PATCH net-next v11 5/6] openvswitch: add layer 3
flow/port support
On 25 August 2016 at 03:08, Simon Horman <simon.horman@...ronome.com> wrote:
> Please find my working patch below.
>
> From: Simon Horman <horms@...ge.net.au>
> Subject: [PATCH] system-traffic: Exercise GSO
>
> Exercise GSO for: unencapsulated; MPLS; GRE; and MPLS in GRE.
>
> There is scope to extend this testing to other encapsulation formats
> if desired.
>
> This is motivated by a desire to test GRE and MPLS encapsulation in
> the context of L3/VPN (MPLS over non-TEB GRE work). That is not
> tested here but tests for those cases would idealy be based on those in
> this patch.
>
> Signed-off-by: Simon Horman <horms@...ge.net.au>
I realised that these tests disable TSO, but they don't actually check
if GSO is enabled. Maybe it's safe to assume this, but it's more
explicit to actually look for it in the tests.
With particular setups (fedora23 in particular, both kernel and
userspace testsuites) I see this:
./system-traffic.at:371: ip netns exec at_ns0 sh << NS_EXEC_HEREDOC
ip route add 10.1.2.0/24 encap mpls 100 via inet 10.1.1.2 dev ns_gre0
NS_EXEC_HEREDOC
--- /dev/null 2016-08-19 01:28:02.151000000 +0000
+++ /home/gitlab-runner/builds/83c49bff/0/root/gitlab-ovs/ovs/tests/system-kmod-testsuite.dir/at-groups/10/stderr
2016-08-25 17:16:27.324000000 +0000
@@ -0,0 +1 @@
+Error: either "to" is duplicate, or "encap" is a garbage.
I'm guessing the ip tool is a little out of date. We could detect and
skip this with something like:
AT_SKIP_IF([ip route help 2>&1 | grep encap])
in the CHECK_MPLS.
Hmm, I'm still seeing the bad counts of segments retransmited even
with the diff change on a kernel I have built at bf0f500bd019 ("Merge
tag 'trace-v4.8-1' of
git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace").
If it's passing on latest net-next then maybe I just need to swap out
that box's kernel for a newer build. I'll try that.
Powered by blists - more mailing lists