On Mon, Jan 08, 2024 at 10:15:40PM +0100, Morten Brørup wrote: > > From: Bruce Richardson [mailto:bruce.richard...@intel.com] > > Sent: Monday, 8 January 2024 11.54 > > > > On Tue, Dec 19, 2023 at 10:59:48PM +0530, jer...@marvell.com wrote: > > > From: Jerin Jacob <jer...@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 <jer...@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. > > > > > 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). > Ok, thanks for the info. All good with me so.
/Bruce
