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 7D38CA04B5; Fri, 2 Oct 2020 16:40:48 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 69C801D919; Fri, 2 Oct 2020 16:40:46 +0200 (CEST) Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) by dpdk.org (Postfix) with ESMTP id 5B2091D6F9 for ; Fri, 2 Oct 2020 16:40:44 +0200 (CEST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.west.internal (Postfix) with ESMTP id DAF13B69; Fri, 2 Oct 2020 10:40:41 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Fri, 02 Oct 2020 10:40:42 -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= aQ+VQ1sqTdLjE3WHcrg14ylj1VqUM4ULa5sEesbSeoI=; b=osgThMX1+mcjKJUh 3qRTyfmYO402+F1LETMQSmpmypfOiuM104zzEwzOtdV/e17i44EOkVglNs/azEyt R4CnbEIyCyppW8CPo/G3QO3ReUG9t/k+ykhcvIlVflkAo6NlchLaTChg1nLl4vz9 6f8mt6mm2NW3yseL0uyWVr9CqHTTjbYGwkFpujYLruE0Ota4nTghEA1SapIGEud0 nn6/Go9PG+JERCTVzPtUBMRyPRiF7Iwdsw5clfQUoaA6Qok8tfWPyNP3iS4A7fXb ki5XAisth4O1vrDNEJiYgqZ+pESvXcLMuX43JchaFwy4haj3CjvyaT3wgscw1mFr CKhx4A== 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=fm3; bh=aQ+VQ1sqTdLjE3WHcrg14ylj1VqUM4ULa5sEesbSe oI=; b=U/SjxfNJch+CTjkTPZ5kz4ASgXfjM0niDKR4gHfVaPWRji80262KkmPkJ JTCzS/vkEvLPem3McgD1DyTXgVvc3h466kMcoT8e+ZP7CjUJgODTCnVOD+/+VWZY 2rtoDil9wHElbH43CpV6tDvDso4gu1CQNT+WppLO5E1sX675L/urodvjLVCVpt/c h3KpLaFpNUKg+Tb1ecneHA1vmca6aD9jKFQzHl3yfZS9BjEVIAsYcm9k9IP3xQ8r yiJ5FvgLTl43GFCJoMfTV3Deeja5T1gsboe6vgoACXR7flimdqwvqjNTxdW/J7TP B+UW9oE/8W5U4rquvNBLThKc9hzew== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrfeeigdejjecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhvffufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhmrghs ucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenucggtf frrghtthgvrhhnpeffvdffjeeuteelfeeileduudeugfetjeelveefkeejfeeigeehteff vdekfeegudenucffohhmrghinhepughpughkrdhorhhgnecukfhppeejjedrudefgedrvd dtfedrudekgeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhr ohhmpehthhhomhgrshesmhhonhhjrghlohhnrdhnvght 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 C36973280063; Fri, 2 Oct 2020 10:40:39 -0400 (EDT) From: Thomas Monjalon To: Dekel Peled , Maxime Leroy Cc: Ori Kam , ferruh.yigit@intel.com, arybchenko@solarflare.com, dev@dpdk.org Date: Fri, 02 Oct 2020 16:40:38 +0200 Message-ID: <2571951.iDdFJuTnZf@thomas> In-Reply-To: References: <209f5087596180d7866a43f0a0f12c9a032eb7ce.1601577847.git.dekelp@nvidia.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH] ethdev: add VLAN attributes to ETH and VLAN items 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" 02/10/2020 14:39, Maxime Leroy: > Hi Dekel, > > On Thu, Oct 1, 2020 at 8:49 PM Dekel Peled wrote: > > > > From: Dekel Peled > > > > This patch implements the change proposes in RFC [1], adding dedicated > > fields to ETH and VLAN items structs, to clearly define the required > > characteristic of a packet, and enable precise match criteria. Please add more explanations, without relying on what is in RFC. We need to clearly understand the motivation and why this implementation is chosen. If you correctly thread your patch with previous ones, it should not be needed to mention RFC. > > > > [1] https://mails.dpdk.org/archives/dev/2020-August/177536.html > > > > Signed-off-by: Dekel Peled > > I am still wondering, why not using a new item 'NOT' for example to > match only eth packet not tagged ? > example: eth / not vlan. It's a more generic solution. > > Here in this commit, we add a reference on VLAN fields on ethernet header. > But tomorrow, we could do the same for mpls by adding mpls_exists in > the eth item and so on. > > In fact, we have the same needs for IPv6 options. To match for > example, ipv6 packet with no fragment option. > With a NOT field, it can be easily done: > eth / ipv6 / no ipv6_frag. > > Adding new fields 'item'_exists into eth and ipv6 do the jobs, but > having a NOT attribute is a more generic solution. > > It could address many other use cases like matching any udp packets > that are not vxlan ( eth / ipv4 / vxlan / not udp), > > Let me know what you think about that. You're right Maxime, a NOT operator looks better for the user, but it is expected to be very hard to implement and offload.