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 EF351A04C9; Mon, 14 Sep 2020 13:27:06 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id D07261BE95; Mon, 14 Sep 2020 13:27:06 +0200 (CEST) Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) by dpdk.org (Postfix) with ESMTP id 9A391160 for ; Mon, 14 Sep 2020 13:27:05 +0200 (CEST) IronPort-SDR: H5JAaH2CiEMaLy4rAmR6+jQee0/ZRyL0sD/3l44jmfZ9EDraQu7Np6sQjN/k2FHPTZbLJgn/KH U3+8djSKprNQ== X-IronPort-AV: E=McAfee;i="6000,8403,9743"; a="243891101" X-IronPort-AV: E=Sophos;i="5.76,425,1592895600"; d="scan'208";a="243891101" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga004.jf.intel.com ([10.7.209.38]) by fmsmga105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 14 Sep 2020 04:27:04 -0700 IronPort-SDR: lJPmV9AXlgZqg6Qwy98mqkkc0G/s6hIyaeJa0aYTW7uVpFsUrLlJy8tDoDAhKu8wp3bterTzoT QRhH0+SD44Qg== X-IronPort-AV: E=Sophos;i="5.76,425,1592895600"; d="scan'208";a="450838953" Received: from bricha3-mobl.ger.corp.intel.com ([10.251.82.81]) by orsmga004-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-SHA; 14 Sep 2020 04:27:03 -0700 Date: Mon, 14 Sep 2020 12:26:59 +0100 From: Bruce Richardson To: Morten =?iso-8859-1?Q?Br=F8rup?= Cc: thomas@monjalon.net, ferruh.yigit@intel.com, arybchenko@solarflare.com, jia.guo@intel.com, dev@dpdk.org Message-ID: <20200914112659.GA745@bricha3-MOBL.ger.corp.intel.com> References: <20200914110511.95609-1-mb@smartsharesystems.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20200914110511.95609-1-mb@smartsharesystems.com> Subject: Re: [dpdk-dev] [PATCH] ethdev: rte_eth_rx_burst() nb_pkts requirements 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 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@smartserver.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." > * 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 >