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 43A4CA00C4; Thu, 31 Oct 2019 14:39:09 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 09F571C23D; Thu, 31 Oct 2019 14:39:08 +0100 (CET) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by dpdk.org (Postfix) with ESMTP id 108851C23C for ; Thu, 31 Oct 2019 14:39:06 +0100 (CET) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 5A22422502; Thu, 31 Oct 2019 09:39:04 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Thu, 31 Oct 2019 09:39:04 -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=mesmtp; bh=21wuTiBrBznQs1VXHu4YUq211HmzAycsgAmhg9aDx5Q=; b=DWEPswSFZ2li xOhWqQ3sLW/M9ABY1e6kdZXmDb8cHo3UtdewLh0W45GMwMlqBozq3VWaEBZvMt16 dJnSwfxW6lKuUnC+ShMz9zdDbhs8IeYx4HBa5YfmgOlyFzwsgqqZ3cbxw1DP3xux dYVG7/xnIQTPgYH37nllxV/TEUdyN6E= 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=21wuTiBrBznQs1VXHu4YUq211HmzAycsgAmhg9aDx 5Q=; b=wSXrJmkKBwBPx9wziq1QKaRyQfd83tp93QsaJUGH4za24nt/xfrOsSYNG gloSgBKItpl2lx9KYrH7b5hf6nDXwTsO3hvdh8UZcOTnb3YqPuezSa3e4D3iTmLm AGvtQfW7gl1S8R/V09cgtfZzBIyJ+RElipjGTEimHyYjit29lCAKZ9qkDJeH7qKz 8Cz350RHHGb7kwdW+MmMGSeTmoei4siMv3E3xSHBK/LYKxgrLsNIwOMI61xknkLT jnHKpllpMQHS8jpKzjAAx9eiSr3VwdeKiuvtX88pjY7QWIcw7yHDhWRnSf0RetMA HU9Wd/xPmcFavLBdk9agYJhhtJMug== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedruddthedghedvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecukf hppeejjedrudefgedrvddtfedrudekgeenucfrrghrrghmpehmrghilhhfrhhomhepthhh ohhmrghssehmohhnjhgrlhhonhdrnhgvthenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 7056280068; Thu, 31 Oct 2019 09:39:02 -0400 (EDT) From: Thomas Monjalon To: pbhagavatula@marvell.com Cc: dev@dpdk.org, ferruh.yigit@intel.com, arybchenko@solarflare.com, jerinj@marvell.com, John McNamara , Marko Kovacevic Date: Thu, 31 Oct 2019 14:39:01 +0100 Message-ID: <11736109.b5uY1SBMPI@xps> In-Reply-To: <20191029153722.4547-2-pbhagavatula@marvell.com> References: <20191029050312.2715-1-pbhagavatula@marvell.com> <20191029153722.4547-1-pbhagavatula@marvell.com> <20191029153722.4547-2-pbhagavatula@marvell.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH v15 1/7] ethdev: add set ptype function 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" 29/10/2019 16:37, pbhagavatula@marvell.com: > From: Pavan Nikhilesh > --- a/doc/guides/rel_notes/release_19_11.rst > +++ b/doc/guides/rel_notes/release_19_11.rst > @@ -231,6 +231,14 @@ New Features > * Added a console command to testpmd app, ``show port (port_id) ptypes`` which > gives ability to print port supported ptypes in different protocol layers. > > +* **Added ethdev API to set supported packet types** > + > + * Added new API ``rte_eth_dev_set_supported_ptypes`` that allows an > + application to inform PMD about packet types classification the application > + is interested in > + * This scheme will allow PMDs to avoid lookup to internal ptype table on Rx > + and thereby improve Rx performance if application wishes do so. You just added or rebased this paragraph at the end. As mentioned in the release notes files (top of the section), there is an order for presenting features. > Removed Items > ------------- > --- a/lib/librte_ethdev/rte_ethdev.h > +++ b/lib/librte_ethdev/rte_ethdev.h > +/** > + * @warning > + * @b EXPERIMENTAL: this API may change without prior notice. > + * > + * Inform Ethernet device of the packet types classification the recipient is > + * interested in. This is a bit convoluted. What about this? "Optimize driver handling of packet types by reducing its range." > + * > + * Application can use this function to set only specific ptypes that it's > + * interested. This information can be used by the PMD to optimize Rx path. > + * > + * The function accepts an array `set_ptypes` allocated by the caller to > + * store the packet types set by the driver, the last element of the array > + * is set to RTE_PTYPE_UNKNOWN. The size of the `set_ptype` array should be > + * `rte_eth_dev_get_supported_ptypes() + 1` else it might only be filled > + * partially. > + * > + * @param port_id > + * The port identifier of the Ethernet device. > + * @param ptype_mask > + * The ptype family that application is interested in should be bitwise OR of > + * RTE_PTYPE_*_MASK or 0. > + * @param set_ptypes > + * An array pointer to store set packet types, allocated by caller. The > + * function marks the end of array with RTE_PTYPE_UNKNOWN. > + * @param num > + * Size of the array pointed by param ptypes. > + * Should be rte_eth_dev_get_supported_ptypes() + 1 to accommodate the > + * set ptypes. > + * @return > + * - (0) if Success. > + * - (-ENODEV) if *port_id* invalid. > + * - (-EINVAL) if *ptype_mask* is invalid (or) set_ptypes is NULL and > + * num > 0. > + */ John, please you check the English wording? > +__rte_experimental > +int rte_eth_dev_set_supported_ptypes(uint16_t port_id, uint32_t ptype_mask, > + uint32_t *set_ptypes, unsigned int num); I don't like the name of the function because they are not "supported" packet types but "requested". What about replacing "set_supported" with "set_allowed", or "white_list"?