From: Yu Jiang <yux.jiang@intel.com>
To: dts@dpdk.org, yuan.peng@intel.com
Cc: Yu Jiang <yux.jiang@intel.com>
Subject: [dts] [PATCH V1 2/3] test_plans/generic_flow_api: add case: fdir for Control levels of FDir match reporting
Date: Mon, 25 Oct 2021 14:24:51 +0800 [thread overview]
Message-ID: <1635143092-11970-3-git-send-email-yux.jiang@intel.com> (raw)
In-Reply-To: <1635143092-11970-1-git-send-email-yux.jiang@intel.com>
add plan: IXGBE fdir for Control levels of FDir match reporting
Signed-off-by: Yu Jiang <yux.jiang@intel.com>
---
test_plans/generic_flow_api_test_plan.rst | 118 ++++++++++++++++++++++++++++++
1 file changed, 118 insertions(+)
diff --git a/test_plans/generic_flow_api_test_plan.rst b/test_plans/generic_flow_api_test_plan.rst
index c1c3835..cbd41bd 100644
--- a/test_plans/generic_flow_api_test_plan.rst
+++ b/test_plans/generic_flow_api_test_plan.rst
@@ -1149,6 +1149,124 @@ Test case: IXGBE fdir for mac/vlan(support by x540, x552, x550)
testpmd> flow flush 0
testpmd> flow list 0
+Test case: IXGBE fdir for Control levels of FDir match reporting
+================================================================
+
+The status of FDir filter matching for each packet can be reported by the
+hardware through the RX descriptor of each received packet, and this information
+is copied into the packet mbuf, that can be examined by the application.
+
+There are three different reporting modes, that can be set in testpmd using the
+``--pkt-filter-report-hash`` command line argument:
+
+
+Sub-case: ``--pkt-filter-report-hash=none`` mode
+------------------------------------------------
+
+In this mode FDir reporting mode, matches are never reported.
+Start the ``testpmd`` application as follows::
+
+ ./x86_64-native-linuxapp-gcc/app/dpdk-testpmd -c 0xf -- -i --rxq=4 --txq=4 --disable-rss --pkt-filter-mode=perfect --pkt-filter-report-hash=none
+ testpmd> set verbose 1
+ testpmd> set fwd rxonly
+ testpmd> start
+
+Send the matched packet with Scapy on the traffic generator and check that no FDir information is printed::
+
+ packet: pkt0=Ether(dst="90:E2:BA:AC:99:FC")/IP(src="192.168.0.1", dst="192.168.0.2")/Raw('x' * 20)
+ testpmd> port 0/queue 0: received 1 packets
+ src=00:0C:29:B3:0E:82 - dst=90:E2:BA:AC:99:FC - type=0x0800 - length=60 - nb_segs=1 - hw ptype: L2_ETHER L3_IPV4 - sw ptype: L2_ETHER L3_IPV4 - l2_len=14 - l3_len=20 - Receive queue=0x0
+ ol_flags: PKT_RX_L4_CKSUM_GOOD PKT_RX_IP_CKSUM_GOOD PKT_RX_OUTER_L4_CKSUM_UNKNOWN
+
+Add flow filter rule, and send the matched packet again.
+No Dir information is printed, but it can be seen that the packet goes to queue 1::
+
+ testpmd> flow create 0 ingress pattern eth / ipv4 src is 192.168.0.1 dst is 192.168.0.2 / end actions queue index 1 / mark id 1 / end
+ testpmd> port 0/queue 1: received 1 packets
+ src=00:0C:29:B3:0E:82 - dst=90:E2:BA:AC:99:FC - type=0x0800 - length=60 - nb_segs=1 - hw ptype: L2_ETHER L3_IPV4 - sw ptype: L2_ETHER L3_IPV4 - l2_len=14 - l3_len=20 - Receive queue=0x1
+ ol_flags: PKT_RX_L4_CKSUM_GOOD PKT_RX_IP_CKSUM_GOOD PKT_RX_OUTER_L4_CKSUM_UNKNOWN
+ testpmd> quit
+
+Sub-case: ``--pkt-filter-report-hash=match`` mode
+-------------------------------------------------
+
+In this mode FDir reporting mode, FDir information is printed for packets that match a filter.
+Start the ``testpmd`` application as follows::
+
+ ./x86_64-native-linuxapp-gcc/app/dpdk-testpmd -c 0xf -- -i --rxq=4 --txq=4 --disable-rss --pkt-filter-mode=perfect --pkt-filter-report-hash=match
+ testpmd> set verbose 1
+ testpmd> set fwd rxonly
+ testpmd> start
+
+Send pkt0 packet with Scapy on the traffic generator and check that no FDir information is printed::
+
+ packet: pkt0=Ether(dst="90:E2:BA:AC:99:FC")/IP(src="192.168.0.1", dst="192.168.0.2")/Raw('x' * 20)
+ testpmd> port 0/queue 0: received 1 packets
+ src=00:0C:29:B3:0E:82 - dst=90:E2:BA:AC:99:FC - type=0x0800 - length=60 - nb_segs=1 - hw ptype: L2_ETHER L3_IPV4 - sw ptype: L2_ETHER L3_IPV4 - l2_len=14 - l3_len=20 - Receive queue=0x0
+ ol_flags: PKT_RX_L4_CKSUM_GOOD PKT_RX_IP_CKSUM_GOOD PKT_RX_OUTER_L4_CKSUM_UNKNOWN
+
+Add flow filter rule, and send the pkt0 packet again.
+This time, the match is indicated (``PKT_RX_FDIR``), and its details (hash, id) printed ::
+
+ testpmd> flow create 0 ingress pattern eth / ipv4 src is 192.168.0.1 dst is 192.168.0.2 / end actions queue index 1 / mark id 1 / end
+ testpmd> port 0/queue 1: received 1 packets
+ src=00:0C:29:B3:0E:82 - dst=90:E2:BA:AC:99:FC - type=0x0800 - length=60 - nb_segs=1 - FDIR matched hash=0x2f3 ID=0x1 - hw ptype: L2_ETHER L3_IPV4 - sw ptype: L2_ETHER L3_IPV4 - l2_len=14 - l3_len=20 - Receive queue=0x1
+ ol_flags: PKT_RX_FDIR PKT_RX_L4_CKSUM_GOOD PKT_RX_IP_CKSUM_GOOD PKT_RX_OUTER_L4_CKSUM_UNKNOWN
+
+Add flow filter rule by using different src,dst, and send the matched pkt1 packet again.
+This time, the match is indicated (``PKT_RX_FDIR``), and its details (hash, id) printed ::
+
+ packet: pkt1=Ether(dst="90:E2:BA:AC:99:FC")/IP(src="192.168.1.1", dst="192.168.1.2")/Raw('x' * 20)
+ testpmd> flow create 0 ingress pattern eth / ipv4 src is 192.168.1.1 dst is 192.168.1.2 / end actions queue index 2 / mark id 2 / end
+ testpmd> port 0/queue 2: received 1 packets
+ src=00:0C:29:B3:0E:82 - dst=90:E2:BA:AC:99:FC - type=0x0800 - length=64 - nb_segs=1 - FDIR matched hash=0x2f3 ID=0x2 - hw ptype: L2_ETHER L3_IPV4 - sw ptype: L2_ETHER L3_IPV4 - l2_len=14 - l3_len=20 - Receive queue=0x2
+ ol_flags: PKT_RX_FDIR PKT_RX_L4_CKSUM_GOOD PKT_RX_IP_CKSUM_GOOD PKT_RX_OUTER_L4_CKSUM_UNKNOWN
+
+Remove rule1 and send the matched pkt0 packet again. Check that no FDir information is printed::
+
+ testpmd> flow destroy 0 rule 0
+ Flow rule #0 destroyed
+ testpmd> port 0/queue 0: received 1 packets
+ src=00:0C:29:B3:0E:82 - dst=90:E2:BA:AC:99:FC - type=0x0800 - length=60 - nb_segs=1 - hw ptype: L2_ETHER L3_IPV4 - sw ptype: L2_ETHER L3_IPV4 - l2_len=14 - l3_len=20 - Receive queue=0x0
+ ol_flags: PKT_RX_L4_CKSUM_GOOD PKT_RX_IP_CKSUM_GOOD PKT_RX_OUTER_L4_CKSUM_UNKNOWN
+
+Remove rule2, and send the match pkt1 packet again. Check that no FDir information is printed::
+
+ testpmd> flow destroy 0 rule 1
+ Flow rule #1 destroyed
+ testpmd> port 0/queue 0: received 1 packets
+ src=00:0C:29:B3:0E:82 - dst=90:E2:BA:AC:99:FC - type=0x0800 - length=60 - nb_segs=1 - hw ptype: L2_ETHER L3_IPV4 - sw ptype: L2_ETHER L3_IPV4 - l2_len=14 - l3_len=20 - Receive queue=0x0
+ ol_flags: PKT_RX_L4_CKSUM_GOOD PKT_RX_IP_CKSUM_GOOD PKT_RX_OUTER_L4_CKSUM_UNKNOWN
+ testpmd> quit
+
+Sub-case: ``--pkt-filter-report-hash=always`` mode
+--------------------------------------------------
+
+In this mode FDir reporting mode, FDir information is printed for every received packet.
+Start the ``testpmd`` application as follows::
+
+ ./x86_64-native-linuxapp-gcc/app/dpdk-testpmd -c 0xf -- -i --rxq=4 --txq=4 --disable-rss --pkt-filter-mode=perfect --pkt-filter-report-hash=always
+ testpmd> set verbose 1
+ testpmd> set fwd rxonly
+ testpmd> start
+
+
+Send matched pkt0 packet with Scapy on the traffic generator and check the output (FDIR id=0x0)::
+
+ packet: pkt0=Ether(dst="90:E2:BA:AC:99:FC")/IP(src="192.168.0.1", dst="192.168.0.2")/Raw('x' * 20)
+ testpmd> port 0/queue 0: received 1 packets
+ src=00:0C:29:B3:0E:82 - dst=90:E2:BA:AC:99:FC - type=0x0800 - length=60 - nb_segs=1 - FDIR matched hash=0x2f3 ID=0x0 - hw ptype: L2_ETHER L3_IPV4 - sw ptype: L2_ETHER L3_IPV4 - l2_len=14 - l3_len=20 - Receive queue=0x0
+ ol_flags: PKT_RX_FDIR PKT_RX_L4_CKSUM_GOOD PKT_RX_IP_CKSUM_GOOD PKT_RX_OUTER_L4_CKSUM_UNKNOWN
+
+Add flow filter rule, and send the matched pkt0 packet again.
+This time, the filter ID is different, and the packet goes to queue 1 ::
+
+ testpmd> flow create 0 ingress pattern eth / ipv4 src is 192.168.0.1 dst is 192.168.0.2 / end actions queue index 1 / mark id 1 / end
+ testpmd> port 0/queue 1: received 1 packets
+ src=00:0C:29:B3:0E:82 - dst=90:E2:BA:AC:99:FC - type=0x0800 - length=60 - nb_segs=1 - FDIR matched hash=0x2f3 ID=0x1 - hw ptype: L2_ETHER L3_IPV4 - sw ptype: L2_ETHER L3_IPV4 - l2_len=14 - l3_len=20 - Receive queue=0x1
+ ol_flags: PKT_RX_FDIR PKT_RX_L4_CKSUM_GOOD PKT_RX_IP_CKSUM_GOOD PKT_RX_OUTER_L4_CKSUM_UNKNOWN
+ testpmd> quit
+
Test case: IXGBE fdir for tunnel (vxlan and nvgre)(support by x540, x552, x550)
===============================================================================
--
2.7.4
next prev parent reply other threads:[~2021-10-25 6:25 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-25 6:24 [dts] [PATCH V1 0/3] tests/generic_flow_api: add fdir's case Yu Jiang
2021-10-25 6:24 ` [dts] [PATCH V1 1/3] test_plans/fdir: move case: fdir for Control levels of FDir match reporting to generic_flow_api Yu Jiang
2021-10-25 6:24 ` Yu Jiang [this message]
2021-10-25 6:24 ` [dts] [PATCH V1 3/3] tests/generic_flow_api: add case:test_fdir_for_match_report Yu Jiang
2021-10-25 7:23 ` Jiang, YuX
2021-10-25 9:06 ` Peng, Yuan
2021-10-27 6:14 ` Tu, Lijuan
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=1635143092-11970-3-git-send-email-yux.jiang@intel.com \
--to=yux.jiang@intel.com \
--cc=dts@dpdk.org \
--cc=yuan.peng@intel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).