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 7184041BAE; Thu, 2 Feb 2023 13:24:28 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 1F08B40689; Thu, 2 Feb 2023 13:24:28 +0100 (CET) Received: from shelob.oktetlabs.ru (shelob.oktetlabs.ru [91.220.146.113]) by mails.dpdk.org (Postfix) with ESMTP id 9913E4021F for ; Thu, 2 Feb 2023 13:24:26 +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)) (No client certificate requested) by shelob.oktetlabs.ru (Postfix) with ESMTPSA id D0A2F50; Thu, 2 Feb 2023 15:24:25 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 shelob.oktetlabs.ru D0A2F50 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=oktetlabs.ru; s=default; t=1675340666; bh=pHiUN++VEr+pDmieemWjpo6QQZAZUXYt8fwlnOojQoc=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=T+y1mAEycTd0QCgnwfICs+/GQNc0G0OPgNuXlhqVYEDJDslWjw4Y8X+/YvnlNpUTt g/kf+2eX7Xxo1DT/pVL/LV/B54Un8eXee3I49Wwy840FWot8Fq6+/EZzMMT0bfOxZw QSoGr8Qpfn7JOn6NyYFulu4qJuUQvkd9LBVlE1T0= Message-ID: Date: Thu, 2 Feb 2023 15:24:25 +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 , Yuying Zhang Cc: Rongwei Liu , matan@nvidia.com, viacheslavo@nvidia.com, orika@nvidia.com, Aman Singh , dev@dpdk.org, rasland@nvidia.com, jerinj@marvell.com References: <51e583ea-4446-fea5-af74-dfe75d37f05c@oktetlabs.ru> <2309073.BjyWNHgNrj@thomas> <0f546992-dbd8-6d86-3d87-015a3dae98ee@oktetlabs.ru> <12425652.O9o76ZdvQC@thomas> From: Andrew Rybchenko Organization: OKTET Labs In-Reply-To: <12425652.O9o76ZdvQC@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 2/2/23 14:29, Thomas Monjalon wrote: > 02/02/2023 10:21, Andrew Rybchenko: >> On 2/1/23 16:48, Thomas Monjalon wrote: >>> 01/02/2023 12:38, Andrew Rybchenko: >>>> On 2/1/23 14:18, Thomas Monjalon wrote: >>>>> 01/02/2023 12:10, Andrew Rybchenko: >>>>>> On 2/1/23 13:58, Thomas Monjalon wrote: >>>>>>> 01/02/2023 11:17, Andrew Rybchenko: >>>>>>>> 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. >>>>>>> >>>>>>> It's OK to explain and check everything is OK, no worries. >>>>>>> Thanks for reviewing. >>>>>>> >>>>>>>>> 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? >>>>>>> >>>>>>> I think that's how template tables are designed. >>>>>>> Ori, please could you point us to the relevant documentation? >>>>>>> >>>>>>>>> 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. >>>>>>> >>>>>>> It a packet comes from a wired port AND >>>>>>> the PMD did an optimization based on this hint, >>>>>>> then the packet could be not matched. >>>>>> >>>>>> So, the hint changes matching results and therefore becomes >>>>>> a strange (extra) matching criteria under specific >>>>>> circumstance. It sounds bad. >>>>> >>>>> In this case, the user made a wrong assumption. >>>>> If the user does not do a mistake, the behavior should be the same >>>>> whether the hint is used or ignored. >>>>> >>>>>> So, good application must use >>>>>> real (always) matching criteria when composing flow rules. >>>>> >>>>> Of course, nothing replaces matching criteria. >>>>> >>>>>> So, RTE flow API should provide a way to write a good >>>>>> application without extra pain. >>>>>> That's why I'm saying that (2) requires (1) anyway. >>>>> >>>>> I don't follow this sentence. >>>>> If you mean with hint, flow matching is still required, then yes, >>>>> this is what I emphasized in my rewrite of the case (2) below. >>>>> >>>>>> It does not say that hint is not required at all. >>>>>> It is still useful for resources usage optimization if >>>>>> application knows how it is going to use particular table. >>>>> >>>>> Yes, that's an optional optimization. >>>>> It should not change the rules, >>>>> and it should not change the functional behavior >>>>> if the user does not do mistakes. >>>> >>>> So, we basically agree on the topic, but my goal here is a bit >>>> bigger. Make it easier for a user to avoid mistakes. May be it >>>> is stupid goal :) and all efforts are vain. >>>> If we have a match item with similar functionality it would be >>>> easy to just put it into a pattern. Otherwise, it could be >>>> complicated, have high chances to be skipped and rely on >>>> implicit matching criteria imposed by the hint on the HW >>>> which takes it into account. >>> >>> We may highlight in the doc that the functional behaviour must not rely >>> on the hints. It is only optional optimization and effects may vary >>> with differents driver. >>> What do you think? I don't know what else to do about user mistakes :) >> >> As I said - add corresponding pattern items. > > I think I get it now. > You suggest to have pattern items for VPORT and PHY_PORT, > so the user won't be tempted to use hint for such matching? > We used to have RTE_FLOW_ITEM_TYPE_PHY_PORT, we could think about it. Naming is bad since we had PHY_PORT before, but you get the idea right. > >> Anyway, hint itself is OK and makes sense. Hopefully >> documentation highlights that pattern match is required. > > Yes we did an effort to highlight what are hints in the last version. > >> If so, >> >> Acked-by: Andrew Rybchenko > > >