DPDK patches and discussions
 help / color / mirror / Atom feed
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


  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).