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 005394240B; Wed, 18 Jan 2023 08:31:00 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 99D0840DFD; Wed, 18 Jan 2023 08:31:00 +0100 (CET) Received: from shelob.oktetlabs.ru (shelob.oktetlabs.ru [91.220.146.113]) by mails.dpdk.org (Postfix) with ESMTP id 67FCC4003F for ; Wed, 18 Jan 2023 08:30:59 +0100 (CET) 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 564E150; Wed, 18 Jan 2023 10:30:58 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 shelob.oktetlabs.ru 564E150 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=oktetlabs.ru; s=default; t=1674027058; bh=rZd4AmTYKy3PT3cEKJoL1gYrZjyIX2RlcnTRd0GB31Y=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=LJsRiCEas7Nn5UBWmwRPqMXVAx/nM6ISNuHGlwsOvw5Vvr5vmjeUp6CUfDA/MBoe+ fqmCoFFppnaR5YDaSu7+qF0tYAyzPGV2XnvFBogLu0q7hy6BxmNxuqyCfarIgrGbEO DRdwojdBFoRPmh08fS3IcOziQ4rAa6Y40mZqvEro= Message-ID: Date: Wed, 18 Jan 2023 10:30:57 +0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.5.0 Subject: Re: [PATCH v7] ethdev: add special flags when creating async transfer table Content-Language: en-US To: Ferruh Yigit , Rongwei Liu , matan@nvidia.com, viacheslavo@nvidia.com, orika@nvidia.com, Aman Singh , Yuying Zhang , Ivan Malov , thomas@monjalon.net Cc: dev@dpdk.org, rasland@nvidia.com References: <51e583ea-4446-fea5-af74-dfe75d37f05c@oktetlabs.ru> <20221114115946.1074787-1-rongweil@nvidia.com> From: Andrew Rybchenko Organization: OKTET Labs In-Reply-To: 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 1/17/23 18:13, Ferruh Yigit wrote: > On 11/14/2022 11:59 AM, Rongwei Liu wrote: >> In case flow rules match only one kind of traffic in a flow table, >> then optimization can be done via allocation of this table. >> Such optimization is possible only if the application gives a hint >> about its usage of the table during initial configuration. >> >> The transfer domain rules may process traffic from wire or vport, >> which may correspond to two kinds of underlayer resources. >> That's why the first two hints introduced in this patch are about >> wire and vport traffic specialization. >> Wire means traffic arrives from the uplink port while vport means >> traffic initiated from VF/SF. >> >> There are two possible approaches for providing the hints. >> Using IPv4 as an example: >> 1. Use pattern item in both template table and flow rules. >> >> pattern_template: pattern ANY_VPORT / eth / ipv4 is 1.1.1.1 / end >> async flow create: pattern ANY_VPORT / eth / ipv4 is 1.1.1.2 / end >> >> "ANY_VPORT" needs to be present in each flow rule even if it's >> just a hint. No value to match because matching is already done by >> IPv4 item. >> >> 2. Add special flags into table_attr. >> >> template_table 0 create table_id 0 group 1 transfer vport_orig >> >> Approach 1 needs to specify the pattern in each flow rule which wastes >> memory and is not user friendly. >> This patch takes the 2nd approach and introduces one new member >> "specialize" into rte_flow_table_attr to indicate possible flow table >> optimization. >> >> By default, there is no hint, so the behavior of the transfer domain >> doesn't change. >> There is no guarantee that the hint will be used by the PMD. >> >> Signed-off-by: Rongwei Liu >> Acked-by: Ori Kam > > Hi Andrew, Ivan, > > Do you have objection/comment to latest version, if not I will proceed > with patch? > > Thanks, > ferruh Hi Ferruh, Sorry, but I'm still unhappy with the description. See my reply. Thanks, Andrew.