[dpdk-dev] [RFC 0/9] get Rx and Tx used descriptors

[Richardson, Bruce]

> -----Original Message-----
> From: Olivier Matz [mailto:olivier.matz at 6wind.com]
> Sent: Friday, January 13, 2017 4:44 PM
> To: dev at dpdk.org
> Cc: thomas.monjalon at 6wind.com; Ananyev, Konstantin
> <konstantin.ananyev at intel.com>; Lu, Wenzhuo <wenzhuo.lu at intel.com>; Zhang,
> Helin <helin.zhang at intel.com>; Richardson, Bruce
> <bruce.richardson at intel.com>
> Subject: Re: [dpdk-dev] [RFC 0/9] get Rx and Tx used descriptors
> 
> Hi,
> 
> On Thu, 24 Nov 2016 10:54:12 +0100, Olivier Matz <olivier.matz at 6wind.com>
> wrote:
> > This RFC patchset introduces a new ethdev API function
> > rte_eth_tx_queue_count() which is the tx counterpart of
> > rte_eth_rx_queue_count(). It implements this API on some Intel drivers
> > for reference, and it also optimizes the implementation of
> > rte_eth_rx_queue_count().
> >
> 
> I'm planning to send a new version of this patchset, fixing the issues
> seen by Ferruh, plus a bug fix in the e1000 implementation.
> 
> Does anyone have any comment about the new API or about questions raised
> in the cover letter? Especially about the real meaning of "used
> descriptor": should it include the descriptors hold by the driver?
For TX, I think we just need used/unused, since for TX any driver will reuse
a slot that has been completed by the NIC, and doesn't hold the mbufs back
for buffering at all.
For RX, strictly speaking, we should have three categories, rather than
trying to work it into 2. I don't see why we can't report a slot as
used/unused/unavailable.

> 
> Any comment about the method (binary search to find the used descriptors)?

I think binary search should work ok, though linear search may work better for
smaller ranges as we can prefetch ahead since we know what we will check next.
Linear can also go backward only if we want accuracy (going forward risks having
race conditions between read and NIC write). Overall, though I think binary
search should work well enough.

> 
> I'm also wondering about adding rte_eth_tx_descriptor_done() in the API at
> the same time.
> 

Let me switch the question around - do we need the queue_count APIs at
all, and is it not more efficient to just supply the descriptor_done() APIs?
If an app wants to know the use of the ring, and take some action based on it,
that app is going to have one or more thresholds for taking the action, right?
In that case, rather than scanning descriptors to find the absolute number
of free/used descriptors, it would be more efficient for the app to just check
the descriptor on the threshold - and take action based just on that value.
Any app that really does need the absolute value of the ring capacity can
presumably do its own binary search or linear search to determine the value
itself. However, I think just doing a done function should encourage people
to use the more efficient solution of just checking the minimum number of
descriptors needed.

Regards,
/Bruce