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 5C7D8460F3; Thu, 23 Jan 2025 04:26:35 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id F078740294; Thu, 23 Jan 2025 04:26:34 +0100 (CET) Received: from inbox.dpdk.org (inbox.dpdk.org [95.142.172.178]) by mails.dpdk.org (Postfix) with ESMTP id B47EB40279 for ; Thu, 23 Jan 2025 04:26:33 +0100 (CET) Received: by inbox.dpdk.org (Postfix, from userid 33) id 9A2A1460F4; Thu, 23 Jan 2025 04:26:33 +0100 (CET) From: bugzilla@dpdk.org To: dev@dpdk.org Subject: [DPDK/DTS Bug 1618] l2fwd testsuite match packets failing on Nvidia connectx-6 Date: Thu, 23 Jan 2025 03:26:33 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: DPDK X-Bugzilla-Component: DTS X-Bugzilla-Version: 25.03 X-Bugzilla-Keywords: X-Bugzilla-Severity: major X-Bugzilla-Who: probb@iol.unh.edu 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 cc target_milestone Message-ID: Content-Type: multipart/alternative; boundary=17376027930.ed1C5.2219666 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 --17376027930.ed1C5.2219666 Date: Thu, 23 Jan 2025 04:26:33 +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=3D1618 Bug ID: 1618 Summary: l2fwd testsuite match packets failing on Nvidia connectx-6 Product: DPDK Version: 25.03 Hardware: Other OS: All Status: UNCONFIRMED Severity: major Priority: Normal Component: DTS Assignee: dev@dpdk.org Reporter: probb@iol.unh.edu CC: juraj.linkes@pantheon.tech, probb@iol.unh.edu Target Milestone: --- Hi, l2fwd runs correctly on NVIDIA cx5 (as tested when this testsuite was added last year). I added a config for NVIDIA cx6 today, and the testsuite errore= d, logging that 50 out of 50 packets were missing. The testsuite follows this process:=20 1. create packets with generate_random_packets() 2. Run send_packet_and_capture(), returns received packets list 3. Run get_expected_packets(), returns expected packets list. 4. Use match_all_packets(), which converts both lists of packets to a list = of raw bytes and attempts to subtract the received packets against the expected packets, which should leave no packets remaining at the end (the pass condition). After digging a little, it looks like when running with the cx6, step #2 and step #3 from above produce the same list of 50 packets (same raw layer payload), though the L3 header values differ, which causes the packets to differ when matched against one another. For instance, here are two packets matched against each other on the cx6 test, which should match positively (= but do not):=20 received_packet: >>> expected_packet :=20 >>> I expect this comes down to usage of _adjust_addresses() in #2, vs get_expected_packets() in #3. I am wondering whether the strategy employed = in match_packets is good anyhow (its strategy is comparing raw packet bytes wi= th no deep packet comparison). And, this is the only testsuite which is compar= ing packets in this manner. I propose to switch to comparing the two packet lis= ts with the testsuite verify_packets() method. I have tested this verify method, and I will submit a patch for folks to comment on. --=20 You are receiving this mail because: You are the assignee for the bug.= --17376027930.ed1C5.2219666 Date: Thu, 23 Jan 2025 04:26:33 +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 1618
Summary l2fwd testsuite match packets failing on Nvidia connectx-6
Product DPDK
Version 25.03
Hardware Other
OS All
Status UNCONFIRMED
Severity major
Priority Normal
Component DTS
Assignee dev@dpdk.org
Reporter probb@iol.unh.edu
CC juraj.linkes@pantheon.tech, probb@iol.unh.edu
Target Milestone --- 

Hi,

l2fwd runs correctly on NVIDIA cx5 (as tested when this testsuite was added
last year). I added a config for NVIDIA cx6 today, and the testsuite errore=
d,
logging that 50 out of 50 packets were missing. The testsuite follows this
process:=20

1. create packets with generate_random_packets()
2. Run send_packet_and_capture(), returns received packets list
3. Run get_expected_packets(), returns expected packets list.
4. Use match_all_packets(), which converts both lists of packets to a list =
of
raw bytes and attempts to subtract the received packets against the expected
packets, which should leave no packets remaining at the end (the pass
condition).

After digging a little, it looks like when running with the cx6, step #2 and
step #3 from above produce the same list of 50 packets (same raw layer
payload), though the L3 header values differ, which causes the packets to
differ when matched against one another. For instance, here are two packets
matched against each other on the cx6 test, which should match positively (=
but
do not):=20

received_packet:

<Ether  dst=3D02:00:00:00:00:00 src=3Db8:3f:d2:52:b7:24 type=3DIPv4 |<=
;IP  version=3D4
ihl=3D5 tos=3D0x0 len=3D140 id=3D1 flags=3D frag=3D0 ttl=3D64 proto=3D6 chk=
sum=3D0x3014
src=3D192.168.100.3 dst=3D192.168.101.3 |<TCP  sport=3D43994 dport=3D362=
57 seq=3D0 ack=3D0
dataofs=3D5 reserved=3D0 flags=3DS window=3D8192 chksum=3D0x9baa urgptr=3D0=
 |<Raw=20
load=3Db"\xd7'C\x0c\xb5\x02H\xd6C\xf2\x1b\xec\xf4\x0c\x8e\x90*\xd2\x1b=
m\xbdhHx\xd0\xdbbz9\xeb\xb0\x1dBy-\xe4r\x0c\x8e\x0bjX\x95\x01\xc7\x8aL6A\x1=
d\xa1v-K\x93t\xbaT3i\xb7\x1b#\xee\\_nN7\xdd\xb2\xb6-1t\x8c\x1c)\x8an\x80r(\=
x19D\x84.\xc0*\xd7\xfcv\xbeB\xa6k\xb27\xc4\xb0"
|>>>>

expected_packet :=20

<Ether  dst=3Da0:88:c2:95:79:c5 src=3Db8:3f:d2:52:b7:24 type=3DIPv4 |<=
;IP  frag=3D0
proto=3D6 src=3D192.168.100.3 dst=3D192.168.101.3 |<TCP  sport=3D43994 d=
port=3D36257
|<Raw=20
load=3Db"\xd7'C\x0c\xb5\x02H\xd6C\xf2\x1b\xec\xf4\x0c\x8e\x90*\xd2\x1b=
m\xbdhHx\xd0\xdbbz9\xeb\xb0\x1dBy-\xe4r\x0c\x8e\x0bjX\x95\x01\xc7\x8aL6A\x1=
d\xa1v-K\x93t\xbaT3i\xb7\x1b#\xee\\_nN7\xdd\xb2\xb6-1t\x8c\x1c)\x8an\x80r(\=
x19D\x84.\xc0*\xd7\xfcv\xbeB\xa6k\xb27\xc4\xb0"
|>>>>


I expect this comes down to usage of _adjust_addresses() in #2, vs
get_expected_packets() in #3. I am wondering whether the strategy employed =
in
match_packets is good anyhow (its strategy is comparing raw packet bytes wi=
th
no deep packet comparison). And, this is the only testsuite which is compar=
ing
packets in this manner. I propose to switch to comparing the two packet lis=
ts
with the testsuite verify_packets() method.

I have tested this verify method, and I will submit a patch for folks to
comment on.

You are receiving this mail because:
  • You are the assignee for the bug.
=20=20=20=20=20=20=20=20=20=20
= --17376027930.ed1C5.2219666--