> From: Konstantin Ananyev [mailto:konstantin.anan...@huawei.com] > Sent: Thursday, 18 January 2024 11.17 > > Hi Jerin, > > > > > Introduce a new API to retrieve the number of used 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> > > > > > > @@ -6803,6 +6803,80 @@ rte_eth_recycle_mbufs(uint16_t rx_port_id, > uint16_t rx_queue_id, > > > > __rte_experimental > > > > int rte_eth_buffer_split_get_supported_hdr_ptypes(uint16_t > port_id, uint32_t *ptypes, int num); > > > > > > > > +/** > > > > + * @warning > > > > + * @b EXPERIMENTAL: this API may change, or be removed, without > prior notice > > > > + * > > > > + * Get the number of used descriptors of a Tx queue > > > > + * > > > > + * This function retrieves the number of used descriptors of a > transmit queue. > > > > + * Applications can use this API in the fast path to inspect Tx > queue occupancy and take > > > > + * appropriate actions based on the available free descriptors. > > > > + * An example action could be implementing the Random Early > Discard (RED). > > > > > > Sorry, I probably misunderstood your previous mails, but wouldn't > it be more convenient > > > for user to have rte_eth_tx_queue_free_count(...) as fast-op, and > > > have rte_eth_tx_queue_count(...) { queue_txd_num - > rte_eth_tx_queue_free_count(...);} > > > as a slow-path function in rte_ethdev.c? > > > > The general feedback is to align with the Rx queue API, specifically > > rte_eth_rx_queue_count, > > and it's noted that there is no equivalent > rte_eth_rx_queue_free_count. > > > > Given that the free count can be obtained by subtracting the used > > count from queue_txd_num, > > it is considered that either approach is acceptable. > > > > The application configures queue_txd_num with tx_queue_setup(), and > > the application can store that value in its structure. > > This would enable fast-path usage for both base cases (whether the > > application needs information about free or used descriptors) > > with just one API(rte_eth_tx_queue_count()) > > Right now I don't use these functions, but if I think what most people > are interested in: > - how many packets you can receive immediately (rx_queue_count)
Agreed that "used" (not "free") is the preferred info for RX. > - how many packets you can transmit immediately (tx_queue_free_count) > Sure, I understand that user can store txd_num somewhere and then do > subtraction himself. > Though it means more effort for the user, and the only reason for that, > as I can see, > is to have RX and TX function naming symmetric. > Which seems much less improtant to me comparing to user convenience. I agree 100 % with your prioritization: Usability has higher priority than symmetric naming. So here are some example use cases supporting the TX "Used" API: - RED (and similar queueing algorithms) need to know how many packets the queue holds (not how much room the queue has for more packets). - Load Balancing across multiple links, in use cases where packet reordering is allowed. - Monitoring egress queueing, especially in many-to-one-port traffic patterns, e.g. to catch micro-burst induced spikes (which may cause latency/"bufferbloat"). - The (obsolete) ifOutQLen object in the Interfaces MIB for SNMP, which I suppose was intended for monitoring egress queueing. > Anyway, as I stated above, I don't use these functions right now, > so if the majority of users are happy with current approach, I would > not insist :) I'm very happy with the current approach. :-)
