From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.droids-corp.org (zoll.droids-corp.org [94.23.50.67]) by dpdk.org (Postfix) with ESMTP id AF1085942 for ; Mon, 5 Nov 2018 10:55:42 +0100 (CET) Received: from rsa59-2-82-233-193-189.fbx.proxad.net ([82.233.193.189] helo=droids-corp.org) by mail.droids-corp.org with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gJbcx-0003mw-BF; Mon, 05 Nov 2018 10:57:00 +0100 Received: by droids-corp.org (sSMTP sendmail emulation); Mon, 05 Nov 2018 10:55:33 +0100 Date: Mon, 5 Nov 2018 10:55:33 +0100 From: Olivier Matz To: Tom Barbette Cc: Shahaf Shuler , "dev@dpdk.org" , Ferruh Yigit , Thomas Monjalon , Andrew Rybchenko , Yongseok Koh Message-ID: <20181105095533.yupcifz45metjkgf@platinum> References: <1540653055-67051-1-git-send-email-barbette@kth.se> <1540976475938.69727@kth.se> <1541408462940.66979@kth.se> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1541408462940.66979@kth.se> User-Agent: NeoMutt/20170113 (1.7.2) Subject: Re: [dpdk-dev] [PATCH v4] mlx5: Support for rte_eth_rx_queue_count X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2018 09:55:42 -0000 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. Regards, Olivier