<html>
<head>
<base href="https://bugs.dpdk.org/">
</head>
<body><table border="1" cellspacing="0" cellpadding="8" class="bz_new_table">
<tr>
<th>Bug ID</th>
<td><a class="bz_bug_link
bz_status_UNCONFIRMED "
title="UNCONFIRMED - net/mlx5 Tx stuck if mbuf has too many segments"
href="https://bugs.dpdk.org/show_bug.cgi?id=1367">1367</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>net/mlx5 Tx stuck if mbuf has too many segments
</td>
</tr>
<tr>
<th>Product</th>
<td>DPDK
</td>
</tr>
<tr>
<th>Version</th>
<td>23.11
</td>
</tr>
<tr>
<th>Hardware</th>
<td>All
</td>
</tr>
<tr>
<th>OS</th>
<td>All
</td>
</tr>
<tr>
<th>Status</th>
<td>UNCONFIRMED
</td>
</tr>
<tr>
<th>Severity</th>
<td>normal
</td>
</tr>
<tr>
<th>Priority</th>
<td>Normal
</td>
</tr>
<tr>
<th>Component</th>
<td>ethdev
</td>
</tr>
<tr>
<th>Assignee</th>
<td>dev@dpdk.org
</td>
</tr>
<tr>
<th>Reporter</th>
<td>andrew.rybchenko@oktetlabs.ru
</td>
</tr>
<tr>
<th>Target Milestone</th>
<td>---
</td>
</tr></table>
<p>
<div class="bz_comment_block">
<pre class="bz_comment_text">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
<a href="https://ts-factory.io/bublik/v2/log/477842?focusId=479564&mode=treeAndinfoAndlog&experimental=true&lineNumber=1_25">https://ts-factory.io/bublik/v2/log/477842?focusId=479564&mode=treeAndinfoAndlog&experimental=true&lineNumber=1_25</a>
2. Test splits the packet into 60 segments:
<a href="https://ts-factory.io/bublik/v2/log/477842?focusId=479564&mode=treeAndinfoAndlog&experimental=true&lineNumber=1_49">https://ts-factory.io/bublik/v2/log/477842?focusId=479564&mode=treeAndinfoAndlog&experimental=true&lineNumber=1_49</a>
3. Test logs expectations for the packet to be rejected by Tx prepare:
<a href="https://ts-factory.io/bublik/v2/log/477842?focusId=479564&mode=treeAndinfoAndlog&experimental=true&lineNumber=1_60">https://ts-factory.io/bublik/v2/log/477842?focusId=479564&mode=treeAndinfoAndlog&experimental=true&lineNumber=1_60</a>
4. Tx prepare accepts the packet and the test logs error:
<a href="https://ts-factory.io/bublik/v2/log/477842?focusId=479564&mode=treeAndinfoAndlog&experimental=true&lineNumber=1_62">https://ts-factory.io/bublik/v2/log/477842?focusId=479564&mode=treeAndinfoAndlog&experimental=true&lineNumber=1_62</a>
5. Test tries to Tx burst the packet, but it returns 0. One more error is
logged.
<a href="https://ts-factory.io/bublik/v2/log/477842?focusId=479564&mode=treeAndinfoAndlog&experimental=true&lineNumber=1_62">https://ts-factory.io/bublik/v2/log/477842?focusId=479564&mode=treeAndinfoAndlog&experimental=true&lineNumber=1_62</a>
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.
</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are the assignee for the bug.</li>
</ul>
<div itemscope itemtype="http://schema.org/EmailMessage">
<div itemprop="action" itemscope itemtype="http://schema.org/ViewAction">
<link itemprop="url" href="https://bugs.dpdk.org/show_bug.cgi?id=1367">
<meta itemprop="name" content="View bug">
</div>
<meta itemprop="description" content="Bugzilla bug update notification">
</div>
</body>
</html>