tx_preparation/tx_preparation:IPV6/TCP packets TSO checksum incorrect
[email protected]
Acked-by Olivier Matzhttps://bugs.dpdk.org/show_bug.cgi?id=513
Bug ID: 513
Summary: [dpdk-20.08]tx_preparation/tx_preparation:IPV6/TCP
packets TSO checksum incorrect
Product: DPDK
Version: 20.08
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: Normal
Component: testpmd
Assignee: [email protected]
Reporter: [email protected]Target Milestone: ---
DPDK version: Use make showversion or for a non-released version: git remote -v && git show-ref --heads
20.08-rc2 3126c6e04118e92364571b7020f7bb1567bac694
Other software versions: name/version for QEMU, OVS, etc. Repeat as required. OS:linux64(Ubuntu20.04,Ubuntu18.04,CentOS8.2,REHL8.2.... )5.4.0-26-generic...
Compiler: gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-39) & gcc (GCC) 8.3.1 20191121 (Red Hat 8.3.1-5) ...
Hardware platform: Intel(R) Xeon(R) Gold 6139 CPU @ 2.30GHz&Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz &Intel(R) Xeon(R) CPU E5-2699 v4 @ 2.20GHz ....... NIC hardware: carlsville springville fortville_25g powerville foxville SUSE15 NIC firmware:i40e, igb,igc,ixgbe
Test Setup
Steps to reproduce
1.tester: ethtool -K eth0 rx off tx off tso off gso off gro off lro
off
2.tester: ifconfig eth0 mtu 90003.usertools/dpdk-devbind.py --force --bind=vfio-pci 0000:3d:00.0 0000:3d:00.1 4../x86_64-native-linuxapp-gcc/app/testpmd -l 1,2 -n 4 -w 0000:3d:00.0 -w
0000:3d:00.1 --file-prefix=dpdk_9602_20200723104126 -- -i --portmask=1
--port-topology=chained --max-pkt-len=9000 --tx-offloads=0x8000 5.show port info 0
6.set fwd csum
7.set verbose 1
8.port stop all
9.csum set ip hw 0
10.csum set tcp hw 0
11.csum set udp hw 0
12.tso set 1460 0
13.port start all
14.start
15.tester:tcpdump ether[12:2]!=0x88cc and ether src A4:BF:01:3E:21:54 -i eth0
-n -e -vv -w ./getPackageByTcpdump.cap 2> /dev/null&
16.tester: sendp([Ether(dst="A4:BF:01:3E:21:54")/IPv6()/TCP(flags=0x10)
/Raw(RandString(4258))], iface="eth0", count=4)
17.tester: tcpdump -nn -e -v -r ./getPackageByTcpdump.cap
Expected Result:
10:42:13.463210 a4:bf:01:3e:21:54 > 02:00:00:00:00:00, ethertype IPv6 (0x86dd), length 1534: (hlim 64, next-header TCP (6) payload length: 1480) ::.20 > ::1.80: Flags [.], cksum 0x6ba5 (correct), seq 0:1460, ack 0, win 8192, length 1460: HTTP
Actual results:
10:38:32.600209 a4:bf:01:3e:21:54 > 02:00:00:00:00:00, ethertype IPv6 (0x86dd), length 1534: (hlim 64, next-header TCP (6) payload length: 1480) ::.20 > ::1.80: Flags [.], cksum 0xf7b6 (incorrect -> 0xf7af), seq 0:1460, ack 0, win 8192, length 1460: HTTP
Regression
Is this issue a regression: Y
commit 520059a41aa9b263d4f5dd2337e9e543441277de
Author: Andrew Rybchenko <[email protected]>
Date: Mon Jul 13 15:22:34 2020 +0100
net: check fragmented headers in non-debug as well
Pseudo-header checksum calculation requires contiguous headers. There is no any formal requirements on data location and mbuf structure which could be used by the application.
Since
commit dfc6b2fd8da3 ("mbuf: remove Intel offload checks from generic API")
fragmented headers checks are done inside rte_net_intel_cksum_flags_prepare() in RTE_LIBRTE_ETHDEV_DEBUG build because it is moved from rte_validate_tx_offload() which is called under debug only.
Make corresponding check to be done in non-debug build as well to avoid bad accesses, incorrect checksum calculation and to return appropriate error from Tx prepare.
Make no-offloads check more precise and do it in non-debug build as well to avoid contiguous headers check and Tx prepare failure if it is not actually required.
Signature · 2 lines
You are receiving this mail because: You are the assignee for the bug.
https://bugs.dpdk.org/show_bug.cgi?id=513
xizhan4x ([email protected]) changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|--- |DUPLICATE
Status|UNCONFIRMED |RESOLVED--- Comment #1 from xizhan4x ([email protected]) --- Site stuck resulting in repeated submission of bugs
*** This bug has been marked as a duplicate of bug 514 ***
Signature · 2 lines
You are receiving this mail because: You are the assignee for the bug.