On 1/8/2024 9:15 PM, 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. >
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). > >
