> From: Bruce Richardson [mailto:[email protected]]
> Sent: Monday, 8 January 2024 11.54
>
> On Tue, Dec 19, 2023 at 10:59:48PM +0530, [email protected] wrote:
> > From: Jerin Jacob <[email protected]>
> >
> > 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 <[email protected]>
> > ---
>
> 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.
>
> 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).
