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 7706AA0540; Wed, 21 Sep 2022 11:40:09 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 157A740697; Wed, 21 Sep 2022 11:40:09 +0200 (CEST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) by mails.dpdk.org (Postfix) with ESMTP id A00004014F for ; Wed, 21 Sep 2022 11:40:07 +0200 (CEST) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 31C235C0116; Wed, 21 Sep 2022 05:40:05 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Wed, 21 Sep 2022 05:40:05 -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=1663753205; x= 1663839605; bh=sKZTj5Mjo7kJaM5ZUEe4ys2jICFp/Xrrzd6z65gbr4k=; b=J UHbV4jsx3XphgNSHqNlTrKtzV6B+Hiam4QxZJBYHEFw2l2DGgdOw4FjA7BsuXQ2c 2qRTVlCOrDTWgoAFkQ69nPIHnJYkItdMfBf+BTY5P1CiPVUpET+PYe3P7kJOvx5F WLxkB7OpPvxED4F83pIyBdppIUYsVAdE0dTxCjMNrbWm8LulEIOFrs8/9aiMbfpk 37plkHetnqUNLAfrp912mNLaroApMev6U91kdvV7AXYmGFyLJANa1vMDrWfKIqj2 jcA9MfWd7KCyenviIy5hBpiNZXABk68IrvwWBM4oII+dkypaQ6PhHwCCJXdR87FX po5ajZ4Pgt3XB2RAfEMtQ== 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=1663753205; x= 1663839605; bh=sKZTj5Mjo7kJaM5ZUEe4ys2jICFp/Xrrzd6z65gbr4k=; b=t AukRkqDej9QRgT39xC87sBg+4KyFa/ctzKcPYuRIbfpH1RmvZ2mZYVIjFBgxTqIx xbwUNyPXupUzXr1/hZqZi+w0tyO6yez+CaKKN4XlTOn8oNccipl0DAogqaLJzPuT lVNCBVQXmNbeVv/oN7YwS9Nov1mlyoxo+qjddcTIhkPDOEw2EzDPxDk9N6Yfkt4H GmSwD/wZyq6R+5C3xQoZ6gGxKHjkf9n5fN6EabeakvowrrwIgQSpC0lyQ9R97Jor AuN3ipaKj2IB2IAihvndPY3wgXjnLW9rNOsNUFgwOpOrTarGSZbBlGO5G0jaZjYC 7UGGjD0VtLAyyk/sp+uHg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrfeefuddgudelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvvefufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhm rghsucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenuc ggtffrrghtthgvrhhnpedtjeeiieefhedtfffgvdelteeufeefheeujefgueetfedttdei kefgkeduhedtgfenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfh hrohhmpehthhhomhgrshesmhhonhhjrghlohhnrdhnvght X-ME-Proxy: Feedback-ID: i47234305:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 21 Sep 2022 05:40:03 -0400 (EDT) From: Thomas Monjalon To: Ori Kam , Ivan Malov Cc: Rongwei Liu , Matan Azrad , Slava Ovsiienko , Aman Singh , Yuying Zhang , Andrew Rybchenko , "dev@dpdk.org" , Raslan Darawsheh , jerinj@marvell.com, ajit.khaparde@broadcom.com Subject: Re: [PATCH v1] ethdev: add direction info when creating the transfer table Date: Wed, 21 Sep 2022 11:40:01 +0200 Message-ID: <13527775.RDIVbhacDa@thomas> In-Reply-To: <4733483b-effe-1eac-cbf-d238e1ec2b8@oktetlabs.ru> References: <20220907024020.2474860-1-rongweil@nvidia.com> <4733483b-effe-1eac-cbf-d238e1ec2b8@oktetlabs.ru> 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 21/09/2022 11:04, Ivan Malov: > Now it's clear to me that your intention is to match on exact ports, > as usual, but this time with a hint for the flow table. Got it. > > In your response, you say that matching on ALL vports is not what > the use case needs. OK, I understood. But please note that the > item name does not say "ALL", it says "ANY". > > OK. Say, "ANY" is also confusing. Let's then name it "VPORTS_ONLY" > and "PHY_PORTS_ONLY". This way, if user provides item VPORTS_ONLY > and then provides item REPRESENTED_PORT, these two items do not > contradict each other. Item VPORTS_ONLY defines the scope of some > kind, then the following item, REPRESENTED_PORT, makes it narrower. > > And, in documentation, one can say clearly that the user *may* > omit item VPORTS_ONLY in the exact rule pattern provided that > they have already submitted this item as part of the template. I think the problem that Rongwei & Ori are trying to solve is to allocate resources for the templates table in the right place. A table can have multiple templates. If all rules/templates for this table are dedicated to virtual ports, then the table will be allocated in a place managing only virtual ports. This allocation decision must be taken at table creation, whereas rules will be created later. In order to do this specific table allocation for vports, we need to restrict all templates of the table to be "vports only". I hope it makes things clearer. Now the question is how to achieve this? Solutions are: 1/ give a hint to the table allocation 2/ insert a pattern item in all templates of the table I don't see any other solution. Please propose if there are more options.