From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 476BAA04B7; Tue, 13 Oct 2020 12:56:05 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id CB6341DA82; Tue, 13 Oct 2020 12:56:02 +0200 (CEST) Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by dpdk.org (Postfix) with ESMTP id 0F0DF1DA7C for ; Tue, 13 Oct 2020 12:55:59 +0200 (CEST) IronPort-SDR: 6RBUlpAanusf2yXXZcVRLqKfRHSBA7VsrJi+3C8T0JMe4ESCXqmJktL3UfVK2o6b9ixfqTQvyw 7HsimZ+YaPbw== X-IronPort-AV: E=McAfee;i="6000,8403,9772"; a="162425386" X-IronPort-AV: E=Sophos;i="5.77,370,1596524400"; d="scan'208";a="162425386" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga005.jf.intel.com ([10.7.209.41]) by fmsmga102.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 Oct 2020 03:55:56 -0700 IronPort-SDR: hM/vIGMem6ml+GUD7TKSjN139gfG61c5GbDd/yutMsXFPTDxTyY5+xma13Uprsd5v5eHhnSFb0 Z6WN+99tS5cA== X-IronPort-AV: E=Sophos;i="5.77,370,1596524400"; d="scan'208";a="530348103" Received: from fyigit-mobl1.ger.corp.intel.com (HELO [10.213.214.64]) ([10.213.214.64]) by orsmga005-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 Oct 2020 03:55:54 -0700 To: =?UTF-8?Q?Morten_Br=c3=b8rup?= , Bruce Richardson Cc: thomas@monjalon.net, arybchenko@solarflare.com, jia.guo@intel.com, dev@dpdk.org References: <20200914110511.95609-1-mb@smartsharesystems.com> <20200914112659.GA745@bricha3-MOBL.ger.corp.intel.com> <98CBD80474FA8B44BF855DF32C47DC35C612DF@smartserver.smartshare.dk> From: Ferruh Yigit Message-ID: <60d87dbf-167e-d0a6-781a-5f54ee5cb5ac@intel.com> Date: Tue, 13 Oct 2020 11:55:51 +0100 MIME-Version: 1.0 In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35C612DF@smartserver.smartshare.dk> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Subject: Re: [dpdk-dev] [PATCH] ethdev: rte_eth_rx_burst() nb_pktsrequirements 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: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On 9/14/2020 1:42 PM, Morten Brørup wrote: >> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Bruce Richardson >> Sent: Monday, September 14, 2020 1:27 PM >> >> On Mon, Sep 14, 2020 at 01:05:11PM +0200, Morten Brørup wrote: >>> Updated description of rte_eth_rx_burst() to reflect what drivers, >>> when using vector instructions, expect from nb_pkts. >>> >>> Also discussed on the mailing list here: >>> >> http://inbox.dpdk.org/dev/98CBD80474FA8B44BF855DF32C47DC35C61257@smarts >> erver.smartshare.dk/ >>> >>> Signed-off-by: Morten Brørup >>> --- >>> lib/librte_ethdev/rte_ethdev.h | 5 +++++ >>> 1 file changed, 5 insertions(+) >>> >>> diff --git a/lib/librte_ethdev/rte_ethdev.h >> b/lib/librte_ethdev/rte_ethdev.h >>> index 70295d7ab..41f8ba4ef 100644 >>> --- a/lib/librte_ethdev/rte_ethdev.h >>> +++ b/lib/librte_ethdev/rte_ethdev.h >>> @@ -4469,6 +4469,10 @@ int >> rte_eth_dev_hairpin_capability_get(uint16_t port_id, >>> * burst-oriented optimizations in both synchronous and asynchronous >>> * packet processing environments with no overhead in both cases. >>> * >>> + * @note >>> + * Some drivers using vector instructions require that *nb_pkts* >> is >>> + * divisible by 4 or 8, depending on the driver implementation. >>> + * >> >> Not technically true, in that the drivers will round the value down to >> the >> nearest multiple of 4 or 8. So how about rewording as: >> >> "Some drivers using vector instructions may round the *nb_pkts* driver >> to >> a multiple of 4 or 8 depending upon the driver implementation." >> > > You are correct about the driver behavior. > > However, if you pass nb_pkts=9, the driver will return 8 packets, > and thus it does not conform to the API behavior of returning nb_pkts > if they are there. > > This is why the description in this patch differs from the description we reached in the RFC discussion. > Hi Morten, Bruce, +1 to document the this behavior. But in the patch the wording is more strict: "... require that *nb_pkts* is divisible by 4 or 8 ..." "... The value must be divisible by 8 in order to work with any driver." I am not sure the requirement is that strict. Application still provide any value for 'nb_pkts', so the value doesn't "have to" be divisible 8/4. But for vector PMD case it will return number of packets round down to 8/4. Perhaps can add for vector PMD it must be at least 4/8? Bruce's explanation sound more accurate to me, what do you think? >>> * The rte_eth_rx_burst() function does not provide any error >>> * notification to avoid the corresponding overhead. As a hint, the >>> * upper-level application might check the status of the device link >> once >>> @@ -4485,6 +4489,7 @@ int rte_eth_dev_hairpin_capability_get(uint16_t >> port_id, >>> * must be large enough to store *nb_pkts* pointers in it. >>> * @param nb_pkts >>> * The maximum number of packets to retrieve. >>> + * The value must be divisible by 8 in order to work with any >> driver. >> >> Similarly here, I think it's better to state that it should be at least >> 8, >> and any values not divisible by 8 may be rounded down. >> >>> * @return >>> * The number of packets actually retrieved, which is the number >>> * of pointers to *rte_mbuf* structures effectively supplied to >> the >>> -- >>> 2.17.1 >>> >