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 8DB44A0093; Tue, 8 Nov 2022 15:38:54 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 7D37D42D35; Tue, 8 Nov 2022 15:38:54 +0100 (CET) Received: from shelob.oktetlabs.ru (shelob.oktetlabs.ru [91.220.146.113]) by mails.dpdk.org (Postfix) with ESMTP id 47CD0400D4 for ; Tue, 8 Nov 2022 15:38:53 +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 9EA9766; Tue, 8 Nov 2022 17:38:52 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 shelob.oktetlabs.ru 9EA9766 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=oktetlabs.ru; s=default; t=1667918332; bh=Vo4io71+ted0LO7aLu1hlT76m6oVGeEpeByWLh6OLB8=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=lLUla0Nzo7XQH5xz/s+wC3hCCagGGp8MCSmoaFYYmP0JkkDuii2laSrvH4bBGdY6Y csEOP+ijU0zbAel96SWobaC+FJq1EO79BZbUifT9oeyA2i7nVK7NfuAmp0oN/1OA4q guihimC4URYPw1ZuQAd10VQc8qaN5DSzyCfla/bE= Message-ID: Date: Tue, 8 Nov 2022 17:38:52 +0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.0 Subject: Re: [PATCH v4] ethdev: add special flags when creating async transfer table Content-Language: en-US To: Thomas Monjalon Cc: Rongwei Liu , matan@nvidia.com, viacheslavo@nvidia.com, orika@nvidia.com, Aman Singh , Yuying Zhang , Ferruh Yigit , dev@dpdk.org, rasland@nvidia.com References: <125dc971-f3e6-b834-2488-c44047ef14b4@oktetlabs.ru> <8e1d278e-f9db-26f3-ff5f-c12be9db1827@oktetlabs.ru> <2068231.htQpZWrp2x@thomas> From: Andrew Rybchenko Organization: OKTET Labs In-Reply-To: <2068231.htQpZWrp2x@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 11/8/22 16:29, Thomas Monjalon wrote: > 08/11/2022 12:47, Andrew Rybchenko: >> On 11/8/22 14:39, Andrew Rybchenko wrote: >>> On 11/4/22 13:44, Rongwei Liu wrote: >>>> diff --git a/lib/ethdev/rte_flow.h b/lib/ethdev/rte_flow.h >>>> index 8858b56428..1eab12796f 100644 >>>> --- a/lib/ethdev/rte_flow.h >>>> +++ b/lib/ethdev/rte_flow.h >>>> @@ -5186,6 +5186,34 @@ rte_flow_actions_template_destroy(uint16_t >>>> port_id, >>>> */ >>>> struct rte_flow_template_table; >>>> +/** >>>> + * @warning >>>> + * @b EXPERIMENTAL: this API may change without prior notice. >>>> + * >>>> + * Special optional flags for template table attribute. >>>> + * Each bit stands for a table specialization >>>> + * offering a potential optimization at PMD layer. >>>> + * PMD can ignore the unsupported bits silently. >>>> + */ >>>> +enum rte_flow_template_table_specialize { >>>> + /** >>>> + * Specialize table for transfer flows which come only from wire. >>>> + * It allows PMD not to allocate resources for non-wire >>>> originated traffic. >>>> + * This bit is not a matching criteria, just an optimization hint. >>>> + * Flow rules which match non-wire originated traffic will be missed >>>> + * if the hint is supported. >> >> Sorry, but if so, the hint changes behavior. > > Yes the hint may change behaviour. > >> Let's consider a rule which matches both VF originating and >> wire originating traffic. Will the rule be missed (ignored) >> regardless if the hint is supported or not? > > If the hint RTE_FLOW_TRANSFER_WIRE_ORIG is used, > the PMD may assume the table won't be used for traffic > which is not coming from wire ports. > As a consequence, the table may be implemented on the path > of wire traffic only. > In this case, the traffic coming from virtual ports > won't be affected by this table. > To answer the question, a rule matching both virtual and wire traffic > will be applied in a table affecting only wire traffic, > so it will still apply (not completely ignored). If so, it is not a hint. It becomes matching criteria which should be in pattern as we discussed. > > If you really want to manage both types of traffic in this table, > you must not use such hint. > >> I.e. it will not apply to wire originated traffic as well. >> >>>> + */ >>>> + RTE_FLOW_TRANSFER_WIRE_ORIG = RTE_BIT32(0), >>>> + /** >>>> + * Specialize table for transfer flows which come only from vport >>>> (e.g. VF, SF). >>>> + * It allows PMD not to allocate resources for non-vport >>>> originated traffic. >>>> + * This bit is not a matching criteria, just an optimization hint. >>>> + * Flow rules which match non-vport originated traffic will be >>>> missed >>>> + * if the hint is supported. >>>> + */ >>>> + RTE_FLOW_TRANSFER_VPORT_ORIG = RTE_BIT32(1), >>>> +}; >>>> + >>>> /** >>>> * @warning >>>> * @b EXPERIMENTAL: this API may change without prior notice. >>>> @@ -5201,6 +5229,10 @@ struct rte_flow_template_table_attr { >>>> * Maximum number of flow rules that this table holds. >>>> */ >>>> uint32_t nb_flows; >>>> + /** >>>> + * Optional hint flags for PMD optimization. >>>> + */ >>>> + enum rte_flow_template_table_specialize specialize; >>> >>> >>> IMHO it is not 100% correct to use enum for flag since >>> RTE_FLOW_TRANSFER_WIRE_ORIG | RTE_FLOW_TRANSFER_VPORT_ORIG >>> is not the enum member. uint32_t is a better option here since >>> bits are defined as RTE_BIT32. enum should be mentioned in the >>> description. > > I agree, let's not use enum. > Instead we can mention the prefix of the defines in the comments. > >