From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <dev-bounces@dpdk.org>
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 <dev@dpdk.org>; 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: <bug-564-3@http.bugs.dpdk.org/>
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 <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
<mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
<mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>
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 <dekelp@nvidia.com>
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 <dekelp@nvidia.com>
Acked-by: Matan Azrad <matan@nvidia.com>
Acked-by: Ori Kam <orika@nvidia.com>
commit ad976bd40d28f319d97ad7baa2bcf1d931a3e615
Author: Dekel Peled <dekelp@nvidia.com>
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 <dekelp@nvidia.com>
Acked-by: Ori Kam <orika@nvidia.com>
Acked-by: Ajit Khaparde <ajit.khaparde@broadcom.com>
Acked-by: Thomas Monjalon <thomas@monjalon.net>
--=20
You are receiving this mail because:
You are the assignee for the bug.=