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 727BC4240B; Wed, 18 Jan 2023 08:28:36 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 11E3240DFD; Wed, 18 Jan 2023 08:28:36 +0100 (CET) Received: from shelob.oktetlabs.ru (shelob.oktetlabs.ru [91.220.146.113]) by mails.dpdk.org (Postfix) with ESMTP id A65F14003F for ; Wed, 18 Jan 2023 08:28:34 +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 7819D50; Wed, 18 Jan 2023 10:28:33 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 shelob.oktetlabs.ru 7819D50 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=oktetlabs.ru; s=default; t=1674026913; bh=Snghn0aHZeARLaG5uRoJYIBtGNRq1UrjlClSPcSV9Vw=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=b/HGbv2P5OSha1NMtOBN8vNiSKieRSHvbg0YUT13d4Z+EQ8OgK2zS+GuBjtQDJHDL dXBV74te8v0Bke1I+O6uWhQ9nsOI6LA1XtNCP6BUuJKeLxER8OiCvhIATSy+sOS9Ho zemWeDXc6dfuJmXI6Is4JJ37t8L9IwwrvAZ0Ssjc= Message-ID: <1f7972ac-ad64-bde4-554d-d3ee1afbc324@oktetlabs.ru> Date: Wed, 18 Jan 2023 10:28:33 +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: Rongwei Liu , matan@nvidia.com, viacheslavo@nvidia.com, orika@nvidia.com, thomas@monjalon.net, Aman Singh , Yuying Zhang , Ferruh Yigit 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: <20221114115946.1074787-1-rongweil@nvidia.com> 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 11/14/22 14:59, 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. The above description is misleading. It alternates options (1) and (2), but in fact (2) requires (1) as well. (2) is simply done on different level - much earlier, before flow rules creation. Since resources allocation is assumed to be done on table creation, we need to know the purpose of the table in advance to optimize resources allocation. Since (2) is *not a matching criteria*, but just a hint, (1) flow rules must have matching criteria anyway. > > 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 [snip] > diff --git a/doc/guides/prog_guide/rte_flow.rst b/doc/guides/prog_guide/rte_flow.rst > index 3e6242803d..d9ca041ae4 100644 > --- a/doc/guides/prog_guide/rte_flow.rst > +++ b/doc/guides/prog_guide/rte_flow.rst > @@ -3605,6 +3605,21 @@ and pattern and actions templates are created. > &actions_templates, nb_actions_templ, > &error); > > +Table Attribute: Specialize > +^^^^^^^^^^^^^^^^^^^^^^^^^^^ > + > +Application can help optimizing underlayer resources and insertion rate > +by specializing template table. > +Specialization is done by providing hints > +in the template table attribute ``specialize``. > + > +This attribute is not mandatory for each PMD to implement. > +If a hint is not supported, it will be silently ignored, > +and no special optimization is done. > + > +If a table is specialized, the application should make sure the rules > +comply with the table attribute. If a table is specialized, the application must make sure that all flow rules added to the table have pattern which implies corresponding matching criteria. For example if a table is specialized to be wire-origin only, pattern should have represented port item with ethdev which corresponds to a physical port (or any other item which matches packets coming from wire only). [snip]