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 0A9DB439C0; Thu, 25 Jan 2024 11:44:22 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id ED1C6402AB; Thu, 25 Jan 2024 11:44:19 +0100 (CET) Received: from inbox.dpdk.org (inbox.dpdk.org [95.142.172.178]) by mails.dpdk.org (Postfix) with ESMTP id 375B94029B for ; Thu, 25 Jan 2024 11:44:19 +0100 (CET) Received: by inbox.dpdk.org (Postfix, from userid 33) id 1359B439C1; Thu, 25 Jan 2024 11:44:19 +0100 (CET) From: bugzilla@dpdk.org To: dev@dpdk.org Subject: [DPDK Bug 1369] net/mlx5: RX packet metadata altered/incorrect after reception Date: Thu, 25 Jan 2024 10:44:17 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: DPDK X-Bugzilla-Component: ethdev X-Bugzilla-Version: 22.11 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: pt4hwmy@clavister.com 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 Message-ID: Content-Type: multipart/alternative; boundary=17061794580.D08658.1307218 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 --17061794580.D08658.1307218 Date: Thu, 25 Jan 2024 11:44:18 +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=3D1369 Bug ID: 1369 Summary: net/mlx5: RX packet metadata altered/incorrect after reception Product: DPDK Version: 22.11 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: Normal Component: ethdev Assignee: dev@dpdk.org Reporter: pt4hwmy@clavister.com Target Milestone: --- Our platform operates with Mellanox ConnectX-5 (MT_0000000183) network adapters, equipped with the latest firmware (version 16.35.3006). It utiliz= es DPDK 22.11.3 and runs on Ubuntu 20. Under heavy load, we occasionally observe the reception of packets where the metadata is incorrect or altered at a later time. The incorrect data seem to revolve around the "port" and "RSS" fields. For packet reception, we use:=20 rte_eth_rx_burst(port ..) To detect the problem, we loop through the packets that have been received = and check if the "port" specified in the "mbuf" aligns with the interface designated for the RX burst execution. Occasionally, they will not match. Sometimes, the port appears to match initially, only to change later during processing. Attempts to modify the packet metadata after reception, such as changing the port, result in its reverting to its previous state shortly after.=20 The packet data for these anomalies seems accurate. For instance, if RX is performed on port 1 and the packet mbuf indicates port 2, the IP data within the packet still correlates with the IP ranges assigned to port 1. Initially, we suspected a potential double free of packet buffers but found= no evidence supporting this. Also, our implementation functions correctly with various other network adapters and drivers. This implementation also worked with an older version of DPDK. We previously used DPDK 20.02 without issue, but the problem emerged after upgrading to D= PDK 22.11. Upgrading further to DPDK 23.11 did not resolve the issue. We have tried different Mellanox firmware versions and even switched to ConnectX-6 adapters, but the problem persisted.=20 The only effective workaround so far has been to disable "hardware RX vecto= r" (rx_vec_en=3D0), which seem to make the problem go away. Do you have any insights into what might be causing this problem, or suggestions on how to proceed in resolving it? --=20 You are receiving this mail because: You are the assignee for the bug.= --17061794580.D08658.1307218 Date: Thu, 25 Jan 2024 11:44:18 +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 1369
Summary net/mlx5: RX packet metadata altered/incorrect after reception
Product DPDK
Version 22.11
Hardware x86
OS Linux
Status UNCONFIRMED
Severity normal
Priority Normal
Component ethdev
Assignee dev@dpdk.org
Reporter pt4hwmy@clavister.com
Target Milestone --- 

Our platform operates with Mellano=
x ConnectX-5 (MT_0000000183) network
adapters, equipped with the latest firmware (version 16.35.3006). It utiliz=
es
DPDK 22.11.3 and runs on Ubuntu 20.

Under heavy load, we occasionally observe the reception of packets where the
metadata is incorrect or altered at a later time. The incorrect data seem to
revolve around the "port" and "RSS" fields.

For packet reception, we use:=20
rte_eth_rx_burst(port ..)

To detect the problem, we loop through the packets that have been received =
and
check if the "port" specified in the "mbuf" aligns with=
 the interface
designated for the RX burst execution.

Occasionally, they will not match. Sometimes, the port appears to match
initially, only to change later during processing.

Attempts to modify the packet metadata after reception, such as changing the
port, result in its reverting to its previous state shortly after.=20

The packet data for these anomalies seems accurate. For instance, if RX is
performed on port 1 and the packet mbuf indicates port 2, the IP data within
the packet still correlates with the IP ranges assigned to port 1.

Initially, we suspected a potential double free of packet buffers but found=
 no
evidence supporting this. Also, our implementation functions correctly with
various other network adapters and drivers.

This implementation also worked with an older version of DPDK. We previously
used DPDK 20.02 without issue, but the problem emerged after upgrading to D=
PDK
22.11. Upgrading further to DPDK 23.11 did not resolve the issue.

We have tried different Mellanox firmware versions and even switched to
ConnectX-6 adapters, but the problem persisted.=20

The only effective workaround so far has been to disable "hardware RX =
vector"
(rx_vec_en=3D0), which seem to make the problem go away.

Do you have any insights into what might be causing this problem, or
suggestions on how to proceed in resolving it?

You are receiving this mail because:
  • You are the assignee for the bug.
=20=20=20=20=20=20=20=20=20=20
= --17061794580.D08658.1307218--