From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <dev-bounces@dpdk.org> Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 54061A04B7; Wed, 14 Oct 2020 10:53:34 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 3C9781D56F; Wed, 14 Oct 2020 10:53:33 +0200 (CEST) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) by dpdk.org (Postfix) with ESMTP id 066D31D54B for <dev@dpdk.org>; Wed, 14 Oct 2020 10:53:30 +0200 (CEST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.west.internal (Postfix) with ESMTP id 76D47D40; Wed, 14 Oct 2020 04:53:27 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Wed, 14 Oct 2020 04:53:27 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:content-type; s=fm2; bh= RpCt7TarUT+5VepmdYRzPkHUagkgIUTD1RO+azeExFA=; b=tPPpqAebjD280wqN gxzC14AkqHUA0jWoKopgJI1EklwBCSenUtCsyxSsFieUkSgtODlBjNxKdaFpTSSW c4ocflzluytAoPDolo+2wi6eVNQGgB801OFgFUYJnekePEeKicDpuMSV2f6SVpfe Sloq23neNgh3bzgctKhWjuOFjNPBAgLuD/sufBaSO/MH/qECNMX56eTmEuxnwlMi xcF/9r5perSOjU7ML/VIynASF0eZNz70EjSYzso+hCfxpkTetGXd4NOGHpqKCc5W p33bUIrmNpkTJ6dJ5B4BxRv2QB8pLCIN8btTeKSe6TaKS/0qolaSNDoj3/hLZxqP SgmUpw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=RpCt7TarUT+5VepmdYRzPkHUagkgIUTD1RO+azeEx FA=; b=bN9Wv7F0IWjBIMW7nGrlFZw4rww/Ycxms4gM8GcPrKFKd4reymalnXGzR ftWqYQvmaaVqnSvxBNiORUOJe6daes7YnRe1U5aL15dMAJ84z1ZPmhHy4jHr+52H 53BjiS6dZp/gS3OGQbe8zEWSHRZpm0Gmd0Jel6CZFwOUcTyDYCNPrCgOY1ISLoY2 ccHYk5MWxSO5KCnNthetXF3rdov7AEvQqUqbp7bZTcJi7+qLFBQR5/nB0GdSF4+C aQ9H5KHQNuDlJ7PP2cVQL1VA4lrPNYv50bJ1ewNRgdhb+RgCInRD6iIwuqr/CI1j I6IF07QVnEgWD2D6as3q1G6+gRe1A== X-ME-Sender: <xms:hryGX_gINTEHR5-h7PPWFkXUm_EAqxLm2vXOrNHJ8HY3qlS1CQ1cNQ> <xme:hryGX8C9OTby3-Kke6pTqFwmZuUqWyZVh1-4orle03f5NF7ap-cwGwjBBIHfnBNwk EtyBB1Xh4i19eBFRA> X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedriedugddtlecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhvffufffkjghfggfgtgesthhqredttddtudenucfhrhhomhepvfhhohhmrghs ucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenucggtf frrghtthgvrhhnpeeujeduffdtudeiudetgefhledtheehteekfeeiieeikedtvdfgheff uddtjeethfenucffohhmrghinhepughpughkrdhorhhgpdhsmhgrrhhtshhhrghrvgdrug hknecukfhppeejjedrudefgedrvddtfedrudekgeenucevlhhushhtvghrufhiiigvpedt necurfgrrhgrmhepmhgrihhlfhhrohhmpehthhhomhgrshesmhhonhhjrghlohhnrdhnvg ht X-ME-Proxy: <xmx:hryGX_GicFtulS5gW1RY5BChjqAl1_S-KXBq5lk7pE_CX4JE1GtWYg> <xmx:hryGX8RSaZqzEbqbDptY46rhzVlUm1u2NNKc15EUHkKSa9mFtrqjBg> <xmx:hryGX8wZKODlH9_A-rAoXSR4-jYwLFQwLhiaxWrpMwlJzc2uBd736g> <xmx:h7yGX4_dncODTeNSYzIk0KGg6ZJ009zCd92mXjddxmGLFPwdtWXWLg> Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id D83C53064674; Wed, 14 Oct 2020 04:53:25 -0400 (EDT) From: Thomas Monjalon <thomas@monjalon.net> To: Ferruh Yigit <ferruh.yigit@intel.com>, Bruce Richardson <bruce.richardson@intel.com>, Morten =?ISO-8859-1?Q?Br=F8rup?= <mb@smartsharesystems.com> Cc: arybchenko@solarflare.com, jia.guo@intel.com, dev@dpdk.org Date: Wed, 14 Oct 2020 10:53:24 +0200 Message-ID: <2517144.VUf8PMuDld@thomas> In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35C6136A@smartserver.smartshare.dk> References: <20200914110511.95609-1-mb@smartsharesystems.com> <60d87dbf-167e-d0a6-781a-5f54ee5cb5ac@intel.com> <98CBD80474FA8B44BF855DF32C47DC35C6136A@smartserver.smartshare.dk> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" 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 <dev.dpdk.org> List-Unsubscribe: <https://mails.dpdk.org/options/dev>, <mailto:dev-request@dpdk.org?subject=unsubscribe> List-Archive: <http://mails.dpdk.org/archives/dev/> List-Post: <mailto:dev@dpdk.org> List-Help: <mailto:dev-request@dpdk.org?subject=help> List-Subscribe: <https://mails.dpdk.org/listinfo/dev>, <mailto:dev-request@dpdk.org?subject=subscribe> Errors-To: dev-bounces@dpdk.org Sender: "dev" <dev-bounces@dpdk.org> 14/10/2020 10:26, Morten Br=F8rup: > From: Ferruh Yigit > > On 9/14/2020 1:42 PM, Morten Br=F8rup wrote: > > > From: Bruce Richardson > > >> On Mon, Sep 14, 2020 at 01:05:11PM +0200, Morten Br=F8rup 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@sma= rts > > >> erver.smartshare.dk/ > > >>> > > >>> --- 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 asynchron= ous > > >>> * 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* driv= er > > >> 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=3D9, 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 descriptio= n we > > reached in the RFC discussion. > > > > >=20 > > Hi Morten, Bruce, > >=20 > > +1 to document the this behavior. > >=20 > > 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." > >=20 > > 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. > >=20 > > 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? > >=20 > > Bruce's explanation sound more accurate to me, what do you think? > >=20 >=20 > I aim to keep the explanation in the documentation relatively simple. Kee= p the parameter description short, and add the details about vector driver = behavior as a note to the function. >=20 > The reason for all this is the existing documentation describing how to u= se the rte_eth_rx_burst() function at high level: >=20 > The rte_eth_rx_burst() function returns the number of packets actually re= trieved [...]. A return value equal to nb_pkts indicates [...] that other r= eceived packets remain in the input queue. Applications implementing a "ret= rieve as much received packets as possible" policy can check this specific = case and keep invoking the rte_eth_rx_burst() function until a value less t= han nb_pkts is returned. >=20 > As an alternative to my proposed solution, we could add that vector drive= rs round down to 4 or 8, and the application's comparison of the nb_pkts an= d return value must consider this. But that would make the above descriptio= n strangely complex, rather than just requiring that nb_pkts for vector dri= vers must be divisible by 4 or 8. >=20 > And as a minor detail, keeping my proposed restriction would also elimina= te the vector drivers' need to round down. >=20 > I don't see a need to be able to call rte_eth_rx_burst() with a value not= divisible by 4 or 8 for a vector driver, so my proposed restriction is a t= radeoff favoring simplicity over unnecessary flexibility. It makes sense to me.