[dpdk-dev] [v1] ethdev: support Tx queue used count

[Konstantin Ananyev]

> > > > > 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 <jerinj at 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).

Ok, but to calculate percentage we do need both numbers: txd_num and txd_used_num (or txd_free_num).
So in such case user still has to store txd_num somewhere and do the math after getting txd_used_num.
So probably  no advantage between tx_queue_used_count() and tx_queue_free_count() for that case.
 
> - Load Balancing across multiple links, in use cases where packet reordering is allowed.

I suppose for that case, you also will need to calc percentage, not the raw txd_used_num, no?
 
> - 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. :-)

As I said, if end users are happy, then I am fine too ;)