From: Ferruh Yigit <ferruh.yigit@amd.com>
To: Ori Kam <orika@nvidia.com>,
dsosnowski@nvidia.com, cristian.dumitrescu@intel.com,
Thomas Monjalon <thomas@monjalon.net>,
Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
Cc: dev@dpdk.org, rasland@nvidia.com
Subject: Re: [RFC] ethdev: introduce entropy calculation
Date: Thu, 14 Dec 2023 11:34:39 +0000 [thread overview]
Message-ID: <7ec96599-6235-4ef5-9bba-6a037815d358@amd.com> (raw)
In-Reply-To: <20231210083100.7893-1-orika@nvidia.com>
On 12/10/2023 8:30 AM, 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.
>
Hi Ori,
Can you please provide more details what this 'entropy' is used for,
what is the usecase?
> 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.
>
So is this new API a datapath API? Is the intention that application
call this API per packet that is missing 'entropy' information?
> Signed-off-by: Ori Kam <orika@nvidia.com>
> ---
> 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,
> + /* 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.
> + * @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.
>
Is the size same as field size in the 'dest_field'?
Like for 'RTE_FLOW_ENTROPY_DEST_UDP_SRC_PORT' is it two bytes?
> + * @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
next prev parent reply other threads:[~2023-12-14 11:34 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-10 8:30 Ori Kam
2023-12-12 12:19 ` Dariusz Sosnowski
2023-12-14 11:34 ` Ferruh Yigit [this message]
2023-12-14 14:16 ` Ori Kam
2023-12-14 15:25 ` Dumitrescu, Cristian
2023-12-14 17:18 ` Ori Kam
2023-12-14 17:26 ` Stephen Hemminger
2023-12-15 13:44 ` Ferruh Yigit
2023-12-15 16:21 ` Thomas Monjalon
2023-12-16 9:03 ` Andrew Rybchenko
2023-12-27 15:20 ` Ori Kam
2024-01-04 12:57 ` Dumitrescu, Cristian
2024-01-04 14:33 ` Ori Kam
2024-01-04 18:18 ` Thomas Monjalon
2024-01-07 9:37 ` Ori Kam
2023-12-16 9:19 ` Andrew Rybchenko
2023-12-17 10:07 ` Ori Kam
2024-01-12 7:46 ` Andrew Rybchenko
2024-01-21 9:36 ` Ori Kam
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7ec96599-6235-4ef5-9bba-6a037815d358@amd.com \
--to=ferruh.yigit@amd.com \
--cc=andrew.rybchenko@oktetlabs.ru \
--cc=cristian.dumitrescu@intel.com \
--cc=dev@dpdk.org \
--cc=dsosnowski@nvidia.com \
--cc=orika@nvidia.com \
--cc=rasland@nvidia.com \
--cc=thomas@monjalon.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).