diff mbox

[net-next,mlxsw] selftests: mlxsw: Don't rely on MZ's range notation

Message ID 332b4984fc9f0bb93b49167840409e5853c0be37.1526313067.git.petrm@mellanox.com (mailing list archive)
State Accepted
Delegated to: Ido Schimmel
Headers show

Commit Message

Petr Machata May 14, 2018, 3:52 p.m. UTC
When given a range, mausezahn should attempt to send a packet for each
address in the range. However, some of the packets are dropped, and in
some cases even just a single packet is sent. Just run MZ separately for
each packet, which works reliably.

Signed-off-by: Petr Machata <petrm@mellanox.com>
---

Notes:
    This should fix the regression that we have been observing on
    r-mgtswd-261.

 tools/testing/selftests/drivers/net/mlxsw/tc_flower_scale.sh | 8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)

Comments

Jiri Pirko May 14, 2018, 4:05 p.m. UTC | #1
Mon, May 14, 2018 at 05:52:42PM CEST, petrm@mellanox.com wrote:
>When given a range, mausezahn should attempt to send a packet for each
>address in the range. However, some of the packets are dropped, and in
>some cases even just a single packet is sent. Just run MZ separately for

Is it a bug in MZ?


>each packet, which works reliably.
>
>Signed-off-by: Petr Machata <petrm@mellanox.com>
>---
>
>Notes:
>    This should fix the regression that we have been observing on
>    r-mgtswd-261.
>
> tools/testing/selftests/drivers/net/mlxsw/tc_flower_scale.sh | 8 +++++---
> 1 file changed, 5 insertions(+), 3 deletions(-)
>
>diff --git a/tools/testing/selftests/drivers/net/mlxsw/tc_flower_scale.sh b/tools/testing/selftests/drivers/net/mlxsw/tc_flower_scale.sh
>index 963f4cb..a6d733d 100644
>--- a/tools/testing/selftests/drivers/net/mlxsw/tc_flower_scale.sh
>+++ b/tools/testing/selftests/drivers/net/mlxsw/tc_flower_scale.sh
>@@ -94,9 +94,11 @@ __tc_flower_test()
> 
> 	tc_flower_rules_create $count $should_fail
> 
>-	$MZ $h1 -q -c 1 -t ip -p 20 -b bc -6 \
>-		  -A 2001:db8:2::1 \
>-		  -B $(tc_flower_addr 0)-$(tc_flower_addr $last)
>+	for ((i = 0; i < count; ++i)); do
>+		$MZ $h1 -q -c 1 -t ip -p 20 -b bc -6 \
>+			-A 2001:db8:2::1 \
>+			-B $(tc_flower_addr $i)
>+	done
> 
> 	MISMATCHES=$(
> 		tc -j -s filter show dev $h2 ingress |
>-- 
>2.4.11
>
>_______________________________________________
>Linux-mlxsw mailing list
>Linux-mlxsw@lists.ozlabs.org
>https://lists.ozlabs.org/listinfo/linux-mlxsw
Ido Schimmel May 14, 2018, 4:07 p.m. UTC | #2
On Mon, May 14, 2018 at 05:52:42PM +0200, Petr Machata wrote:
> When given a range, mausezahn should attempt to send a packet for each
> address in the range. However, some of the packets are dropped, and in
> some cases even just a single packet is sent. Just run MZ separately for
> each packet, which works reliably.
> 
> Signed-off-by: Petr Machata <petrm@mellanox.com>

Squashed to: "selftests: mlxsw: Add tc flower scale test"

Thanks
Petr Machata May 14, 2018, 9:02 p.m. UTC | #3
Jiri Pirko <jiri@resnulli.us> writes:

> Mon, May 14, 2018 at 05:52:42PM CEST, petrm@mellanox.com wrote:
>>When given a range, mausezahn should attempt to send a packet for each
>>address in the range. However, some of the packets are dropped, and in
>>some cases even just a single packet is sent. Just run MZ separately for
>
> Is it a bug in MZ?

Pretty sure. I looked into the code, and it's surprisingly poor quality.
I'm getting some valgrind citations that look relevant, but can't quite
pinpoint what's going on. But that seems to be the reason I was seeing
the occasional one-packet runs.

Petr
Petr Machata May 14, 2018, 10:19 p.m. UTC | #4
Petr Machata <petrm@mellanox.com> writes:

> Jiri Pirko <jiri@resnulli.us> writes:
>
>> Mon, May 14, 2018 at 05:52:42PM CEST, petrm@mellanox.com wrote:
>>>When given a range, mausezahn should attempt to send a packet for each
>>>address in the range. However, some of the packets are dropped, and in
>>>some cases even just a single packet is sent. Just run MZ separately for
>>
>> Is it a bug in MZ?
>
> I'm getting some valgrind citations that look relevant, but can't
> quite pinpoint what's going on.

Fix for the single-packet runs:
    https://groups.google.com/forum/#!topic/netsniff-ng/6YGUz_Lq8NU

The other drops, I think, might be caused by socket buffer limitations
and can be gotten rid of by -d 1m or similar. But due to the above bug
it's better not to rely on IPv6 address ranges.

Petr
diff mbox

Patch

diff --git a/tools/testing/selftests/drivers/net/mlxsw/tc_flower_scale.sh b/tools/testing/selftests/drivers/net/mlxsw/tc_flower_scale.sh
index 963f4cb..a6d733d 100644
--- a/tools/testing/selftests/drivers/net/mlxsw/tc_flower_scale.sh
+++ b/tools/testing/selftests/drivers/net/mlxsw/tc_flower_scale.sh
@@ -94,9 +94,11 @@  __tc_flower_test()
 
 	tc_flower_rules_create $count $should_fail
 
-	$MZ $h1 -q -c 1 -t ip -p 20 -b bc -6 \
-		  -A 2001:db8:2::1 \
-		  -B $(tc_flower_addr 0)-$(tc_flower_addr $last)
+	for ((i = 0; i < count; ++i)); do
+		$MZ $h1 -q -c 1 -t ip -p 20 -b bc -6 \
+			-A 2001:db8:2::1 \
+			-B $(tc_flower_addr $i)
+	done
 
 	MISMATCHES=$(
 		tc -j -s filter show dev $h2 ingress |