[DPDK/DTS Bug 1618] l2fwd testsuite match packets failing on Nvidia connectx-6

[bugzilla@dpdk.org]

[-- Attachment #1: Type: text/plain, Size: 3281 bytes --]

https://bugs.dpdk.org/show_bug.cgi?id=1618

            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 errored,
logging that 50 out of 50 packets were missing. The testsuite follows this
process: 

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): 

received_packet:

<Ether  dst=02:00:00:00:00:00 src=b8:3f:d2:52:b7:24 type=IPv4 |<IP  version=4
ihl=5 tos=0x0 len=140 id=1 flags= frag=0 ttl=64 proto=6 chksum=0x3014
src=192.168.100.3 dst=192.168.101.3 |<TCP  sport=43994 dport=36257 seq=0 ack=0
dataofs=5 reserved=0 flags=S window=8192 chksum=0x9baa urgptr=0 |<Raw 
load=b"\xd7'C\x0c\xb5\x02H\xd6C\xf2\x1b\xec\xf4\x0c\x8e\x90*\xd2\x1bm\xbdhHx\xd0\xdbbz9\xeb\xb0\x1dBy-\xe4r\x0c\x8e\x0bjX\x95\x01\xc7\x8aL6A\x1d\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 : 

<Ether  dst=a0:88:c2:95:79:c5 src=b8:3f:d2:52:b7:24 type=IPv4 |<IP  frag=0
proto=6 src=192.168.100.3 dst=192.168.101.3 |<TCP  sport=43994 dport=36257
|<Raw 
load=b"\xd7'C\x0c\xb5\x02H\xd6C\xf2\x1b\xec\xf4\x0c\x8e\x90*\xd2\x1bm\xbdhHx\xd0\xdbbz9\xeb\xb0\x1dBy-\xe4r\x0c\x8e\x0bjX\x95\x01\xc7\x8aL6A\x1d\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 with
no deep packet comparison). And, this is the only testsuite which is comparing
packets in this manner. I propose to switch to comparing the two packet lists
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.

[-- Attachment #2: Type: text/html, Size: 5287 bytes --]