Re: [dpdk-dev] [PATCH v4] mlx5: Support for rte_eth_rx_queue_count

[Shahaf Shuler <shahafs@mellanox.com>]

Tom,

Monday, November 5, 2018 11:56 AM, Olivier Matz:
> Subject: Re: [dpdk-dev] [PATCH v4] mlx5: Support for
> rte_eth_rx_queue_count
> 
> Hi Tom,
> 
> On Mon, Nov 05, 2018 at 09:01:03AM +0000, Tom Barbette wrote:
> >
> > > It will tell you if in a given offset on the rxq you have a packet ready. I
> think it will fit your needs, see below.
> > So we just loose in precision here. We're looking at ML techniques that will
> play better with a numerical value and benefit from more entropy than
> arbitrarily poking of some thresholds.
> > If one had to remain, I'd say rx_descriptor_* should be removed as it can
> be deduced from queue_count. Moreover, in the MLX5 case, calling the
> function 3 times to get "half busy", "partially busy" or "idle" will lead to
> scanning the queue 3 times...
> 
> The rationale of the descriptor_status() API was to avoid to scan the hw ring
> in a linear way, like it was done in *_queue_count() functions (on Intel NICs).
> This costs a lot, especially for large rings. The alternative was to do a pci
> access to read the hw head/tail, but benchmarks showed that it was also
> expensive.
> 
> With descriptor_status API, it is fast if you only need a threshold info.
> If you need a more precise count, it is possible to do a binary search
> algorithm, which is faster than the linear traversal.
> 
> That said, these assumptions may not be true for all NICs types, since there
> are different ways of implementing the queue.

I will apply this patch, since this API exists and you find the new one not fit. 
We will follow up on this when we reach the point we deprecate the old one.

Applied to next-net-mlx, thanks. 


> 
> Regards,
> Olivier