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 2E03BA00BE; Thu, 17 Feb 2022 11:44:58 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 06997410FF; Thu, 17 Feb 2022 11:44:58 +0100 (CET) Received: from shelob.oktetlabs.ru (shelob.oktetlabs.ru [91.220.146.113]) by mails.dpdk.org (Postfix) with ESMTP id 1604E410FB for ; Thu, 17 Feb 2022 11:44:57 +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 (2048 bits) server-digest SHA256) (No client certificate requested) by shelob.oktetlabs.ru (Postfix) with ESMTPSA id 7DB8244; Thu, 17 Feb 2022 13:44:56 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 shelob.oktetlabs.ru 7DB8244 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=oktetlabs.ru; s=default; t=1645094696; bh=Jh+3RX9D+e8BwJylbUTvWl7vsUTXZwU5FWFTWdy6Zpc=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=eXkKKduIwCtb74bt27/1ifYgUWfTjC3+u0bPTpSzBq4xnrYQKJX4Skp97zBdC+2fE BSJGXPIDyGfsF5L4lPGvEqv69W8w3sFnuRKv96390Yh5NGYMEMtuk/6F0m1Xenm1Fe h5/5N3mH7E+JKN2h3pNKiH0FMsaXPPnapBFSmPcU= Message-ID: Date: Thu, 17 Feb 2022 13:44:56 +0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0 Subject: Re: [PATCH v5 02/10] ethdev: add flow item/action templates Content-Language: en-US To: Ori Kam , Alexander Kozyrev , "dev@dpdk.org" Cc: "NBU-Contact-Thomas Monjalon (EXTERNAL)" , "ivan.malov@oktetlabs.ru" , "ferruh.yigit@intel.com" , "mohammad.abdul.awal@intel.com" , "qi.z.zhang@intel.com" , "jerinj@marvell.com" , "ajit.khaparde@broadcom.com" , "bruce.richardson@intel.com" References: <20220209213809.1208269-1-akozyrev@nvidia.com> <20220211022653.1372318-1-akozyrev@nvidia.com> <20220211022653.1372318-3-akozyrev@nvidia.com> <0a823087-2421-9716-9f66-70be7b774ecd@oktetlabs.ru> 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 Hi Ori, On 2/16/22 17:18, Ori Kam wrote: > Hi Andrew, > >> -----Original Message----- >> From: Andrew Rybchenko >> Subject: Re: [PATCH v5 02/10] ethdev: add flow item/action templates >> >> On 2/12/22 01:25, Alexander Kozyrev wrote: >>> On Fri, Feb 11, 2022 6:27 Andrew Rybchenko wrote: >>>> On 2/11/22 05:26, Alexander Kozyrev wrote: >>>>> Treating every single flow rule as a completely independent and separate >>>>> entity negatively impacts the flow rules insertion rate. Oftentimes in an >>>>> application, many flow rules share a common structure (the same item mask >>>>> and/or action list) so they can be grouped and classified together. >>>>> This knowledge may be used as a source of optimization by a PMD/HW. >>>>> >>>>> The pattern template defines common matching fields (the item mask) without >>>>> values. The actions template holds a list of action types that will be used >>>>> together in the same rule. The specific values for items and actions will >>>>> be given only during the rule creation. >>>>> >>>>> A table combines pattern and actions templates along with shared flow rule >>>>> attributes (group ID, priority and traffic direction). This way a PMD/HW >>>>> can prepare all the resources needed for efficient flow rules creation in >>>>> the datapath. To avoid any hiccups due to memory reallocation, the maximum >>>>> number of flow rules is defined at the table creation time. >>>>> >>>>> The flow rule creation is done by selecting a table, a pattern template >>>>> and an actions template (which are bound to the table), and setting unique >>>>> values for the items and actions. >>>>> >>>>> Signed-off-by: Alexander Kozyrev >>>>> Acked-by: Ori Kam >> >> [snip] >> > > [Snip] > >>>>> + * >>>>> + * The pattern template defines common matching fields without values. >>>>> + * For example, matching on 5 tuple TCP flow, the template will be >>>>> + * eth(null) + IPv4(source + dest) + TCP(s_port + d_port), >>>>> + * while values for each rule will be set during the flow rule creation. >>>>> + * The number and order of items in the template must be the same >>>>> + * at the rule creation. >>>>> + * >>>>> + * @param port_id >>>>> + * Port identifier of Ethernet device. >>>>> + * @param[in] template_attr >>>>> + * Pattern template attributes. >>>>> + * @param[in] pattern >>>>> + * Pattern specification (list terminated by the END pattern item). >>>>> + * The spec member of an item is not used unless the end member is used. >>>> >>>> Interpretation of the pattern may depend on transfer vs non-transfer >>>> rule to be used. It is essential information and we should provide it >>>> when pattern template is created. >>>> >>>> The information is provided on table stage, but it is too late. >>> >>> Why is it too late? Application knows which template goes to which table. >>> And the pattern is generic to accommodate anything, user just need to put it >>> into the right table. >> >> Because it is more convenient to handle it when individual >> template is processed. Otherwise error reporting will be >> complicated since it could be just one template which is >> wrong. >> >> Otherwise, I see no point to have driver callbacks >> template creation API. I can do nothing here since >> I have no enough context. What's the problem to add >> the context? >> > > The idea is that the same template can be used in different > domains (ingress/egress and transfer) > May be we can add on which domains this template is expected to be used. > What do you think? I see. IMHO if application is going to use the same template in transfer and non-transfer rules, it is not a problem to register it twice. Otherwise, if PMD needs the information and template handling differs a lot in transfer and non-transfer case, handling should be postponed and should be done on table definition. In this case, we cannot provide feedback to application which template it cannot handle. Even if the information is somehow encoded in flow error, encoding must be defined and it still could be inconvenient for the application to handle it. Yes, I agree that it is better to fully specify domain including ingress and egress, not just transfer/non-transfer. Andrew.