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 ABBBE41B9D; Wed, 1 Feb 2023 11:17:42 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 96A2E4021F; Wed, 1 Feb 2023 11:17:42 +0100 (CET) Received: from shelob.oktetlabs.ru (shelob.oktetlabs.ru [91.220.146.113]) by mails.dpdk.org (Postfix) with ESMTP id 4972B40141 for ; Wed, 1 Feb 2023 11:17:41 +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 AA22050; Wed, 1 Feb 2023 13:17:40 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 shelob.oktetlabs.ru AA22050 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=oktetlabs.ru; s=default; t=1675246660; bh=RmM54KiURhj2BlPGxfqFQWLGOFYLzA0H9Gd8cqeimO4=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=ZfRHd6ESsBhJo+UJD6bj5mruNDQrHgPmpLBo21gVT1BG9B4B7PkdcMMKnY/wOX8tS BT6ts5nvKxJLew133HWpkEKyNdnJBJsXLc3nzYxKBdP8EI4Y53jSgH62RKANTCV0xm O7RJZcQ0UmL3aYLJnTaJLMQnD1AeN28iOZGOzsB0= Message-ID: <1339e012-0e6a-81dc-70e7-a08c51a23725@oktetlabs.ru> Date: Wed, 1 Feb 2023 13:17:40 +0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.6.0 Subject: Re: [PATCH v7] ethdev: add special flags when creating async transfer table Content-Language: en-US To: Thomas Monjalon , Ferruh Yigit Cc: Rongwei Liu , matan@nvidia.com, viacheslavo@nvidia.com, orika@nvidia.com, Aman Singh , Yuying Zhang , dev@dpdk.org, rasland@nvidia.com, jerinj@marvell.com References: <51e583ea-4446-fea5-af74-dfe75d37f05c@oktetlabs.ru> <20221114115946.1074787-1-rongweil@nvidia.com> <1f7972ac-ad64-bde4-554d-d3ee1afbc324@oktetlabs.ru> <13070250.ZYm5mLc6kN@thomas> From: Andrew Rybchenko Organization: OKTET Labs In-Reply-To: <13070250.ZYm5mLc6kN@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 1/18/23 19:18, Thomas Monjalon wrote: > 18/01/2023 08:28, Andrew Rybchenko: >> 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. > > Yes the above description may be misleading > and it seems you are misleaded :) It is not my intention. If it is only my problem, I'm OK to step back. > I will explain below why the option (2) doesn't require (1). > I think we should apply the same example to both cases to make it clear: > > 1. Use pattern item in both template table and flow rules: > > template table 3 = transfer pattern ANY_VPORT / eth / ipv4 src is 255.255.255.255 / end > flow rule = template_table 3 pattern ANY_VPORT / eth / ipv4 src is 1.1.1.1 / end > > The pattern template 3 will be used only to match flows coming from vports. > ANY_VPORT needs to be present in each flow rule. It looks like I lost something here. Why do we need to specify it in each flow rule if the matching is already fixed in template table? > ANY_VPORT matching is redundant with IP src 1.1.1.1 because > the user knows 1.1.1.1 is the IP of a vport. What should happen if a packet with src IP 1.1.1.1 comes from the wire? Almost anything could come from network. > > 2. Add specialization flag into template table attribute: > > template table 3 = transfer VPORT_ORIG pattern eth / ipv4 src is 255.255.255.255 / end > flow rule = template_table 3 pattern eth / ipv4 src is 1.1.1.1 / end > > The pattern template 3 can be used only to match flows coming from vports. In this case it is interesting how it will behave on: a NIC which does not support VPORT_ORIG and just ignores it VS a NIC which support VPORT_ORIG and takes it into account. > >> (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. > > Actually in both cases we get the hint at template table creation. > But in solution 2 we are not creating a redundant pattern matching, > and we don't need to check it in flow rules, so it is more efficient. > >> Since (2) is *not a matching criteria*, but just a hint, (1) >> flow rules must have matching criteria anyway. > > No we don't need the matching criteria ANY_VPORT with solution (2) > because we are already matching on an IP src which is a vport. > >>> +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). > > No need of a matching criteria strictly mapping the hint. > Here the hint is SPECIALIZE_TRANSFER_VPORT_ORIG > and the rules can match on an IP src which is assigned to a vport. > So there is no need to strictly match the vport itself in the rule. If so, the problem is that the same rules will behave in a different way on different NICs. > Hope it make thinks clear. > We can improve the commit log as I wrote above. > >