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 6BEB743709; Sat, 16 Dec 2023 10:19:29 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 0B223402AA; Sat, 16 Dec 2023 10:19:29 +0100 (CET) Received: from shelob.oktetlabs.ru (shelob.oktetlabs.ru [91.220.146.113]) by mails.dpdk.org (Postfix) with ESMTP id 48338402A8 for ; Sat, 16 Dec 2023 10:19:27 +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 7BA5666; Sat, 16 Dec 2023 12:19:26 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 shelob.oktetlabs.ru 7BA5666 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=oktetlabs.ru; s=default; t=1702718366; bh=8zHE7JQ2hLuy9VaqnxNfTvgEmqkiTGjXDV6ltVr4rYw=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=tMlN/KH1Ch6t4j+MsnJvdCnM1jj1jXCbrZtamy2/k0v3Oj76nVffAM08yCxa0bpSZ +Hmurynt1Of0l7qObsyq+QnN5lRjuRPTgbZ9ohhV58wEXXpafAhwQpXz5Xwp85ptEr sOz1AoyFmiYulnlVyw80tVS4zq+jeV7t1waxkkco= Message-ID: Date: Sat, 16 Dec 2023 12:19:26 +0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RFC] ethdev: introduce entropy calculation Content-Language: en-US To: Ori Kam , dsosnowski@nvidia.com, ferruh.yigit@amd.com, cristian.dumitrescu@intel.com, Thomas Monjalon Cc: dev@dpdk.org, rasland@nvidia.com References: <20231210083100.7893-1-orika@nvidia.com> From: Andrew Rybchenko Organization: OKTET Labs In-Reply-To: <20231210083100.7893-1-orika@nvidia.com> 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 12/10/23 11:30, Ori Kam wrote: > When offloading rules with the encap action, the HW may calculate entropy based on the encap protocol. > Each HW can implement a different algorithm. > > When the application receives packets that should have been > encaped by the HW, but didn't reach this stage yet (for example TCP SYN packets), > then when encap is done in SW, application must apply > the same entropy calculation algorithm. > > Using the new API application can request the PMD to calculate the > value as if the packet passed in the HW. I'm still wondering why the API is required. Does app install encap rule when the first packet is processed? The rule can contain all outer headers (as it is calculated in SW anyway) and HW does not need to calculate anything. > > Signed-off-by: Ori Kam > --- > lib/ethdev/rte_flow.h | 49 +++++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 49 insertions(+) > > diff --git a/lib/ethdev/rte_flow.h b/lib/ethdev/rte_flow.h > index affdc8121b..3989b089dd 100644 > --- a/lib/ethdev/rte_flow.h > +++ b/lib/ethdev/rte_flow.h > @@ -6753,6 +6753,55 @@ rte_flow_calc_table_hash(uint16_t port_id, const struct rte_flow_template_table > const struct rte_flow_item pattern[], uint8_t pattern_template_index, > uint32_t *hash, struct rte_flow_error *error); > > +/** > + * @warning > + * @b EXPERIMENTAL: this API may change without prior notice. > + * > + * Destination field type for the entropy calculation. > + * > + * @see function rte_flow_calc_encap_entropy > + */ > +enum rte_flow_entropy_dest { > + /* Calculate entropy placed in UDP source port field. */ > + RTE_FLOW_ENTROPY_DEST_UDP_SRC_PORT, And source and destination are used together but for different purposes it is very hard to follow which is used for which purpose. I'd avoid term "dest" in the enum naming. May be present "flow" is already good enough to highlight that it is per-flow? rte_flow_encap_hash? rte_flow_encap_field_hash? > + /* Calculate entropy placed in NVGRE flow ID field. */ > + RTE_FLOW_ENTROPY_DEST_NVGRE_FLOW_ID, > +}; > + > +/** > + * @warning > + * @b EXPERIMENTAL: this API may change without prior notice. > + * > + * Calculate the entropy generated by the HW for a given pattern, > + * when encapsulation flow action is executed. > + * > + * @param[in] port_id > + * Port identifier of Ethernet device. > + * @param[in] pattern > + * The values to be used in the entropy calculation. Is it inner packet fields? Should all fields be used for hash calculation? May be it is better to describe as inner packet headers? How does app know which headers to extract and provide? > + * @param[in] dest_field > + * Type of destination field for entropy calculation. > + * @param[out] entropy > + * Used to return the calculated entropy. It will be written in network order, > + * so entropy[0] is the MSB. > + * The number of bytes is based on the destination field type.f API contract is a bit unclear here. May be it is safer to provide buffer size explicitly? > + * @param[out] error > + * Perform verbose error reporting if not NULL. > + * PMDs initialize this structure in case of error only. > + * > + * @return > + * - (0) if success. > + * - (-ENODEV) if *port_id* invalid. > + * - (-ENOTSUP) if underlying device does not support this functionality. > + * - (-EINVAL) if *pattern* doesn't hold enough information to calculate the entropy > + * or the dest is not supported. > + */ > +__rte_experimental > +int > +rte_flow_calc_encap_entropy(uint16_t port_id, const struct rte_flow_item pattern[], > + enum rte_flow_entropy_dest dest_field, uint8_t *entropy, > + struct rte_flow_error *error); > + > #ifdef __cplusplus > } > #endif