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 5CE74A00BE; Fri, 1 Nov 2019 23:25:44 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id A49051E876; Fri, 1 Nov 2019 23:25:43 +0100 (CET) Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) by dpdk.org (Postfix) with ESMTP id 99D451E874 for <dev@dpdk.org>; Fri, 1 Nov 2019 23:25:42 +0100 (CET) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 107654EB; Fri, 1 Nov 2019 18:25:41 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Fri, 01 Nov 2019 18:25:41 -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=iZxm08PXXYdl3fKH16FoIj/WoH7EvxwEcwcLhwq6BOI=; b=QUW6/R9uepU8 Qowz+8fh/zvekZdArGsCUdSV0GqCqrLD7mMAbPlVMIJpwY/+4vyszxDRFQIc4ICI U3z1VXZ1Gn3gAu1jy/KkFKK/Pldml/LuYRQGevPXzc8whvBuohC3ViScazMDRsTY XpsK86za+e8W9ijLgLTZQNjOovbA09A= 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=iZxm08PXXYdl3fKH16FoIj/WoH7EvxwEcwcLhwq6B OI=; b=XpYrMbGHnEPYDJH6dtsNs7QzdbCcQap7ZIejeCdNkCXLnTzW7kJepUTwK WHcO+L2pxObUfrUmBqGPWYjJn/GdhVYO1L2B+hsBsiRdZTMsGfOqoXv0yJvz2Fdr yqyLgF5AGxMKVWpQIZVllqNoSz3AaaaVppiYDTr/RGrgSUknYzGq8cfq4I8cntR6 TpRfwHVhubaCvx81sEf9q5LgfEvh4XduQmb57Rq3sFOGxaxwHCjVMWu9+f0709f7 2w3D3RIlocSzMQ/UC/5hQa7DsuKWyA02W/x7fBhCW7z+8G1j0MYfROo+sbmd/qm2 X9yi9kUQ7oEO+K9fsAiDjQ0aJdeEw== X-ME-Sender: <xms:47C8XagR3mHldn4oMzeQU4r43E1BVTpg90SzBTyXFZPZ_JMLhbpwWw> X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedruddtjedgudeiudcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefhvffufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhm rghsucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenuc fkphepleefrdeirddugeelrdduudegnecurfgrrhgrmhepmhgrihhlfhhrohhmpehthhho mhgrshesmhhonhhjrghlohhnrdhnvghtnecuvehluhhsthgvrhfuihiivgepud X-ME-Proxy: <xmx:47C8XTJGSVHaD0oDJlePr07spWza2kUdBHCSzfN4O013hveWNYkYMA> <xmx:47C8XRnd9Ewk6zeAXNc3YKJHPWPQq04JpJpdXqkY9pz1ZxSHPjYupA> <xmx:47C8XTMYXZaw_2NsF6ACchbjSEspmIP7br7iM9bl9UitDc0lFaNMWA> <xmx:5LC8XUErg2aMccZj9PwqNXmMtd9zE1xK18f-uz3Aks1dJtKllPvYxQ> Received: from xps.localnet (114.149.6.93.rev.sfr.net [93.6.149.114]) by mail.messagingengine.com (Postfix) with ESMTPA id EF4CD3060060; Fri, 1 Nov 2019 18:25:38 -0400 (EDT) From: Thomas Monjalon <thomas@monjalon.net> To: Andrew Rybchenko <arybchenko@solarflare.com> Cc: Pavan Nikhilesh Bhagavatula <pbhagavatula@marvell.com>, "dev@dpdk.org" <dev@dpdk.org>, "ferruh.yigit@intel.com" <ferruh.yigit@intel.com>, Jerin Jacob Kollanukkaran <jerinj@marvell.com>, John McNamara <john.mcnamara@intel.com>, Marko Kovacevic <marko.kovacevic@intel.com> Date: Fri, 01 Nov 2019 23:25:37 +0100 Message-ID: <2639486.gPBSui7x2o@xps> In-Reply-To: <55a8ec94-bfe8-d132-5122-d322f83f02b2@solarflare.com> References: <CY4PR1801MB1863FA78FE4E6496C9EEF500DE630@CY4PR1801MB1863.namprd18.prod.outlook.com> <55a8ec94-bfe8-d132-5122-d322f83f02b2@solarflare.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 <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> 01/11/2019 11:55, Andrew Rybchenko: > On 10/31/19 7:38 PM, Pavan Nikhilesh Bhagavatula wrote: > >> 29/10/2019 16:37, pbhagavatula@marvell.com: > >>> From: Pavan Nikhilesh <pbhagavatula@marvell.com> > >>> 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." > > @arybchenko@solarflare.com Thoughts? > > Optimize is a possible side effect of the operation, but there is > no any promise that something will be optimized. > I thought that current description explains what happens. > Below statements try to explain why it may be useful. > Any other options? "Reduce range of packet types to handle." > >>> + * 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"? > > "white_list" seems ok but hope it doesn't call for blacklisting API. > > "white_list" suggests that it is guaranteed that nothing else will > be reported. At least for me. However, I agree that set_supported > is not nice and I accepted it just to keep API naming symmetric. > May be it is really misleading here. May be just: rte_eth_dev_set_ptypes()? Maybe the word "allowed" would better fit?