From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 7D2BBA00C5; Thu, 15 Sep 2022 10:18:35 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 61C4F4021D; Thu, 15 Sep 2022 10:18:35 +0200 (CEST) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) by mails.dpdk.org (Postfix) with ESMTP id 4602540156 for ; Thu, 15 Sep 2022 10:18:34 +0200 (CEST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 561695C017C; Thu, 15 Sep 2022 04:18:30 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Thu, 15 Sep 2022 04:18:30 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= cc:cc:content-transfer-encoding:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to; s=fm2; t=1663229910; x= 1663316310; bh=8L47pTJSzYfRnDakHvyeksO7CtymNVtFFdH2osin79k=; b=H A7qm0URWCF+22Vgo7aqzt0IBp2LgRqMWUaN6DVV45+38UVUoNakYhVEfSJhyo37X 2OEfXq+PF6RyJ/nWen4ik3eVEw8TEf3KmjNakoVmpUwJiS6geGpoMwunTShoDNzD ryX/eLFgBtC7CDfQS04EktRQcWsDusmPq595UCmbBaKZmlVt95AcHP8DhmawAAPb 2PgDss5TrZ51fqw08alsIwcTly5A0IHmMcizZFQffr1ndvHb6f40wAO595VceUqb WXEHP0euScf2w8IiNXvqX1HqV2A5UrmaB/2CqC/oNsW7OgnTfJXKfFjwVoJabgxN rWv2g322tjYOulN2EbWWA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t=1663229910; x= 1663316310; bh=8L47pTJSzYfRnDakHvyeksO7CtymNVtFFdH2osin79k=; b=i Fe2knP20u70yrD/Ju3LXyRhP10Q15jrQoSJL3qjPAol5bJMDVrkRwwVL4IK9gH5T 3dca3gvqajmNP6hRdXCooBBb4lp3v17E2rhumPdH790RCYTzIaRy8zZ/zzxmVROv AxTqCyoKcKgzzlj8h4aDmo9JVwFMkQCC9WvASh4Glsom4JmM1ugYpavRSkafb8qr dcPd+gdeYFUcXVcD/Px0kuKJwpMaRnfUUIOUE22KJRpX7aKHJM0y1HIybMu/fi2m mHRhgspiDFjAbvN4RZfwIntzkp4vJ67fhEMiga2JGGtlnF2firTy2re6744Faq7b SEFOdcpz4Q11xUiWwD6Rw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrfedukedgtddvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvvefufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhm rghsucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenuc ggtffrrghtthgvrhhnpedtjeeiieefhedtfffgvdelteeufeefheeujefgueetfedttdei kefgkeduhedtgfenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfh hrohhmpehthhhomhgrshesmhhonhhjrghlohhnrdhnvght X-ME-Proxy: Feedback-ID: i47234305:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 15 Sep 2022 04:18:29 -0400 (EDT) From: Thomas Monjalon To: Rongwei Liu , Ivan Malov Cc: Matan Azrad , Slava Ovsiienko , Ori Kam , Aman Singh , Yuying Zhang , Andrew Rybchenko , "dev@dpdk.org" , Raslan Darawsheh Subject: Re: [PATCH v1] ethdev: add direction info when creating the transfer table Date: Thu, 15 Sep 2022 10:18:26 +0200 Message-ID: <2472631.4XsnlVU6TS@thomas> In-Reply-To: References: <20220907024020.2474860-1-rongweil@nvidia.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org 15/09/2022 09:47, Ivan Malov: > As I said, match criteria belong in flow pattern. I recognise the > importance of the problem that you're looking to solve. It's very > good that you care to address it, but what this patch tries to do > is to add more match criteria in the form of new attributes with > rather questionable names... There's a room for improvement. > > When I say that new features should not confuse readers, I mean > a very basic thing: readers know that match criteria all sit > in the pattern. And they refer to the pattern item enum in > the code and in documentation to learn about criteria, > while "struct rte_flow_attr" is an unusual place from > which to learn about match criteria. > > > We should get a conclusion and reflect in the commit changes&logs, and it's easy for others to absorb. > > Yes, but before we get to that, perhaps it pays to hear > more feedback from other reviewers. Thomas? Ori? Andrew? Sorry I did not read all. I think the main question is about the use of attributes. I refer to this commit of Ivan last year which was agreed: ethdev: deprecate direction attributes in transfer flows Attributes "ingress" and "egress" can only apply unambiguosly to non-"transfer" flows. In "transfer" flows, the standpoint is effectively shifted to the embedded switch. There can be many different endpoints connected to the switch, so the use of "ingress" / "egress" does not shed light on which endpoints precisely can be considered as traffic sources. Add relevant deprecation notices and suggest the use of precise traffic source items (PORT_REPRESENTOR and REPRESENTED_PORT). Signed-off-by: Ivan Malov Acked-by: Ori Kam Acked-by: Andrew Rybchenko Acked-by: Viacheslav Ovsiienko So +1 for using only pattern items as matching criteria.