All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ido Schimmel <idosch@idosch.org>
To: Zahari Doychev <zahari.doychev@linux.com>
Cc: netdev@vger.kernel.org, jhs@mojatatu.com,
	xiyou.wangcong@gmail.com, jiri@resnulli.us, davem@davemloft.net,
	edumazet@google.com, kuba@kernel.org, pabeni@redhat.com,
	hmehrtens@maxlinear.com, aleksander.lobakin@intel.com,
	simon.horman@corigine.com,
	Zahari Doychev <zdoychev@maxlinear.com>
Subject: Re: [PATCH net-next v4 3/3] selftests: net: add tc flower cfm test
Date: Sun, 30 Apr 2023 18:01:23 +0300	[thread overview]
Message-ID: <ZE6Cw0XOU9L/STZj@shredder> (raw)
In-Reply-To: <20230425211630.698373-4-zahari.doychev@linux.com>

On Tue, Apr 25, 2023 at 11:16:30PM +0200, Zahari Doychev wrote:
> From: Zahari Doychev <zdoychev@maxlinear.com>
> 
> New cfm flower test case is added to the net forwarding selfttests.
> 
> Signed-off-by: Zahari Doychev <zdoychev@maxlinear.com>
> ---
>  .../testing/selftests/net/forwarding/Makefile |   1 +
>  .../selftests/net/forwarding/tc_flower_cfm.sh | 175 ++++++++++++++++++
>  2 files changed, 176 insertions(+)
>  create mode 100755 tools/testing/selftests/net/forwarding/tc_flower_cfm.sh
> 
> diff --git a/tools/testing/selftests/net/forwarding/Makefile b/tools/testing/selftests/net/forwarding/Makefile
> index a474c60fe348..11fb97a63646 100644
> --- a/tools/testing/selftests/net/forwarding/Makefile
> +++ b/tools/testing/selftests/net/forwarding/Makefile
> @@ -83,6 +83,7 @@ TEST_PROGS = bridge_igmp.sh \
>  	tc_chains.sh \
>  	tc_flower_router.sh \
>  	tc_flower.sh \
> +	tc_flower_cfm.sh \
>  	tc_mpls_l2vpn.sh \
>  	tc_police.sh \
>  	tc_shblocks.sh \
> diff --git a/tools/testing/selftests/net/forwarding/tc_flower_cfm.sh b/tools/testing/selftests/net/forwarding/tc_flower_cfm.sh
> new file mode 100755
> index 000000000000..0509bc3c9f75
> --- /dev/null
> +++ b/tools/testing/selftests/net/forwarding/tc_flower_cfm.sh
> @@ -0,0 +1,175 @@
> +#!/bin/bash
> +# SPDX-License-Identifier: GPL-2.0
> +
> +ALL_TESTS="match_cfm_opcode match_cfm_level match_cfm_level_and_opcode"
> +NUM_NETIFS=2
> +source tc_common.sh
> +source lib.sh
> +
> +tcflags="skip_hw"
> +
> +h1_create()
> +{
> +	simple_if_init $h1 192.0.2.1/24 198.51.100.1/24

The IP address are not used in the test. Can be omitted.

> +}
> +
> +h1_destroy()
> +{
> +	simple_if_fini $h1 192.0.2.1/24 198.51.100.1/24
> +}
> +
> +h2_create()
> +{
> +	simple_if_init $h2 192.0.2.2/24 198.51.100.2/24
> +	tc qdisc add dev $h2 clsact
> +}
> +
> +h2_destroy()
> +{
> +	tc qdisc del dev $h2 clsact
> +	simple_if_fini $h2 192.0.2.2/24 198.51.100.2/24
> +}
> +
> +cfm_mdl_opcode()
> +{
> +	local mdl=$1
> +	local op=$2
> +	local flags=$3
> +	local tlv_offset=$4

If you use something like:

local mdl=$1; shift
local op=$1; shift

Then minimal changes are required if the order changes

> +
> +	printf "%02x %02x %02x %02x"    \
> +		   $((mdl << 5))             \
> +		   $((op & 0xff))             \
> +		   $((flags & 0xff)) \
> +		   $tlv_offset
> +}

See mldv2_is_in_get() in tools/testing/selftests/net/forwarding/lib.sh
and related functions for a more readable way to achieve the above.

> +
> +match_cfm_opcode()
> +{
> +	local ethtype="89 02"; readonly ethtype
> +	RET=0
> +
> +	tc filter add dev $h2 ingress protocol cfm pref 1 handle 101 \
> +	   flower cfm op 47 action drop
> +	tc filter add dev $h2 ingress protocol cfm pref 2 handle 102 \
> +	   flower cfm op 43 action drop

Both filters can use the same preference since the same mask is used.

> +
> +	pkt="$ethtype $(cfm_mdl_opcode 7 47 0 4)"
> +	$MZ $h1 -c 1 -p 64 -a $h1mac -b $h2mac "$pkt" -q
> +	pkt="$ethtype $(cfm_mdl_opcode 6 5 0 4)"
> +	$MZ $h1 -c 1 -p 64 -a $h1mac -b $h2mac "$pkt" -q
> +
> +	tc_check_packets "dev $h2 ingress" 101 1
> +	check_err $? "Did not match on correct opcode"
> +
> +	tc_check_packets "dev $h2 ingress" 102 0
> +	check_err $? "Matched on the wrong opcode"

For good measures you can send a packet with opcode 43 and check that
only 102 is hit.

> +
> +	tc filter del dev $h2 ingress protocol cfm pref 1 handle 101 flower
> +	tc filter del dev $h2 ingress protocol cfm pref 2 handle 102 flower
> +
> +	log_test "CFM opcode match test"
> +}
> +
> +match_cfm_level()
> +{
> +	local ethtype="89 02"; readonly ethtype
> +	RET=0
> +
> +	tc filter add dev $h2 ingress protocol cfm pref 1 handle 101 \
> +	   flower cfm mdl 5 action drop
> +	tc filter add dev $h2 ingress protocol cfm pref 2 handle 102 \
> +	   flower cfm mdl 3 action drop
> +	tc filter add dev $h2 ingress protocol cfm pref 3 handle 103 \
> +	   flower cfm mdl 0 action drop

Same comment about the preference.

> +
> +	pkt="$ethtype $(cfm_mdl_opcode 5 42 0 4)"
> +	$MZ $h1 -c 1 -p 64 -a $h1mac -b $h2mac "$pkt" -q
> +	pkt="$ethtype $(cfm_mdl_opcode 6 1 0 4)"
> +	$MZ $h1 -c 1 -p 64 -a $h1mac -b $h2mac "$pkt" -q
> +	pkt="$ethtype $(cfm_mdl_opcode 0 1 0 4)"
> +	$MZ $h1 -c 1 -p 64 -a $h1mac -b $h2mac "$pkt" -q
> +
> +	tc_check_packets "dev $h2 ingress" 101 1
> +	check_err $? "Did not match on correct level"
> +
> +	tc_check_packets "dev $h2 ingress" 102 0
> +	check_err $? "Matched on the wrong level"
> +
> +	tc_check_packets "dev $h2 ingress" 103 1
> +	check_err $? "Did not match on correct level"
> +
> +	tc filter del dev $h2 ingress protocol cfm pref 1 handle 101 flower
> +	tc filter del dev $h2 ingress protocol cfm pref 2 handle 102 flower
> +	tc filter del dev $h2 ingress protocol cfm pref 3 handle 103 flower
> +
> +	log_test "CFM level match test"
> +}
> +
> +match_cfm_level_and_opcode()
> +{
> +	local ethtype="89 02"; readonly ethtype
> +	RET=0
> +
> +	tc filter add dev $h2 ingress protocol cfm pref 1 handle 101 \
> +	   flower cfm mdl 5 op 41 action drop
> +	tc filter add dev $h2 ingress protocol cfm pref 2 handle 102 \
> +	   flower cfm mdl 7 op 42 action drop

Likewise

> +
> +	pkt="$ethtype $(cfm_mdl_opcode 5 41 0 4)"
> +	$MZ $h1 -c 1 -p 64 -a $h1mac -b $h2mac "$pkt" -q
> +	pkt="$ethtype $(cfm_mdl_opcode 7 3 0 4)"
> +	$MZ $h1 -c 1 -p 64 -a $h1mac -b $h2mac "$pkt" -q
> +	pkt="$ethtype $(cfm_mdl_opcode 3 42 0 4)"
> +	$MZ $h1 -c 1 -p 64 -a $h1mac -b $h2mac "$pkt" -q
> +
> +	tc_check_packets "dev $h2 ingress" 101 1
> +	check_err $? "Did not match on correct level and opcode"
> +	tc_check_packets "dev $h2 ingress" 102 0
> +	check_err $? "Matched on the wrong level and opcode"
> +
> +	tc filter del dev $h2 ingress protocol cfm pref 1 handle 101 flower
> +	tc filter del dev $h2 ingress protocol cfm pref 2 handle 102 flower
> +
> +	log_test "CFM opcode and level match test"
> +}
> +
> +setup_prepare()
> +{
> +	h1=${NETIFS[p1]}
> +	h2=${NETIFS[p2]}
> +	h1mac=$(mac_get $h1)
> +	h2mac=$(mac_get $h2)
> +
> +	vrf_prepare
> +
> +	h1_create
> +	h2_create
> +}
> +
> +cleanup()
> +{
> +	pre_cleanup
> +
> +	h2_destroy
> +	h1_destroy
> +
> +	vrf_cleanup
> +}
> +
> +trap cleanup EXIT
> +
> +setup_prepare
> +setup_wait
> +
> +tests_run
> +
> +tc_offload_check
> +if [[ $? -ne 0 ]]; then
> +	log_info "Could not test offloaded functionality"
> +else
> +	tcflags="skip_sw"
> +	tests_run
> +fi
> +
> +exit $EXIT_STATUS
> -- 
> 2.40.0
> 

  reply	other threads:[~2023-04-30 15:01 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-25 21:16 [PATCH net-next v4 0/3] net: flower: add cfm support Zahari Doychev
2023-04-25 21:16 ` [PATCH net-next v4 1/3] net: flow_dissector: add support for cfm packets Zahari Doychev
2023-04-30 14:32   ` Ido Schimmel
2023-04-30 16:33     ` Zahari Doychev
2023-04-25 21:16 ` [PATCH net-next v4 2/3] net: flower: add support for matching cfm fields Zahari Doychev
2023-04-30 14:49   ` Ido Schimmel
2023-04-30 16:35     ` Zahari Doychev
2023-05-01  6:56       ` Ido Schimmel
2023-05-03 20:15         ` Zahari Doychev
2023-04-25 21:16 ` [PATCH net-next v4 3/3] selftests: net: add tc flower cfm test Zahari Doychev
2023-04-30 15:01   ` Ido Schimmel [this message]
2023-04-30 16:37     ` Zahari Doychev
2023-04-26  7:22 ` [PATCH net-next v4 0/3] net: flower: add cfm support Leon Romanovsky

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ZE6Cw0XOU9L/STZj@shredder \
    --to=idosch@idosch.org \
    --cc=aleksander.lobakin@intel.com \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=hmehrtens@maxlinear.com \
    --cc=jhs@mojatatu.com \
    --cc=jiri@resnulli.us \
    --cc=kuba@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=simon.horman@corigine.com \
    --cc=xiyou.wangcong@gmail.com \
    --cc=zahari.doychev@linux.com \
    --cc=zdoychev@maxlinear.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.