Skip to contentSkip to conversation

net/mlx5 Tx stuck if mbuf has too many segments

Bug 1367 [email protected] 1 participant 2 messages Jan 18, 2024 – Oct 27, 2025

lore
Share & tools
lore
#0 lore raw

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

            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: [email protected]
          Reporter: [email protected]

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 extra efforts) why it fails to send the packet after successful Tx prepare. In theory the reason could be fully occupied Tx queue and application should simply retry forever.

Found by test run at UNH IOL:

1. Test checks reported maximum segments count: tx_desc_lim.nb_mtu_seg_max=40
https://ts-factory.io/bublik/v2/log/477842?focusId=479564&mode=treeAndinfoAndlog&experimental=true&lineNumber=1_25

2. Test splits the packet into 60 segments:
https://ts-factory.io/bublik/v2/log/477842?focusId=479564&mode=treeAndinfoAndlog&experimental=true&lineNumber=1_49

3. Test logs expectations for the packet to be rejected by Tx prepare:
https://ts-factory.io/bublik/v2/log/477842?focusId=479564&mode=treeAndinfoAndlog&experimental=true&lineNumber=1_60

4. Tx prepare accepts the packet and the test logs error:
https://ts-factory.io/bublik/v2/log/477842?focusId=479564&mode=treeAndinfoAndlog&experimental=true&lineNumber=1_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=479564&mode=treeAndinfoAndlog&experimental=true&lineNumber=1_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.

Signature · 2 lines
You are receiving this mail because:
You are the assignee for the bug.
#1 lore raw

http://bugs.dpdk.org/show_bug.cgi?id=1367

[email protected] ([email protected]) changed:

What |Removed |Added
----------------------------------------------------------------------------

             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |FIXED
                 CC|                            |[email protected]

--- Comment #6 from [email protected] ([email protected]) --- Closing as the discussion ended.

Signature · 2 lines
You are receiving this mail because:
You are the assignee for the bug.