From: bugzilla@dpdk.org
To: dev@dpdk.org
Subject: [DPDK/testpmd Bug 1737] [dpdk-25.07] [CNV] ice_dcf_checksum_offload/checksum_offload_vlan_tunnel_enable: the udp_gtpu packet will affect the hardware checksum of other udp packets
Date: Thu, 03 Jul 2025 03:40:41 +0000 [thread overview]
Message-ID: <bug-1737-3@https.bugs.dpdk.org/> (raw)
[-- Attachment #1: Type: text/plain, Size: 8511 bytes --]
https://bugs.dpdk.org/show_bug.cgi?id=1737
Bug ID: 1737
Summary: [dpdk-25.07] [CNV]
ice_dcf_checksum_offload/checksum_offload_vlan_tunnel_
enable: the udp_gtpu packet will affect the hardware
checksum of other udp packets
Product: DPDK
Version: 25.03
Hardware: x86
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: Normal
Component: testpmd
Assignee: dev@dpdk.org
Reporter: songx.jiale@intel.com
Target Milestone: ---
Environment
===========
DPDK version: 5f37ee9c859f3ce08ca4364f1d8c0e70ec33ac83 version: 25.03.0-rc2
OS: Ubuntu24.04.1 LTS (Noble Numbat)/6.8.0-41-generic
Compiler: gcc version 13.2.0
Hardware platform: Intel(R) Xeon(R) Platinum 8380 CPU @ 2.30GHz
NIC hardware: Intel Corporation Ethernet Controller E830-CC for QSFP
[8086:12d2][8086:1593])
NIC firmware:
driver: vfio-pci
kdriver: ice-1.17.8
firmware-version: 1.00 0x800161b7 1.3832.0
pkg: ice comms 1.3.53.0
scapy:2.4.4
Test Setup
Steps to reproduce
==================
1. reload ice
rmmod ice && modprobe ice
2. create 1 vf and set vf echo 1 >
/sys/bus/pci/devices/0000\:af\:00.0/sriov_numvfs
ip link set ens802f0np0 vf 0 trust on
ip link set ens802f0np0 vf 0 spoofchk off
modprobe vfio && modprobe vfio-pci
./usertools/dpdk-devbind.py -b vfio-pci 0000:af:01.0
3. start testpmd x86_64-native-linuxapp-gcc/app/dpdk-testpmd -l 1-2 -n 4 -a
0000:af:01.0,cap=dcf -- -i --enable-rx-cksum
4. set testpmd
set verbose 1
set fwd csum
set promisc 0 on
port stop all
csum set ip hw 0
csum set udp hw 0
csum set tcp hw 0
csum set sctp hw 0
csum set outer-ip hw 0
csum set outer-udp hw 0
csum parse-tunnel on 0
rx_vxlan_port add 4789 0
port start all
start
5. tcpdump captures packets forwarded by testpmd
tcpdump -ei enp5s0 -Q in -w 1.pcap
6. scapy send packets
p=[
Ether(dst='00:11:22:33:44:55',
src='52:00:00:00:00:00')/Dot1Q(vlan=100)/IPv6(src='::1')/UDP(dport=2152)/GTP_U_Header(gtp_type=255,
teid=1193046)/IP(src='10.0.0.1')/UDP(sport=29999,
dport=30000)/Raw(load=b'\xce\xfd\xe9\x04\xde\xa9V<\xb6*;J\x12\xb1\xde\x00\x1d`a\x03^\xc1\xb5\x07\xad\xc4\xad>\x996sXt\x82^\xe3\xbb\xf4K\x10";J^\xa6T\xc2\x8b\xe8@\xfd\xee\xa8\x07\x9eC\xa8\xcb\xcb`\xafh0\xb8'),
Ether(dst='00:11:22:33:44:55',
src='52:00:00:00:00:00')/Dot1Q(vlan=100)/IP(src='10.0.0.1')/UDP(sport=4789,
dport=4789)/VXLAN()/Ether()/IP(src='10.0.0.1')/UDP(sport=29999,
dport=30000)/Raw(load=b'\xce\xfd\xe9\x04\xde\xa9V<\xb6*;J\x12\xb1\xde\x00\x1d`a\x03^\xc1\xb5\x07\xad\xc4\xad>\x996sXt\x82^\xe3\xbb\xf4K\x10";J^\xa6T\xc2\x8b\xe8@\xfd\xee\xa8\x07\x9eC\xa8\xcb\xcb`\xafh0\xb8'),
Ether(dst='00:11:22:33:44:55',
src='52:00:00:00:00:00')/Dot1Q(vlan=100)/IP(src='10.0.0.1')/UDP()/Raw(load=b'\xce\xfd\xe9\x04\xde\xa9V<\xb6*;J\x12\xb1\xde\x00\x1d`a\x03^\xc1\xb5\x07\xad\xc4\xad>\x996sXt\x82^\xe3\xbb\xf4K\x10";J^\xa6T\xc2\x8b\xe8@\xfd\xee\xa8\x07\x9eC\xa8\xcb\xcb`\xafh0\xb8'),
]
sendp(p, iface='enp5s0', count=1)
7. ^C exit tcpdump and scapy or wireshark parsing data packets
pkt=rdpcap('1.pcap')
Results:
========
The outer UDP checksum for p[1] and p[2] is incorrect.
>>> p[0]
<Ether dst=02:00:00:00:00:00 src=b6:90:6c:aa:47:dc type=n_802_1Q |<Dot1Q
prio=0 id=0 vlan=100 type=IPv6 |<IPv6 version=6 tc=0 fl=0 plen=108 nh=UDP
hlim=64 src=::1 dst=::1 |<UDP sport=2152 dport=2152 len=108 chksum=0x11dd
|<GTP_U_Header version=1 PT=1 reserved=0 E=0 S=0 PN=0 gtp_type=g_pdu length=92
teid=1193046 |<IP version=4 ihl=5 tos=0x0 len=92 id=1 flags= frag=0 ttl=64
proto=udp chksum=0xf18e src=10.0.0.1 dst=127.0.0.1 |<UDP sport=29999
dport=30000 len=72 chksum=0x9280 |<Raw
load='\xce\xfd\xe9\x04\xde\xa9V<\xb6*;J\x12\xb1\xde\x00\x1d`a\x03^\xc1\xb5\x07\xad\xc4\xad>\x996sXt\x82^\xe3\xbb\xf4K\x10";J^\xa6T\xc2\x8b\xe8@\xfd\xee\xa8\x07\x9eC\xa8\xcb\xcb`\xafh0\xb8'
|>>>>>>>>
>>> p[1]
<Ether dst=02:00:00:00:00:00 src=b6:90:6c:aa:47:dc type=n_802_1Q |<Dot1Q
prio=0 id=0 vlan=100 type=IPv4 |<IP version=4 ihl=5 tos=0x0 len=142 id=1
flags= frag=0 ttl=64 proto=udp chksum=0xf15c src=10.0.17.221 dst=127.0.0.1
|<UDP sport=4789 dport=4789 len=122 chksum=0x0 |<VXLAN
flags=NextProtocol+Instance reserved0=0 NextProtocol=Ethernet vni=0x0
reserved2=0x0 |<Ether dst=ff:ff:ff:ff:ff:ff src=00:00:00:00:00:00 type=IPv4
|<IP version=4 ihl=5 tos=0x0 len=92 id=1 flags= frag=0 ttl=64 proto=udp
chksum=0xf18e src=10.0.0.1 dst=127.0.0.1 |<UDP sport=29999 dport=30000 len=72
chksum=0x9280 |<Raw
load='\xce\xfd\xe9\x04\xde\xa9V<\xb6*;J\x12\xb1\xde\x00\x1d`a\x03^\xc1\xb5\x07\xad\xc4\xad>\x996sXt\x82^\xe3\xbb\xf4K\x10";J^\xa6T\xc2\x8b\xe8@\xfd\xee\xa8\x07\x9eC\xa8\xcb\xcb`\xafh0\xb8'
|>>>>>>>>>
>>> p[2]
<Ether dst=02:00:00:00:00:00 src=02:82:14:0b:94:11 type=n_802_1Q |<Dot1Q
prio=0 id=0 vlan=100 type=IPv4 |<IP version=4 ihl=5 tos=0x0 len=92 id=1 flags=
frag=0 ttl=64 proto=udp chksum=0xf18e src=10.0.0.1 dst=127.0.0.1 |<UDP
sport=domain dport=domain len=72 chksum=0xc5e6 |<DNS id=52989 qr=1 opcode=13
aa=0 tc=0 rd=1 ra=0 z=0 ad=0 cd=0 rcode=not-implemented qdcount=57001
ancount=22076 nscount=46634 arcount=15178 qd='' an='' ns='' ar='' |<Raw
load='\x12\xb1\xde\x00\x1d`a\x03^\xc1\xb5\x07\xad\xc4\xad>\x996sXt\x82^\xe3\xbb\xf4K\x10";J^\xa6T\xc2\x8b\xe8@\xfd\xee\xa8\x07\x9eC\xa8\xcb\xcb`\xafh0\xb8'
|>>>>>>
Expected Result:
================
p[1] outer udp checksum is 0xc5e6, p[2] outer udp checksum is 0x7c76
>>> p[0]
<Ether dst=02:00:00:00:00:00 src=02:82:14:0b:94:11 type=n_802_1Q |<Dot1Q
prio=0 id=0 vlan=100 type=IPv6 |<IPv6 version=6 tc=0 fl=0 plen=108 nh=UDP
hlim=64 src=::1 dst=::1 |<UDP sport=2152 dport=2152 len=108 chksum=0x11dd
|<GTP_U_Header version=1 PT=1 reserved=0 E=0 S=0 PN=0 gtp_type=g_pdu length=92
teid=1193046 |<IP version=4 ihl=5 tos=0x0 len=92 id=1 flags= frag=0 ttl=64
proto=udp chksum=0xf18e src=10.0.0.1 dst=127.0.0.1 |<UDP sport=29999
dport=30000 len=72 chksum=0x9280 |<Raw
load='\xce\xfd\xe9\x04\xde\xa9V<\xb6*;J\x12\xb1\xde\x00\x1d`a\x03^\xc1\xb5\x07\xad\xc4\xad>\x996sXt\x82^\xe3\xbb\xf4K\x10";J^\xa6T\xc2\x8b\xe8@\xfd\xee\xa8\x07\x9eC\xa8\xcb\xcb`\xafh0\xb8'
|>>>>>>>>
>>> p[1]
<Ether dst=02:00:00:00:00:00 src=02:82:14:0b:94:11 type=n_802_1Q |<Dot1Q
prio=0 id=0 vlan=100 type=IPv4 |<IP version=4 ihl=5 tos=0x0 len=142 id=1
flags= frag=0 ttl=64 proto=udp chksum=0xf15c src=10.0.0.1 dst=127.0.0.1 |<UDP
sport=4789 dport=4789 len=122 chksum=0xc5e6 |<VXLAN
flags=NextProtocol+Instance reserved0=0 NextProtocol=Ethernet vni=0x0
reserved2=0x0 |<Ether dst=ff:ff:ff:ff:ff:ff src=00:00:00:00:00:00 type=IPv4
|<IP version=4 ihl=5 tos=0x0 len=92 id=1 flags= frag=0 ttl=64 proto=udp
chksum=0xf18e src=10.0.0.1 dst=127.0.0.1 |<UDP sport=29999 dport=30000 len=72
chksum=0x9280 |<Raw
load='\xce\xfd\xe9\x04\xde\xa9V<\xb6*;J\x12\xb1\xde\x00\x1d`a\x03^\xc1\xb5\x07\xad\xc4\xad>\x996sXt\x82^\xe3\xbb\xf4K\x10";J^\xa6T\xc2\x8b\xe8@\xfd\xee\xa8\x07\x9eC\xa8\xcb\xcb`\xafh0\xb8'
|>>>>>>>>>
>>> p[2]
<Ether dst=02:00:00:00:00:00 src=02:82:14:0b:94:11 type=n_802_1Q |<Dot1Q
prio=0 id=0 vlan=100 type=IPv4 |<IP version=4 ihl=5 tos=0x0 len=92 id=1 flags=
frag=0 ttl=64 proto=udp chksum=0xf18e src=10.0.0.1 dst=127.0.0.1 |<UDP
sport=domain dport=domain len=72 chksum=0x7c76 |<DNS id=52989 qr=1 opcode=13
aa=0 tc=0 rd=1 ra=0 z=0 ad=0 cd=0 rcode=not-implemented qdcount=57001
ancount=22076 nscount=46634 arcount=15178 qd='' an='' ns='' ar='' |<Raw
load='\x12\xb1\xde\x00\x1d`a\x03^\xc1\xb5\x07\xad\xc4\xad>\x996sXt\x82^\xe3\xbb\xf4K\x10";J^\xa6T\xc2\x8b\xe8@\xfd\xee\xa8\x07\x9eC\xa8\xcb\xcb`\xafh0\xb8'
|>>>>>>
bad commit:
===========
commit b1f3a7a8c375fbb66be48aed078222686d16fdb5
Author: Dengdui Huang <huangdengdui@huawei.com>
Date: Tue Jun 3 20:06:22 2025 +0800
net: fix GTP packet parsing
After parsing the GTP packet header, the next protocol type should
be converted from RTE_GTP_TYPE_IPV4/IPV6 to RTE_ETHER_TYPE_IPV4/IPV6.
Otherwise, the next protocol cannot be parsed.
Bugzilla ID: 1672
Fixes: 64ed7f854cf4 ("net: add tunnel packet type parsing")
Cc: stable@dpdk.org
Signed-off-by: Dengdui Huang <huangdengdui@huawei.com>
Acked-by: Jie Hai <haijie1@huawei.com>
lib/net/rte_net.c | 8 +++++++-
1 file changed, 7 insertions, 1 deletion
--
You are receiving this mail because:
You are the assignee for the bug.
[-- Attachment #2: Type: text/html, Size: 11307 bytes --]
reply other threads:[~2025-07-03 3:40 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=bug-1737-3@https.bugs.dpdk.org/ \
--to=bugzilla@dpdk.org \
--cc=dev@dpdk.org \
/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).