From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path:
Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124])
by inbox.dpdk.org (Postfix) with ESMTP id A34B543C90;
Tue, 12 Mar 2024 11:14:53 +0100 (CET)
Received: from mails.dpdk.org (localhost [127.0.0.1])
by mails.dpdk.org (Postfix) with ESMTP id 77434402D8;
Tue, 12 Mar 2024 11:14:53 +0100 (CET)
Received: from inbox.dpdk.org (inbox.dpdk.org [95.142.172.178])
by mails.dpdk.org (Postfix) with ESMTP id 4718C40282
for ; Tue, 12 Mar 2024 11:14:52 +0100 (CET)
Received: by inbox.dpdk.org (Postfix, from userid 33)
id 34C4F43C91; Tue, 12 Mar 2024 11:14:52 +0100 (CET)
From: bugzilla@dpdk.org
To: dev@dpdk.org
Subject: [DPDK/testpmd Bug 1399] Intel X710 (i40e): cannot configure RSS with
testpmd and rte_flow API
Date: Tue, 12 Mar 2024 10:14:51 +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: 23.11
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: anton@vaa.su
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: multipart/alternative; boundary=17102384920.55d10e38A.3050465
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://bugs.dpdk.org/
Auto-Submitted: auto-generated
X-Auto-Response-Suppress: All
MIME-Version: 1.0
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: DPDK patches and discussions
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
Errors-To: dev-bounces@dpdk.org
--17102384920.55d10e38A.3050465
Date: Tue, 12 Mar 2024 11:14:51 +0100
MIME-Version: 1.0
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
https://bugs.dpdk.org/show_bug.cgi?id=3D1399
Bug ID: 1399
Summary: Intel X710 (i40e): cannot configure RSS with testpmd
and rte_flow API
Product: DPDK
Version: 23.11
Hardware: x86
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: Normal
Component: testpmd
Assignee: dev@dpdk.org
Reporter: anton@vaa.su
Target Milestone: ---
Created attachment 277
--> https://bugs.dpdk.org/attachment.cgi?id=3D277&action=3Dedit
sample gre traffic
Environment:
- DPDK 21.11 and DPDK 23.11
- NIC: 'Ethernet Controller X710 for 10GbE SFP+ 1572'
- NIC firmware: 9.40 0x8000ed0e 1.3429.0
I've got problem with Intel X710 NIC (we have other NICs, and they work just
fine).
RSS don't work for ETH-IPV4-GRE-ERSPAN packets.
We need to setup 2-tuple RSS using IPV4 src and dst addresses only.=20
It's OK for all NICs except X710. With x710 we have all packets (with uniqu=
e IP
addresses) placed in the same RX queue.
I can reproduce it with testpmd (tried 21.11 and 23.11).
# ./build/app/dpdk-testpmd -l 0,2,4,6,8 -n 4 -- -i --portmask=3D0x1 --nb-co=
res=3D4
--rxq=3D4 --forward-mode=3Drxonly
testpmd> set verbose 1
Change verbose level from 0 to 1
testpmd> flow create 0 ingress pattern eth / ipv4 / end actions rss types i=
pv4
end queues end / end
Flow rule #0 created
testpmd> flow list 0
ID Group Prio Attr Rule
0 0 0 i-- ETH IPV4 =3D> RSS
testpmd> start
rxonly packet forwarding - ports=3D1 - cores=3D4 - streams=3D4 - NUMA suppo=
rt
enabled, MP allocation mode: native
Logical Core 2 (socket 0) forwards packets on 1 streams:
RX P=3D0/Q=3D0 (socket 0) -> TX P=3D0/Q=3D0 (socket 0) peer=3D02:00:00:00=
:00:00
Logical Core 4 (socket 0) forwards packets on 1 streams:
RX P=3D0/Q=3D1 (socket 0) -> TX P=3D0/Q=3D1 (socket 0) peer=3D02:00:00:00=
:00:00
Logical Core 6 (socket 0) forwards packets on 1 streams:
RX P=3D0/Q=3D2 (socket 0) -> TX P=3D0/Q=3D2 (socket 0) peer=3D02:00:00:00=
:00:00
Logical Core 8 (socket 0) forwards packets on 1 streams:
RX P=3D0/Q=3D3 (socket 0) -> TX P=3D0/Q=3D3 (socket 0) peer=3D02:00:00:00=
:00:00
Then I send simple eth-ipv4-udp traffic from another server:
$ tcpdump -v -r /home/pcap/syslog.pcap
14:19:00.572282 IP (tos 0x0, ttl 64, id 51158, offset 0, flags [DF], proto =
UDP
(17), length 237)
10.0.49.143.53346 > 10.10.192.162.10514: UDP, length 209
14:19:00.572956 IP (tos 0x0, ttl 64, id 51159, offset 0, flags [DF], proto =
UDP
(17), length 136)
10.0.49.143.53346 > 10.10.192.162.10514: UDP, length 108
...
$ tcpreplay -K -i ens3f1 --pps 1 -l 0 --unique-ip /home/pcap/syslog.pcap
...
In testpmd I see following:
testpmd> port 0/queue 0: received 1 packets
src=3D60:22:32:14:09:DD - dst=3D00:1C:7F:6C:8E:20 - type=3D0x0800 - lengt=
h=3D251 -
nb_segs=3D1 - hw ptype: L2_ETHER L3_IPV4_EXT_UNKNOWN L4_UDP - sw ptype: L2=
_ETHER
L3_IPV4 L4_UDP - l2_len=3D14 - l3_len=3D20 - l4_len=3D8 - Receive queue=3D=
0x0
ol_flags: RTE_MBUF_F_RX_L4_CKSUM_GOOD RTE_MBUF_F_RX_IP_CKSUM_GOOD
RTE_MBUF_F_RX_OUTER_L4_CKSUM_UNKNOWN=20
port 0/queue 0: received 1 packets
!!! RSS wasn't computed at all, and all packets are placed in queue 0.
Speedup TX, and check stats:
testpmd> show fwd stats all
------- Forward Stats for RX Port=3D 0/Queue=3D 0 -> TX Port=3D 0/Queue=
=3D 0 -------
RX-packets: 111974 TX-packets: 0 TX-dropped: 0=20=20=
=20=20=20=20=20=20=20=20=20
---------------------- Forward statistics for port 0 -------------------=
---
RX-packets: 111974 RX-dropped: 0 RX-total: 111974
TX-packets: 0 TX-dropped: 0 TX-total: 0
-------------------------------------------------------------------------=
---
Now if I add flow rule for eth-ipv4-udp:
testpmd> flow create 0 ingress pattern eth / ipv4 / udp / end actions rss t=
ypes
ipv4 end queues end / end
i40e_check_write_global_reg(): i40e device 0000:4c:00.2 changed global regi=
ster
[0x002676fc]. original: 0x0001801e, new: 0x00018018
Flow rule #1 created
testpmd> show port 0 rss-hash=20
RSS functions:
ipv4-frag ipv4-udp ipv4-other
!!! Then RSS will work for UDP packets (we can see RSS hash=3D0x2110f405, s=
o hash
was calculated):
testpmd> port 0/queue 1: received 1 packets
src=3D60:22:32:14:09:DD - dst=3D00:1C:7F:6C:8E:20 - type=3D0x0800 - lengt=
h=3D251 -
nb_segs=3D1 - RSS hash=3D0x2110f405 - RSS queue=3D0x1 - hw ptype: L2_ETHER
L3_IPV4_EXT_UNKNOWN L4_UDP - sw ptype: L2_ETHER L3_IPV4 L4_UDP - l2_len=
=3D14 -
l3_len=3D20 - l4_len=3D8 - Receive queue=3D0x1
testpmd> show fwd stats all
------- Forward Stats for RX Port=3D 0/Queue=3D 0 -> TX Port=3D 0/Queue=
=3D 0 -------
RX-packets: 8898 TX-packets: 0 TX-dropped: 0=20=20=
=20=20=20=20=20=20=20=20=20
------- Forward Stats for RX Port=3D 0/Queue=3D 1 -> TX Port=3D 0/Queue=
=3D 1 -------
RX-packets: 17796 TX-packets: 0 TX-dropped: 0=20=20=
=20=20=20=20=20=20=20=20=20
------- Forward Stats for RX Port=3D 0/Queue=3D 2 -> TX Port=3D 0/Queue=
=3D 2 -------
RX-packets: 30156 TX-packets: 0 TX-dropped: 0=20=20=
=20=20=20=20=20=20=20=20=20
------- Forward Stats for RX Port=3D 0/Queue=3D 3 -> TX Port=3D 0/Queue=
=3D 3 -------
RX-packets: 17796 TX-packets: 0 TX-dropped: 0=20=20=
=20=20=20=20=20=20=20=20=20
---------------------- Forward statistics for port 0 -------------------=
---
RX-packets: 74647 RX-dropped: 0 RX-total: 74647
TX-packets: 0 TX-dropped: 0 TX-total: 0
-------------------------------------------------------------------------=
---
Now if I take another pcap with GRE-ERSPAN traffic
$ tcpdump -v -r /home/pcap/eth-ip-gre-erspan.pcap=20
23:41:12.550628 IP (tos 0x0, ttl 255, id 1517, offset 0, flags [DF], proto =
GRE
(47), length 110)
1.1.1.2 > 198.18.1.2: GREv0, Flags [sequence# present], seq 2029, lengt=
h 90
gre-proto-0x88be
...
23:48:56.055419 IP (tos 0x0, ttl 255, id 1899, offset 0, flags [DF], proto =
GRE
(47), length 110)
2.2.2.2 > 198.18.1.2: GREv0, Flags [sequence# present], seq 5368, lengt=
h 90
gre-proto-0x88be
...
$ tcpreplay -K -i ens3f1 --pps 1 -l 0 --unique-ip /home/eth-ip-gre-erspan.p=
cap
Testpmd reports:
testpmd> port 0/queue 0: received 1 packets
src=3D54:7F:EE:CE:25:BC - dst=3D6C:2B:59:7B:E5:92 - type=3D0x0800 - lengt=
h=3D124 -
nb_segs=3D1 - hw ptype: L2_ETHER L3_IPV4_EXT_UNKNOWN TUNNEL_GRENAT - sw pt=
ype:
L2_ETHER L3_IPV4 TUNNEL_GRE - l2_len=3D14 - l3_len=3D20 - tunnel_len=3D8 -=
Receive
queue=3D0x0
ol_flags: RTE_MBUF_F_RX_L4_CKSUM_GOOD RTE_MBUF_F_RX_IP_CKSUM_GOOD
RTE_MBUF_F_RX_OUTER_L4_CKSUM_UNKNOWN=20
port 0/queue 0: received 1 packets
!!! Again, RSS wasn't computed at all, and all packets are placed in queue =
0.
Let's try to make a flow rule for GRE:
testpmd> flow create 0 ingress pattern eth / ipv4 / gre / end actions rss t=
ypes
ipv4 end queues end / end
port_flow_complain(): Caught PMD error type 13 (specific pattern item): cau=
se:
0x7ffcdca24938, Pattern not supported: Operation not supported
Driver failed to make it. If we try simple drop rule instead of RSS:
testpmd> flow create 0 ingress pattern eth / ipv4 / gre / end actions drop /
end
port_flow_complain(): Caught PMD error type 13 (specific pattern item): cau=
se:
0x7ffcdca248f8, Unsupported pattern: Invalid argument
Failed again.
GDB can highlight some details. Let's see what happened inside and which it=
em
has the problem address.
Restart testpmd under the debugger:
(gdb) bt
#0 i40e_flow_validate (dev=3D0x56298c45fec0 ,
attr=3D0x7ffeb453a658, pattern=3D0x7ffeb453a6e8, actions=3D0x7ffeb453a768,
error=3D0x7ffeb4538570) at ../drivers/net/i40e/i40e_flow.c:4610
#1 0x00005629882eb059 in i40e_flow_create (dev=3D0x56298c45fec0
, attr=3D0x7ffeb453a658, pattern=3D0x7ffeb453a6e8,
actions=3D0x7ffeb453a768, error=3D0x7ffeb4538570) at
../drivers/net/i40e/i40e_flow.c:4638
#2 0x0000562987677d5d in rte_flow_create (port_id=3D0, attr=3D0x7ffeb453a6=
58,
pattern=3D0x7ffeb453a6e8, actions=3D0x7ffeb453a768, error=3D0x7ffeb4538570)=
at
../lib/ethdev/rte_flow.c:390
#3 0x00005629871ca71b in port_flow_create (port_id=3D0, attr=3D0x7ffeb453a=
658,
pattern=3D0x7ffeb453a6e8, actions=3D0x7ffeb453a768, tunnel_ops=3D0x7ffeb453=
a664) at
../app/test-pmd/config.c:2057
#4 0x00005629871a92ad in cmd_flow_parsed (in=3D0x7ffeb453a650) at
../app/test-pmd/cmdline_flow.c:8722
#5 0x00005629871a94c0 in cmd_flow_cb (arg0=3D0x7ffeb453a650, cl=3D0x56298d=
f99190,
arg2=3D0x0) at ../app/test-pmd/cmdline_flow.c:8784
#6 0x000056298765d372 in cmdline_parse (cl=3D0x56298df99190, buf=3D0x56298=
df991d8
"flow create 0 ingress pattern eth / ipv4 / gre / end actions drop / end\n"=
) at
../lib/cmdline/cmdline_parse.c:290
#7 0x000056298765b877 in cmdline_valid_buffer (rdl=3D0x56298df991a0,
buf=3D0x56298df991d8 "flow create 0 ingress pattern eth / ipv4 / gre / end
actions drop / end\n", size=3D73) at ../lib/cmdline/cmdline.c:26
#8 0x0000562987660287 in rdline_char_in (rdl=3D0x56298df991a0, c=3D10 '\n'=
) at
../lib/cmdline/cmdline_rdline.c:446
#9 0x000056298765bc6c in cmdline_in (cl=3D0x56298df99190, buf=3D0x7ffeb453=
e7af
"\n\320\347S\264\376\177", size=3D1) at ../lib/cmdline/cmdline.c:148
#10 0x000056298765beb3 in cmdline_interact (cl=3D0x56298df99190) at
../lib/cmdline/cmdline.c:222
#11 0x00005629871a10a3 in prompt () at ../app/test-pmd/cmdline.c:18001
#12 0x0000562987230d6b in main (argc=3D9, argv=3D0x7ffeb453e960) at
../app/test-pmd/testpmd.c:4263
(gdb) p *error
$22 =3D {type =3D RTE_FLOW_ERROR_TYPE_ITEM, cause =3D 0x7ffeb453a6e8, messa=
ge =3D
0x56298ba09e1a "Unsupported pattern"}
(gdb) p *(struct rte_flow_item*)0x7ffeb453a6e8
$27 =3D {type =3D RTE_FLOW_ITEM_TYPE_ETH, spec =3D 0x0, last =3D 0x0, mask =
=3D 0x0}
Looks like parser cannot handle the whole set of patterns.
What should I do to make RSS work?
--=20
You are receiving this mail because:
You are the assignee for the bug.=
--17102384920.55d10e38A.3050465
Date: Tue, 12 Mar 2024 11:14:52 +0100
MIME-Version: 1.0
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://bugs.dpdk.org/
Auto-Submitted: auto-generated
X-Auto-Response-Suppress: All
Bug ID |
1399
|
Summary |
Intel X710 (i40e): cannot configure RSS with testpmd and rte_=
flow API
|
Product |
DPDK
|
Version |
23.11
|
Hardware |
x86
|
OS |
Linux
|
Status |
UNCONFIRMED
|
Severity |
normal
|
Priority |
Normal
|
Component |
testpmd
|
Assignee |
dev@dpdk.org
|
Reporter |
anton@vaa.su
|
Target Milestone |
---
|
You are receiving this mail because:
- You are the assignee for the bug.
=20=20=20=20=20=20=20=20=20=20
=
--17102384920.55d10e38A.3050465--
Created attachment 277 [details] sample gre traffic Environment: - DPDK 21.11 and DPDK 23.11 - NIC: 'Ethernet Controller X710 for 10GbE SFP+ 1572' - NIC firmware: 9.40 0x8000ed0e 1.3429.0 I've got problem with Intel X710 NIC (we have other NICs, and they work just fine). RSS don't work for ETH-IPV4-GRE-ERSPAN packets. We need to setup 2-tuple RSS using IPV4 src and dst addresses only.=20 It's OK for all NICs except X710. With x710 we have all packets (with uniqu= e IP addresses) placed in the same RX queue. I can reproduce it with testpmd (tried 21.11 and 23.11). # ./build/app/dpdk-testpmd -l 0,2,4,6,8 -n 4 -- -i --portmask=3D0x1 --nb-co= res=3D4 --rxq=3D4 --forward-mode=3Drxonly testpmd> set verbose 1 Change verbose level from 0 to 1 testpmd> flow create 0 ingress pattern eth / ipv4 / end actions rss type= s ipv4 end queues end / end Flow rule #0 created testpmd> flow list 0 ID Group Prio Attr Rule 0 0 0 i-- ETH IPV4 =3D> RSS testpmd> start rxonly packet forwarding - ports=3D1 - cores=3D4 - streams=3D4 - NUMA suppo= rt enabled, MP allocation mode: native Logical Core 2 (socket 0) forwards packets on 1 streams: RX P=3D0/Q=3D0 (socket 0) -> TX P=3D0/Q=3D0 (socket 0) peer=3D02:00:00= :00:00:00 Logical Core 4 (socket 0) forwards packets on 1 streams: RX P=3D0/Q=3D1 (socket 0) -> TX P=3D0/Q=3D1 (socket 0) peer=3D02:00:00= :00:00:00 Logical Core 6 (socket 0) forwards packets on 1 streams: RX P=3D0/Q=3D2 (socket 0) -> TX P=3D0/Q=3D2 (socket 0) peer=3D02:00:00= :00:00:00 Logical Core 8 (socket 0) forwards packets on 1 streams: RX P=3D0/Q=3D3 (socket 0) -> TX P=3D0/Q=3D3 (socket 0) peer=3D02:00:00= :00:00:00 Then I send simple eth-ipv4-udp traffic from another server: $ tcpdump -v -r /home/pcap/syslog.pcap 14:19:00.572282 IP (tos 0x0, ttl 64, id 51158, offset 0, flags [DF], proto = UDP (17), length 237) 10.0.49.143.53346 > 10.10.192.162.10514: UDP, length 209 14:19:00.572956 IP (tos 0x0, ttl 64, id 51159, offset 0, flags [DF], proto = UDP (17), length 136) 10.0.49.143.53346 > 10.10.192.162.10514: UDP, length 108 ... $ tcpreplay -K -i ens3f1 --pps 1 -l 0 --unique-ip /home/pcap/syslog.pcap ... In testpmd I see following: testpmd> port 0/queue 0: received 1 packets src=3D60:22:32:14:09:DD - dst=3D00:1C:7F:6C:8E:20 - type=3D0x0800 - lengt= h=3D251 - nb_segs=3D1 - hw ptype: L2_ETHER L3_IPV4_EXT_UNKNOWN L4_UDP - sw ptype: L2= _ETHER L3_IPV4 L4_UDP - l2_len=3D14 - l3_len=3D20 - l4_len=3D8 - Receive queue=3D= 0x0 ol_flags: RTE_MBUF_F_RX_L4_CKSUM_GOOD RTE_MBUF_F_RX_IP_CKSUM_GOOD RTE_MBUF_F_RX_OUTER_L4_CKSUM_UNKNOWN=20 port 0/queue 0: received 1 packets !!! RSS wasn't computed at all, and all packets are placed in queue 0. Speedup TX, and check stats: testpmd> show fwd stats all ------- Forward Stats for RX Port=3D 0/Queue=3D 0 -> TX Port=3D 0/Queu= e=3D 0 ------- RX-packets: 111974 TX-packets: 0 TX-dropped: 0=20=20= =20=20=20=20=20=20=20=20=20 ---------------------- Forward statistics for port 0 -------------------= --- RX-packets: 111974 RX-dropped: 0 RX-total: 111974 TX-packets: 0 TX-dropped: 0 TX-total: 0 -------------------------------------------------------------------------= --- Now if I add flow rule for eth-ipv4-udp: testpmd> flow create 0 ingress pattern eth / ipv4 / udp / end actions rs= s types ipv4 end queues end / end i40e_check_write_global_reg(): i40e device 0000:4c:00.2 changed global regi= ster [0x002676fc]. original: 0x0001801e, new: 0x00018018 Flow rule #1 created testpmd> show port 0 rss-hash=20 RSS functions: ipv4-frag ipv4-udp ipv4-other !!! Then RSS will work for UDP packets (we can see RSS hash=3D0x2110f405, s= o hash was calculated): testpmd> port 0/queue 1: received 1 packets src=3D60:22:32:14:09:DD - dst=3D00:1C:7F:6C:8E:20 - type=3D0x0800 - lengt= h=3D251 - nb_segs=3D1 - RSS hash=3D0x2110f405 - RSS queue=3D0x1 - hw ptype: L2_ETHER L3_IPV4_EXT_UNKNOWN L4_UDP - sw ptype: L2_ETHER L3_IPV4 L4_UDP - l2_len= =3D14 - l3_len=3D20 - l4_len=3D8 - Receive queue=3D0x1 testpmd> show fwd stats all ------- Forward Stats for RX Port=3D 0/Queue=3D 0 -> TX Port=3D 0/Queu= e=3D 0 ------- RX-packets: 8898 TX-packets: 0 TX-dropped: 0=20=20= =20=20=20=20=20=20=20=20=20 ------- Forward Stats for RX Port=3D 0/Queue=3D 1 -> TX Port=3D 0/Queu= e=3D 1 ------- RX-packets: 17796 TX-packets: 0 TX-dropped: 0=20=20= =20=20=20=20=20=20=20=20=20 ------- Forward Stats for RX Port=3D 0/Queue=3D 2 -> TX Port=3D 0/Queu= e=3D 2 ------- RX-packets: 30156 TX-packets: 0 TX-dropped: 0=20=20= =20=20=20=20=20=20=20=20=20 ------- Forward Stats for RX Port=3D 0/Queue=3D 3 -> TX Port=3D 0/Queu= e=3D 3 ------- RX-packets: 17796 TX-packets: 0 TX-dropped: 0=20=20= =20=20=20=20=20=20=20=20=20 ---------------------- Forward statistics for port 0 -------------------= --- RX-packets: 74647 RX-dropped: 0 RX-total: 74647 TX-packets: 0 TX-dropped: 0 TX-total: 0 -------------------------------------------------------------------------= --- Now if I take another pcap with GRE-ERSPAN traffic $ tcpdump -v -r /home/pcap/eth-ip-gre-erspan.pcap=20 23:41:12.550628 IP (tos 0x0, ttl 255, id 1517, offset 0, flags [DF], proto = GRE (47), length 110) 1.1.1.2 > 198.18.1.2: GREv0, Flags [sequence# present], seq 2029, le= ngth 90 gre-proto-0x88be ... 23:48:56.055419 IP (tos 0x0, ttl 255, id 1899, offset 0, flags [DF], proto = GRE (47), length 110) 2.2.2.2 > 198.18.1.2: GREv0, Flags [sequence# present], seq 5368, le= ngth 90 gre-proto-0x88be ... $ tcpreplay -K -i ens3f1 --pps 1 -l 0 --unique-ip /home/eth-ip-gre-erspan.p= cap Testpmd reports: testpmd> port 0/queue 0: received 1 packets src=3D54:7F:EE:CE:25:BC - dst=3D6C:2B:59:7B:E5:92 - type=3D0x0800 - lengt= h=3D124 - nb_segs=3D1 - hw ptype: L2_ETHER L3_IPV4_EXT_UNKNOWN TUNNEL_GRENAT - sw pt= ype: L2_ETHER L3_IPV4 TUNNEL_GRE - l2_len=3D14 - l3_len=3D20 - tunnel_len=3D8 -= Receive queue=3D0x0 ol_flags: RTE_MBUF_F_RX_L4_CKSUM_GOOD RTE_MBUF_F_RX_IP_CKSUM_GOOD RTE_MBUF_F_RX_OUTER_L4_CKSUM_UNKNOWN=20 port 0/queue 0: received 1 packets !!! Again, RSS wasn't computed at all, and all packets are placed in queue = 0. Let's try to make a flow rule for GRE: testpmd> flow create 0 ingress pattern eth / ipv4 / gre / end actions rs= s types ipv4 end queues end / end port_flow_complain(): Caught PMD error type 13 (specific pattern item): cau= se: 0x7ffcdca24938, Pattern not supported: Operation not supported Driver failed to make it. If we try simple drop rule instead of RSS: testpmd> flow create 0 ingress pattern eth / ipv4 / gre / end actions dr= op / end port_flow_complain(): Caught PMD error type 13 (specific pattern item): cau= se: 0x7ffcdca248f8, Unsupported pattern: Invalid argument Failed again. GDB can highlight some details. Let's see what happened inside and which it= em has the problem address. Restart testpmd under the debugger: (gdb) bt #0 i40e_flow_validate (dev=3D0x56298c45fec0 <rte_eth_devices>, attr=3D0x7ffeb453a658, pattern=3D0x7ffeb453a6e8, actions=3D0x7ffeb453a768, error=3D0x7ffeb4538570) at ../drivers/net/i40e/i40e_flow.c:4610 #1 0x00005629882eb059 in i40e_flow_create (dev=3D0x56298c45fec0 <rte_eth_devices>, attr=3D0x7ffeb453a658, pattern=3D0x7ffeb453a6e8, actions=3D0x7ffeb453a768, error=3D0x7ffeb4538570) at ../drivers/net/i40e/i40e_flow.c:4638 #2 0x0000562987677d5d in rte_flow_create (port_id=3D0, attr=3D0x7ffeb453a6= 58, pattern=3D0x7ffeb453a6e8, actions=3D0x7ffeb453a768, error=3D0x7ffeb4538570)= at ../lib/ethdev/rte_flow.c:390 #3 0x00005629871ca71b in port_flow_create (port_id=3D0, attr=3D0x7ffeb453a= 658, pattern=3D0x7ffeb453a6e8, actions=3D0x7ffeb453a768, tunnel_ops=3D0x7ffeb453= a664) at ../app/test-pmd/config.c:2057 #4 0x00005629871a92ad in cmd_flow_parsed (in=3D0x7ffeb453a650) at ../app/test-pmd/cmdline_flow.c:8722 #5 0x00005629871a94c0 in cmd_flow_cb (arg0=3D0x7ffeb453a650, cl=3D0x56298d= f99190, arg2=3D0x0) at ../app/test-pmd/cmdline_flow.c:8784 #6 0x000056298765d372 in cmdline_parse (cl=3D0x56298df99190, buf=3D0x56298= df991d8 "flow create 0 ingress pattern eth / ipv4 / gre / end actions drop / e= nd\n") at ../lib/cmdline/cmdline_parse.c:290 #7 0x000056298765b877 in cmdline_valid_buffer (rdl=3D0x56298df991a0, buf=3D0x56298df991d8 "flow create 0 ingress pattern eth / ipv4 / gre /= end actions drop / end\n", size=3D73) at ../lib/cmdline/cmdline.c:26 #8 0x0000562987660287 in rdline_char_in (rdl=3D0x56298df991a0, c=3D10 '\n'= ) at ../lib/cmdline/cmdline_rdline.c:446 #9 0x000056298765bc6c in cmdline_in (cl=3D0x56298df99190, buf=3D0x7ffeb453= e7af "\n\320\347S\264\376\177", size=3D1) at ../lib/cmdline/cmdline.c:= 148 #10 0x000056298765beb3 in cmdline_interact (cl=3D0x56298df99190) at ../lib/cmdline/cmdline.c:222 #11 0x00005629871a10a3 in prompt () at ../app/test-pmd/cmdline.c:18001 #12 0x0000562987230d6b in main (argc=3D9, argv=3D0x7ffeb453e960) at ../app/test-pmd/testpmd.c:4263 (gdb) p *error $22 =3D {type =3D RTE_FLOW_ERROR_TYPE_ITEM, cause =3D 0x7ffeb453a6e8, messa= ge =3D 0x56298ba09e1a "Unsupported pattern"} (gdb) p *(struct rte_flow_item*)0x7ffeb453a6e8 $27 =3D {type =3D RTE_FLOW_ITEM_TYPE_ETH, spec =3D 0x0, last =3D 0x0, mask = =3D 0x0} Looks like parser cannot handle the whole set of patterns. What should I do to make RSS work?