From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 77203A04DE; Fri, 23 Oct 2020 07:41:19 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id DA2236C96; Fri, 23 Oct 2020 07:41:16 +0200 (CEST) Received: from inbox.dpdk.org (xvm-172-178.dc0.ghst.net [95.142.172.178]) by dpdk.org (Postfix) with ESMTP id 2B5B66A6D for ; Fri, 23 Oct 2020 07:41:15 +0200 (CEST) Received: by inbox.dpdk.org (Postfix, from userid 33) id 04294A04DF; Fri, 23 Oct 2020 07:41:13 +0200 (CEST) From: bugzilla@dpdk.org To: dev@dpdk.org Date: Fri, 23 Oct 2020 05:41:13 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: DPDK X-Bugzilla-Component: testpmd X-Bugzilla-Version: 20.11 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: junx.w.zhou@intel.com X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: dev@dpdk.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter target_milestone attachments.created Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://bugs.dpdk.org/ Auto-Submitted: auto-generated X-Auto-Response-Suppress: All MIME-Version: 1.0 Subject: [dpdk-dev] [Bug 564] [dpdk-20.11]flow_classify_softnic: dpdk do not transport packet. X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" https://bugs.dpdk.org/show_bug.cgi?id=3D564 Bug ID: 564 Summary: [dpdk-20.11]flow_classify_softnic: dpdk do not transport packet. Product: DPDK Version: 20.11 Hardware: All OS: Linux Status: UNCONFIRMED Severity: normal Priority: Normal Component: testpmd Assignee: dev@dpdk.org Reporter: junx.w.zhou@intel.com Target Milestone: --- Created attachment 127 --> https://bugs.dpdk.org/attachment.cgi?id=3D127&action=3Dedit for scapy to send packet Environment DPDK version: Use make showversion or for a non-released version: git remot= e -v && git show-ref --heads 20.11-rc1 4669252e0421aaf06ff86d5339f970ebe72cbf22 Other software versions: name/version for QEMU, OVS, etc. Repeat as require= d. OS:=C2=A0Ubuntu 20.04.1 LTS/5.4.0-42-generic Compiler: gcc (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0 Hardware platform: Intel(R) Xeon(R) Gold 6139 CPU @ 2.30GHz NIC hardware: all NIC firmware:=C2=A0 driver: i40e version: 2.13.10 firmware-version: 8.00 0x80008c1a 1.2766.0 Test Setup Steps to reproduce List the steps to reproduce the issue. 1.usertools/dpdk-devbind.py --force --bind=3Dvfio-pci 0000:86:00.0 0000:86:= 00.1 2.scp -v ./dep/flow_classify_softnic.tar.gz root@10.240.183.197:/tmp 3.tar xf /tmp/flow_classify_softnic.tar.gz -C /root/dpdk/drivers/net/softnic 4.sed -i '/^pipeline RX table match/d' ./drivers/net/softnic/flow_classify_softnic/flow_ipv6_addr_hash_firmware.cli 5.sed -i '/^table action/apipeline RX table match hash ext key 16 mask FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF offset 278 buckets 16K size 64K action AP0' ./drivers/net/softnic/flow_classify_softnic/flow_ipv6_addr_hash_firmware.cli 6.sed -i '/^link LINK/d' ./drivers/net/softnic/flow_classify_softnic/flow_ipv6_addr_hash_firmware.cli 7.sed -i '1i\link LINK0 dev 0000:86:00.0' ./drivers/net/softnic/flow_classify_softnic/flow_ipv6_addr_hash_firmware.cli 8.sed -i '2i\link LINK1 dev 0000:86:00.1' ./drivers/net/softnic/flow_classify_softnic/flow_ipv6_addr_hash_firmware.cli 9.sed -i 's/^thread 4 pipeline/thread 2 pipeline/g' ./drivers/net/softnic/flow_classify_softnic/flow_ipv6_addr_hash_firmware.cli 10.x86_64-native-linuxapp-gcc/app/dpdk-testpmd --vdev 'net_softnic0,firmware=3D./drivers/net/softnic/flow_classify_softnic/flow_i= pv6_addr_hash_firmware.cli,cpu_id=3D1,conn_port=3D8086' -l 1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,= 29,30,31,32,33,34,35,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,= 55,56,57,58,59,60,61,62,63,64,65,66,67,68,69,70,71 -n 4 -w 0000:86:00.0 -w 0000:86:00.1 --file-prefix=3Ddpdk_23376_2020102319= 0059=20=20 -s 0x4 -- -i --rxq=3D2 --txq=3D2 --disable-rss --portmask=3D0x4 11.flow create 2 group 0 ingress pattern eth / ipv6 proto mask 0 src mask ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff dst mask 0:0:0:0:0:0:0:0 src spec ABCD:EF01:2345:6789:ABCD:EF01:2345:5789 dst spec 0:0:0:0:0:0:0:0 proto spec= 17 / udp src mask 0 dst mask 0 src spec 0 dst spec 0 / end actions queue index= 1 / end 12.flow create 2 group 0 ingress pattern eth / ipv6 proto mask 0 src mask ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff dst mask 0:0:0:0:0:0:0:0 src spec ABCD:EF01:2345:6789:ABCD:EF01:2345:6789 dst spec 0:0:0:0:0:0:0:0 proto spec= 17 / udp src mask 0 dst mask 0 src spec 0 dst spec 0 / end actions queue index= 0 / end 13.flow create 2 group 0 ingress pattern eth / ipv6 proto mask 0 src mask ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff dst mask 0:0:0:0:0:0:0:0 src spec ABCD:EF01:2345:6789:ABCD:EF01:2345:7789 dst spec 0:0:0:0:0:0:0:0 proto spec= 17 / udp src mask 0 dst mask 0 src spec 0 dst spec 0 / end actions queue index= 1 / end 14.flow create 2 group 0 ingress pattern eth / ipv6 proto mask 0 src mask ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff dst mask 0:0:0:0:0:0:0:0 src spec ABCD:EF01:2345:6789:ABCD:EF01:2345:8789 dst spec 0:0:0:0:0:0:0:0 proto spec= 17 / udp src mask 0 dst mask 0 src spec 0 dst spec 0 / end actions queue index= 0 / end 15.start 16.tester: scapy 17.tester: pkt =3D rdpcap("/tmp/route_0.pcap") 18.tester: sendp(pkt, iface=3D"ens10", count=3D1) 19.tester: tcpdump -n -e -Q in -w /tmp/tcpdump_ens11.pcap -i ens11 src host ABCD:EF01:2345:6789:ABCD:EF01:2345:5789 2> /tmp/tcpdump_ens11.out=20 (there is no packet dump) execute "show port stats all" in testpmd, there is 1 packet recieve but no transport packet. Show the output from the previous commands. # Put output in a noformat block like this. Expected Result Explain what is the expected result in text or as an example output: dump a packet, and execute "show port stats all" in testpmd, there is 1 pac= ket recieve and transport 1 packet. Regression Is this issue a regression: (Y) Version the regression was introduced: commit 09315fc83861ada1119b7ebdb258877ec68e6bd7 Author: Dekel Peled Date: Thu Oct 15 18:51:46 2020 +0300 ethdev: add VLAN attributes to ethernet and VLAN items This patch implements the change proposes in RFC [1], adding dedicated fields to ETH and VLAN items structs, to clearly define the required characteristic of a packet, and enable precise match criteria. Documentation is updated accordingly. [1] https://mails.dpdk.org/archives/dev/2020-August/177536.html Signed-off-by: Dekel Peled Acked-by: Matan Azrad Acked-by: Ori Kam commit ad976bd40d28f319d97ad7baa2bcf1d931a3e615 Author: Dekel Peled Date: Wed Oct 14 19:35:47 2020 +0300 ethdev: add extensions attributes to IPv6 item Using the current implementation of DPDK, an application cannot match on IPv6 packets, based on the existing extension headers, in a simple way. Field 'Next Header' in IPv6 header indicates type of the first extension header only. Following extension headers can't be identified by inspecting the IPv6 header. As a result, the existence or absence of specific extension headers can't be used for packet matching. For example, fragmented IPv6 packets contain a dedicated extension header (which is implemented in a later patch of this series). Non-fragmented packets don't contain the fragment extension header. For an application to match on non-fragmented IPv6 packets, the current implementation doesn't provide a suitable solution. Matching on the Next Header field is not sufficient, since additional extension headers might be present in the same packet. To match on fragmented IPv6 packets, the same difficulty exists. This patch implements the update as detailed in RFC [1]. A set of additional values will be added to IPv6 header struct. These values will indicate the existence of every defined extension header type, providing simple means for identification of existing extensions in the packet header. Continuing the above example, fragmented packets can be identified using the specific value indicating existence of fragment extension header. To match on non-fragmented IPv6 packets, need to use has_frag_ext 0. To match on fragmented IPv6 packets, need to use has_frag_ext 1. To match on any IPv6 packets, the has_frag_ext field should not be specified for match. [1] https://mails.dpdk.org/archives/dev/2020-August/177257.html Signed-off-by: Dekel Peled Acked-by: Ori Kam Acked-by: Ajit Khaparde Acked-by: Thomas Monjalon --=20 You are receiving this mail because: You are the assignee for the bug.=