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 8631641B9E; Wed, 1 Feb 2023 12:29:34 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 0ABCC42BC9; Wed, 1 Feb 2023 12:29:34 +0100 (CET) Received: from shelob.oktetlabs.ru (shelob.oktetlabs.ru [91.220.146.113]) by mails.dpdk.org (Postfix) with ESMTP id BD716406A2 for ; Wed, 1 Feb 2023 12:29:32 +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 D818350; Wed, 1 Feb 2023 14:29:29 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 shelob.oktetlabs.ru D818350 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=oktetlabs.ru; s=default; t=1675250969; bh=1hv4Haf1xyH6zxGlx40A+Z5J33K94MVQY0NAHbkuw80=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=S40H9OgsjUN/ghXktiiwCfNmffoxo+LSD06DFkTjyiddIJZd8pidqsWCYjY+xC7zb HXKY6YyBrplkZtwDy4El4+1harT+6X2Qok5M922GUZf2E+tZq1uhghwf2eGAU7Z93u CaQMTJWbiQUlF1eiCsClaqhhXHKLeX7hoGpYQigc= Message-ID: Date: Wed, 1 Feb 2023 14:29:29 +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: Ori Kam , "NBU-Contact-Thomas Monjalon (EXTERNAL)" , Ferruh Yigit Cc: Rongwei Liu , Matan Azrad , Slava Ovsiienko , Aman Singh , Yuying Zhang , "dev@dpdk.org" , Raslan Darawsheh , "jerinj@marvell.com" References: <51e583ea-4446-fea5-af74-dfe75d37f05c@oktetlabs.ru> <13070250.ZYm5mLc6kN@thomas> <1339e012-0e6a-81dc-70e7-a08c51a23725@oktetlabs.ru> <5879621.alqRGMn8q6@thomas> 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 2/1/23 14:22, Ori Kam wrote: > Hi > > Please also see my previous mail. > >> -----Original Message----- >> From: Andrew Rybchenko >> Sent: Wednesday, 1 February 2023 13:11 >> >> 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. So, good application must use >> real (always) matching criteria when composing flow rules. >> 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'm sorry I don't see why. Will be in reply to Thomas > > This feature is about where to place the rule in the HW. > This feature can be useful for any HW that as different pipelines for ingress > and egress traffic. It can be used to save resources or if some actions can be done > only on one direction then the PMD can allow them and not block the this rule. > > >> 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. >> > > So we agree that the hint is good? Acceptable since we need to optimize resources. It would be better without it, but we need it.