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 8FE98438ED; Thu, 18 Jan 2024 08:28:39 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 1F421402B0; Thu, 18 Jan 2024 08:28:39 +0100 (CET) Received: from inbox.dpdk.org (inbox.dpdk.org [95.142.172.178]) by mails.dpdk.org (Postfix) with ESMTP id 36ADF400D7 for ; Thu, 18 Jan 2024 08:28:38 +0100 (CET) Received: by inbox.dpdk.org (Postfix, from userid 33) id 0DBDE438EE; Thu, 18 Jan 2024 08:28:38 +0100 (CET) From: bugzilla@dpdk.org To: dev@dpdk.org Subject: [Bug 1367] net/mlx5 Tx stuck if mbuf has too many segments Date: Thu, 18 Jan 2024 07:28:37 +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: 23.11 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: andrew.rybchenko@oktetlabs.ru 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=17055629170.1CCc2.1873467 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 --17055629170.1CCc2.1873467 Date: Thu, 18 Jan 2024 08:28:37 +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=3D1367 Bug ID: 1367 Summary: net/mlx5 Tx stuck if mbuf has too many segments Product: DPDK Version: 23.11 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: Normal Component: ethdev Assignee: dev@dpdk.org Reporter: andrew.rybchenko@oktetlabs.ru Target Milestone: --- net/mlx5 Tx stuck if mbuf has too many segments net/mlx5 reports maximum number of Tx segments in device info, but it does = not check it on Tx prepare and simply do not send it on Tx burst. As the result if such packet is encountered, app does not know (without ext= ra efforts) why it fails to send the packet after successful Tx prepare. In th= eory the reason could be fully occupied Tx queue and application should simply r= etry forever. Found by test run at UNH IOL: 1. Test checks reported maximum segments count: tx_desc_lim.nb_mtu_seg_max= =3D40 https://ts-factory.io/bublik/v2/log/477842?focusId=3D479564&mode=3DtreeAndi= nfoAndlog&experimental=3Dtrue&lineNumber=3D1_25 2. Test splits the packet into 60 segments: https://ts-factory.io/bublik/v2/log/477842?focusId=3D479564&mode=3DtreeAndi= nfoAndlog&experimental=3Dtrue&lineNumber=3D1_49 3. Test logs expectations for the packet to be rejected by Tx prepare: https://ts-factory.io/bublik/v2/log/477842?focusId=3D479564&mode=3DtreeAndi= nfoAndlog&experimental=3Dtrue&lineNumber=3D1_60 4. Tx prepare accepts the packet and the test logs error: https://ts-factory.io/bublik/v2/log/477842?focusId=3D479564&mode=3DtreeAndi= nfoAndlog&experimental=3Dtrue&lineNumber=3D1_62 5. Test tries to Tx burst the packet, but it returns 0. One more error is logged. https://ts-factory.io/bublik/v2/log/477842?focusId=3D479564&mode=3DtreeAndi= nfoAndlog&experimental=3Dtrue&lineNumber=3D1_62 IMHO better behaviour here would be to accept the packet bug simply drop it= in SW on Tx before passing to HW. Just avoid Tx stuck. Of course Tx prepare should reject the packet at step 4. --=20 You are receiving this mail because: You are the assignee for the bug.= --17055629170.1CCc2.1873467 Date: Thu, 18 Jan 2024 08:28:37 +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 1367
Summary net/mlx5 Tx stuck if mbuf has too many segments
Product DPDK
Version 23.11
Hardware All
OS All
Status UNCONFIRMED
Severity normal
Priority Normal
Component ethdev
Assignee dev@dpdk.org
Reporter andrew.rybchenko@oktetlabs.ru
Target Milestone --- 

net/mlx5 Tx stuck if mbuf has too =
many segments

net/mlx5 reports maximum number of Tx segments in device info, but it does =
not
check it on Tx prepare and simply do not send it on Tx burst.

As the result if such packet is encountered, app does not know (without ext=
ra
efforts) why it fails to send the packet after successful Tx prepare. In th=
eory
the reason could be fully occupied Tx queue and application should simply r=
etry
forever.

Found by test run at UNH IOL:

1. Test checks reported maximum segments count: tx_desc_lim.nb_mtu_seg_max=
=3D40
htt=
ps://ts-factory.io/bublik/v2/log/477842?focusId=3D479564&mode=3DtreeAnd=
infoAndlog&experimental=3Dtrue&lineNumber=3D1_25

2. Test splits the packet into 60 segments:
htt=
ps://ts-factory.io/bublik/v2/log/477842?focusId=3D479564&mode=3DtreeAnd=
infoAndlog&experimental=3Dtrue&lineNumber=3D1_49

3. Test logs expectations for the packet to be rejected by Tx prepare:
htt=
ps://ts-factory.io/bublik/v2/log/477842?focusId=3D479564&mode=3DtreeAnd=
infoAndlog&experimental=3Dtrue&lineNumber=3D1_60

4. Tx prepare accepts the packet and the test logs error:
htt=
ps://ts-factory.io/bublik/v2/log/477842?focusId=3D479564&mode=3DtreeAnd=
infoAndlog&experimental=3Dtrue&lineNumber=3D1_62

5. Test tries to Tx burst the packet, but it returns 0. One more error is
logged.
htt=
ps://ts-factory.io/bublik/v2/log/477842?focusId=3D479564&mode=3DtreeAnd=
infoAndlog&experimental=3Dtrue&lineNumber=3D1_62

IMHO better behaviour here would be to accept the packet bug simply drop it=
 in
SW on Tx before passing to HW. Just avoid Tx stuck.

Of course Tx prepare should reject the packet at step 4.

You are receiving this mail because:
  • You are the assignee for the bug.
=20=20=20=20=20=20=20=20=20=20
= --17055629170.1CCc2.1873467--