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

[Morten Brørup]

> From: Konstantin Ananyev [mailto:konstantin.ananyev at huawei.com]
> Sent: Friday, 19 January 2024 10.53
> 
> > > > > > 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>
> > > >
> > > > 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.

If used for simple mitigation of tail-dropping, you are correct. Then the percentages would be appropriate.

But not if used for traffic engineering. In that case, the queueing algorithm's thresholds should be based on absolute numbers, configured by the network engineer.
As an optional application optimization, if an application has RED queueing configured for 100 % dropping at 200 packets in queue, the application can configure the NIC with only 256 descriptors instead of 512 or whatever the default is. In this way, the NIC queue size depends on the RED parameters, not vice versa.

> 
> > - 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?

Not if optimizing for low latency. If one of the NICs supports 512 TX descriptors and another of the NICs supports 4096 TX descriptors, the application should transmit packets via the NIC with the lowest absolute number of used descriptors, assuming that this queue has the shortest queuing delay.

> 
> > - 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 ;)

Then everyone are happy; we can enjoy the coming weekend, and leave the remaining work on this to Jerin. :-))

Great discussion, Konstantin! It is important to remain focused on what the users need, and keep challenging if that is really what we are doing.