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 9F50AA04DB; Thu, 15 Oct 2020 01:40:15 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 27A601DA6A; Thu, 15 Oct 2020 01:40:13 +0200 (CEST) Received: from new3-smtp.messagingengine.com (new3-smtp.messagingengine.com [66.111.4.229]) by dpdk.org (Postfix) with ESMTP id C1EE41D5D3 for ; Thu, 15 Oct 2020 01:40:11 +0200 (CEST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailnew.nyi.internal (Postfix) with ESMTP id 246E25802F1; Wed, 14 Oct 2020 19:40:10 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Wed, 14 Oct 2020 19:40:10 -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= ctVafK7aX0rvZc7cmMlWFDfQjL2tYCJdsNKzPDt9iZI=; b=DefM+sn7u4D6R++C FWQlLnlPBPXMHj290I1rhhSsYkiIJf//u2CEk2BMWx4Jg0kl7qdwRyN5DgaWfHYR RjTTwG42KybmTxpl7owN5ggLsd+tPcQ3PU82Ui4r2VZiwhznqBlEQDoDpudirnDN 7msQduamGuMfQfv7vCYDmi6vSTmQuuC49jw2uO5fMtjwGk6TRyhXY5Yk6sxZjIuZ Zm3JZlvGKq3AA1YVYWE6bzULfop+K7UHjoLikc+RIbotnDRVOgbkyj059952K2SI lopvO6KgTWDFw1j81os7V4XWZsgbvGCCqQPQ0ky28fdtwBQzVmGY/NM5RAQ5Xf2d QPNs6g== 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=ctVafK7aX0rvZc7cmMlWFDfQjL2tYCJdsNKzPDt9i ZI=; b=LuVnSUhsw0twD0gDU1A5BSr6yKhoYhQUwoHuU9pl8Jj1g++QSJsaPq7hN CvbqyXVshMLDzyhuHoSJjVfQ5K8GS0plJDGQXHTAFCcYPHJcKDS1h2e2F6laVBib bohJZj3GVg0KBM5aq0DHIg6KjLXjoXwQItI83jBhvv/UvGqNqCA3n6CqzdiCD7of biDaOIjjOQG5zgQxn32mBAYHW41gNPKyn5f/ujX1wCpM7DyiI1XyUpCpSw/9UAWo e8PxxTYrDV45wV2MgZinsHvWIsdZGPuzoWWkF5XXO9e08qbOY+gad5dKRlM6mDqP xeW11XTV21aQh5o24erd/+Rm6gFKg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedriedvgddvgecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhvffufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhmrghs ucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenucggtf frrghtthgvrhhnpedugefgvdefudfftdefgeelgffhueekgfffhfeujedtteeutdejueei iedvffegheenucfkphepjeejrddufeegrddvtdefrddukeegnecuvehluhhsthgvrhfuih iivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepthhhohhmrghssehmohhnjhgrlhho nhdrnhgvth 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 3F7933064682; Wed, 14 Oct 2020 19:40:08 -0400 (EDT) From: Thomas Monjalon To: Gregory Etelson Cc: dev@dpdk.org, matan@nvidia.com, rasland@nvidia.com, elibr@nvidia.com, ozsh@nvidia.com, ajit.khaparde@broadcom.com, Ori Kam , Viacheslav Ovsiienko , Ferruh Yigit , Andrew Rybchenko Date: Thu, 15 Oct 2020 01:40:07 +0200 Message-ID: <1965302.oBouennT9Z@thomas> In-Reply-To: <20201004135040.10307-2-getelson@nvidia.com> References: <20200625160348.26220-1-getelson@mellanox.com> <20201004135040.10307-1-getelson@nvidia.com> <20201004135040.10307-2-getelson@nvidia.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH v4 1/4] ethdev: allow negative values in flow rule types 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" 04/10/2020 15:50, Gregory Etelson: > From: Gregory Etelson > > RTE flow items & actions use positive values in item & action type. > Negative values are reserved for PMD private types. PMD > items & actions usually are not exposed to application and are not > used to create RTE flows. > > The patch allows applications with access to PMD flow > items & actions ability to integrate RTE and PMD items & actions > and use them to create flow rule. > > RTE flow item or action coversion library accepts positive known typo: coversion > element types with predefined sizes only. Private PMD items and > actions do not fit into this scheme becase PMD type values are > negative, each PMD has it's own types numeration and element types and > their sizes are not visible at RTE level. To resolve these > limitations the patch proposes this solution: > 1. PMD can to expose elements of pointer size only. RTE flow typo: "can to" > conversion functions will use pointer size for each configuration > object in private PMD element it processes; > 2. RTE flow verification will not reject elements with negative type. > > Signed-off-by: Gregory Etelson Don't you want to use nvidia email? > Acked-by: Ori Kam > Acked-by: Viacheslav Ovsiienko I was not aware of negative PMD types in rte_flow. Allowing to use these opaque PMD types for magic complex rule looks OK.