[dpdk-dev] [RFC] ethdev: support Tx queue free descriptor query

[Ferruh Yigit]

On 1/8/2024 9:15 PM, Morten Brørup wrote:
>> From: Bruce Richardson [mailto:bruce.richardson at intel.com]
>> Sent: Monday, 8 January 2024 11.54
>>
>> On Tue, Dec 19, 2023 at 10:59:48PM +0530, jerinj at marvell.com wrote:
>>> From: Jerin Jacob <jerinj at marvell.com>
>>>
>>> Introduce a new API to retrieve the number of available free
>> descriptors
>>> in a Tx queue. Applications can leverage this API in the fast path to
>>> inspect the Tx queue occupancy and take appropriate actions based on
>> the
>>> available free descriptors.
>>>
>>> A notable use case could be implementing Random Early Discard (RED)
>>> in software based on Tx queue occupancy.
>>>
>>> Signed-off-by: Jerin Jacob <jerinj at marvell.com>
>>> ---
>>
>> Hi Jerin,
>>
>> while I don't strongly object to this patch, I wonder if it encourages
>> sub-optimal code implementations. To determine the number of free
>> descriptors in a ring, the driver in many cases will need to do a scan
>> of
>> the descriptor ring to see how many are free/used. However, I suspect
>> that
>> in most cases we will see something like the following being done:
>>
>>     count = rte_eth_rx_free_count();
> 
> Typo: rte_eth_rx_free_count() -> rte_eth_tx_free_count()
> 
>>     if (count > X) {
>>         /* Do something */
>>     }
>>
>> For instances like this, scanning the entire ring is wasteful of
>> resources.
>> Instead it would be better to just check the descriptor at position X
>> explicitly. Going to the trouble of checking the exact descriptor count
>> is
>> unnecessary in this case.
> 
> Yes, it introduces such a risk.
> All DPDK examples simply call tx_burst() without checking free space first, so I think the probability (of the simple case) is low.
> And the probability for the case comparing to X could be mitigated by referring to rte_eth_tx_descriptor_status() in the function description.
> 

Agree on the risk,
perhaps adding some documentation to the API helps, we can highlight
intended usecase is QoS implementations, like RED etc..

>>
>> Out of interest, are you aware of a case where an app would need to
>> know
>> exactly the number of free descriptors, and where the result would not
>> be
>> just compared to one or more threshold values? Do we see cases where it
>> would be used in a computation, perhaps?
> 
> Yes: RED. When exceeding the minimum threshold, the probability of marking/dropping a packet increases linearly with the queue's fill level.
> E.g.:
> 0-900 packets in queue: don't drop,
> 901-1000 packets in queue: probability of dropping the packet is 1-100 % (e.g. 980 packets in queue = 80 % drop probability).
> 
>