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 C5A82A0093; Tue, 8 Nov 2022 12:47:23 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 582B3400D4; Tue, 8 Nov 2022 12:47:23 +0100 (CET) Received: from shelob.oktetlabs.ru (shelob.oktetlabs.ru [91.220.146.113]) by mails.dpdk.org (Postfix) with ESMTP id 6BBFC4003C for ; Tue, 8 Nov 2022 12:47:21 +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 4084C66; Tue, 8 Nov 2022 14:47:20 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 shelob.oktetlabs.ru 4084C66 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=oktetlabs.ru; s=default; t=1667908040; bh=RNw1zCsM4S8GslqN5hx5yCbgIGqUxlYm4J5wJxgw55Q=; h=Date:Subject:From:To:Cc:References:In-Reply-To:From; b=FzCsCHIBmkcL/A/jnaKPZUbHDUamucVnHDL3GTFZxZYfVHFeRwk0D5e5KM0MZLsfv Ct6g4zyLpQMwf5iffDHAWPfXRuJgDjR0QGb+TgX5Iw6q4v2Xrq+bxS0KZAzufx/cT+ Lk14eYRFB2oqRFHc+g2Z1611W5LV3RaSzPTTgcdM= Message-ID: <8e1d278e-f9db-26f3-ff5f-c12be9db1827@oktetlabs.ru> Date: Tue, 8 Nov 2022 14:47:20 +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 From: Andrew Rybchenko To: Rongwei Liu , matan@nvidia.com, viacheslavo@nvidia.com, orika@nvidia.com, thomas@monjalon.net, Aman Singh , Yuying Zhang , Ferruh Yigit Cc: dev@dpdk.org, rasland@nvidia.com References: <20221104104439.230147-1-rongweil@nvidia.com> <125dc971-f3e6-b834-2488-c44047ef14b4@oktetlabs.ru> Organization: OKTET Labs In-Reply-To: <125dc971-f3e6-b834-2488-c44047ef14b4@oktetlabs.ru> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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 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. 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? 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. > >>   }; >>   /** >