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 BB704A0540; Wed, 21 Sep 2022 12:04:04 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 612D940F17; Wed, 21 Sep 2022 12:04:04 +0200 (CEST) Received: from shelob.oktetlabs.ru (shelob.oktetlabs.ru [91.220.146.113]) by mails.dpdk.org (Postfix) with ESMTP id A39B04014F for ; Wed, 21 Sep 2022 12:04:02 +0200 (CEST) Received: from [192.168.38.17] (aros.oktetlabs.ru [192.168.38.17]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by shelob.oktetlabs.ru (Postfix) with ESMTPSA id D797183; Wed, 21 Sep 2022 13:04:01 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 shelob.oktetlabs.ru D797183 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=oktetlabs.ru; s=default; t=1663754642; bh=MrdXUVn2SjkMPr3kpDvzp7Yyk3Rx0mBJ3a3Y2GtevZ8=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=huLA0EB4WxiHoy2duFUzWdMWbuxChhH0u9kzl9JhJzxm5ruGHTGNeo0rqBA+CpHYn DBIJYWY/5PlLBE6yDTA4rdutjg+yVDZdR70+XZM/Ncx8WwIRCLgNmMcmQ5o5IBRegQ JjcvX4OhVMPbICnI6CfbdVLuIvVMLhWprULySO34= Message-ID: Date: Wed, 21 Sep 2022 13:04:01 +0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.13.0 Subject: Re: [PATCH v1] ethdev: add direction info when creating the transfer table Content-Language: en-US To: Thomas Monjalon , Ori Kam , Ivan Malov Cc: Rongwei Liu , Matan Azrad , Slava Ovsiienko , Aman Singh , Yuying Zhang , "dev@dpdk.org" , Raslan Darawsheh , jerinj@marvell.com, ajit.khaparde@broadcom.com References: <20220907024020.2474860-1-rongweil@nvidia.com> <4733483b-effe-1eac-cbf-d238e1ec2b8@oktetlabs.ru> <13527775.RDIVbhacDa@thomas> From: Andrew Rybchenko Organization: OKTET Labs In-Reply-To: <13527775.RDIVbhacDa@thomas> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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 On 9/21/22 12:40, Thomas Monjalon wrote: > 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. > > See my mail 3/ use jump rule which ensures that all traffic meets out expectations It means that the table creation could be postponed. Or the table could be per-configured at the point of creation and finalized when we know that all traffic will be from wires or from vports. Yes, it complicates internals to achieve the optimization.