From: Ori Kam <orika@nvidia.com>
To: "ferruh.yigit@amd.com" <ferruh.yigit@amd.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>, Raslan Darawsheh <rasland@nvidia.com>
Subject: RE: [PATCH 1/4] ethdev: introduce encap hash calculation
Date: Thu, 1 Feb 2024 08:40:59 +0000 [thread overview]
Message-ID: <MW2PR12MB46662B9ED86D8C5CBB5B11A1D6432@MW2PR12MB4666.namprd12.prod.outlook.com> (raw)
In-Reply-To: <20240128093943.4461-2-orika@nvidia.com>
Hi Ferruh,
Can you please review my patch?
Thanks,
Ori
> -----Original Message-----
> From: Ori Kam <orika@nvidia.com>
> Sent: Sunday, January 28, 2024 11:40 AM
> To: Dariusz Sosnowski <dsosnowski@nvidia.com>; ferruh.yigit@amd.com;
>
> During the encapsulation of a packet, it is expected to calculate the
> hash value which is based on the original packet (the outer values,
> which will become the inner values).
>
> The tunnel protocol defines which tunnel field should hold this hash,
> but it doesn't define the hash calculation algorithm.
>
> An application that uses flow offloads gets the first few packets
> and then decides to offload the flow. As a result, there are two
> different paths that a packet from a given flow may take.
> SW for the first few packets or HW for the rest.
> When the packet goes through the SW, the SW encapsulates the packet
> and must use the same hash calculation as the HW will do for
> the rest of the packets in this flow.
>
> This patch gives the SW a way to query the hash value
> for a given packet as if the packet was passed through the HW.
>
> Signed-off-by: Ori Kam <orika@nvidia.com>
> ---
> doc/guides/prog_guide/rte_flow.rst | 22 ++++++++++++
> doc/guides/rel_notes/release_24_03.rst | 4 +++
> lib/ethdev/rte_flow.c | 25 +++++++++++++
> lib/ethdev/rte_flow.h | 50 ++++++++++++++++++++++++++
> lib/ethdev/rte_flow_driver.h | 5 +++
> lib/ethdev/version.map | 1 +
> 6 files changed, 107 insertions(+)
>
> diff --git a/doc/guides/prog_guide/rte_flow.rst
> b/doc/guides/prog_guide/rte_flow.rst
> index 900fdaefb6..0435dda3c7 100644
> --- a/doc/guides/prog_guide/rte_flow.rst
> +++ b/doc/guides/prog_guide/rte_flow.rst
> @@ -4211,6 +4211,28 @@ as it would be calculated in the HW.
> uint8_t pattern_template_index,
> uint32_t *hash, struct rte_flow_error
> *error);
>
> +Calculate encap hash
> +~~~~~~~~~~~~~~~~~~~~
> +
> +Calculating hash of a packet in SW as it would be calculated in HW for the
> encap action
> +
> +When the HW execute an encapsulation action, it may calculate an hash
> value which is based
> +on the original packet. This hash is stored depending on the encapsulation
> protocol, in one
> +of the outer fields.
> +
> +This function allows the application to calculate the hash for a given packet
> as if the
> +encapsulation was done in HW.
> +
> +.. code-block:: c
> +
> + int
> + rte_flow_calc_encap_hash(uint16_t port_id,
> + const struct rte_flow_item pattern[],
> + enum rte_flow_encap_hash_field
> dest_field,
> + uint8_t hash_len,
> + uint8_t *hash,
> + struct rte_flow_error *error);
> +
> .. _flow_isolated_mode:
>
> Flow isolated mode
> diff --git a/doc/guides/rel_notes/release_24_03.rst
> b/doc/guides/rel_notes/release_24_03.rst
> index 5e545da867..80af380172 100644
> --- a/doc/guides/rel_notes/release_24_03.rst
> +++ b/doc/guides/rel_notes/release_24_03.rst
> @@ -75,6 +75,10 @@ New Features
> * Added support for VXLAN-GPE matching in HW Steering flow engine
> (``dv_flow_en`` = 2).
>
> +* **Added ability to calculate the encap hash as done by HW.**
> +
> + * Added function that calculates the encap hash, as the HW calculates it:
> + ``rte_flow_calc_encap_hash()``
>
> Removed Items
> -------------
> diff --git a/lib/ethdev/rte_flow.c b/lib/ethdev/rte_flow.c
> index 3f58d792f9..7fce754be1 100644
> --- a/lib/ethdev/rte_flow.c
> +++ b/lib/ethdev/rte_flow.c
> @@ -2482,3 +2482,28 @@ rte_flow_calc_table_hash(uint16_t port_id, const
> struct rte_flow_template_table
> hash, error);
> return flow_err(port_id, ret, error);
> }
> +
> +int
> +rte_flow_calc_encap_hash(uint16_t port_id, const struct rte_flow_item
> pattern[],
> + enum rte_flow_encap_hash_field dest_field, uint8_t
> hash_len,
> + uint8_t *hash, struct rte_flow_error *error)
> +{
> + int ret;
> + struct rte_eth_dev *dev;
> + const struct rte_flow_ops *ops;
> +
> + RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
> + ops = rte_flow_ops_get(port_id, error);
> + if (!ops || !ops->flow_calc_encap_hash)
> + return rte_flow_error_set(error, ENOTSUP,
> +
> RTE_FLOW_ERROR_TYPE_UNSPECIFIED, NULL,
> + "calc encap hash is not supported");
> + if ((dest_field == RTE_FLOW_ENCAP_HASH_FIELD_SRC_PORT &&
> hash_len != 2) ||
> + (dest_field == RTE_FLOW_ENCAP_HASH_FIELD_NVGRE_FLOW_ID
> && hash_len != 1))
> + return rte_flow_error_set(error, EINVAL,
> +
> RTE_FLOW_ERROR_TYPE_UNSPECIFIED, NULL,
> + "hash len doesn't match the
> requested field len");
> + dev = &rte_eth_devices[port_id];
> + ret = ops->flow_calc_encap_hash(dev, pattern, dest_field, hash,
> error);
> + return flow_err(port_id, ret, error);
> +}
> diff --git a/lib/ethdev/rte_flow.h b/lib/ethdev/rte_flow.h
> index 1267c146e5..ffbde58245 100644
> --- a/lib/ethdev/rte_flow.h
> +++ b/lib/ethdev/rte_flow.h
> @@ -6783,6 +6783,56 @@ 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 hash calculation, when encap action is used.
> + *
> + * @see function rte_flow_calc_encap_hash
> + */
> +enum rte_flow_encap_hash_field {
> + /* Calculate hash placed in UDP source port field. */
> + RTE_FLOW_ENCAP_HASH_FIELD_SRC_PORT,
> + /* Calculate hash placed in NVGRE flow ID field. */
> + RTE_FLOW_ENCAP_HASH_FIELD_NVGRE_FLOW_ID,
> +};
> +
> +/**
> + * @warning
> + * @b EXPERIMENTAL: this API may change without prior notice.
> + *
> + * Simulates HW hash calculation that is done when encap action is being
> used.
> + *
> + * @param[in] port_id
> + * Port identifier of Ethernet device.
> + * @param[in] pattern
> + * The values to be used in the hash calculation.
> + * @param[in] dest_field
> + * Type of destination field for hash calculation.
> + * @param[in] hash_len
> + * The length of the hash pointer in bytes. Should be according to
> encap_hash_field.
> + * @param[out] hash
> + * Used to return the calculated hash. It will be written in network order,
> + * so hash[0] is the MSB.
> + * The number of bytes is based on the destination field type.
> + * @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
> hash
> + * or the dest is not supported.
> + */
> +__rte_experimental
> +int
> +rte_flow_calc_encap_hash(uint16_t port_id, const struct rte_flow_item
> pattern[],
> + enum rte_flow_encap_hash_field dest_field, uint8_t
> hash_len,
> + uint8_t *hash, struct rte_flow_error *error);
> +
> #ifdef __cplusplus
> }
> #endif
> diff --git a/lib/ethdev/rte_flow_driver.h b/lib/ethdev/rte_flow_driver.h
> index f35f659503..447163655a 100644
> --- a/lib/ethdev/rte_flow_driver.h
> +++ b/lib/ethdev/rte_flow_driver.h
> @@ -370,6 +370,11 @@ struct rte_flow_ops {
> (struct rte_eth_dev *dev, const struct
> rte_flow_template_table *table,
> const struct rte_flow_item pattern[], uint8_t
> pattern_template_index,
> uint32_t *hash, struct rte_flow_error *error);
> + /** @see rte_flow_calc_encap_hash() */
> + int (*flow_calc_encap_hash)
> + (struct rte_eth_dev *dev, const struct rte_flow_item
> pattern[],
> + enum rte_flow_encap_hash_field dest_field, uint8_t *hash,
> + struct rte_flow_error *error);
> };
>
> /**
> diff --git a/lib/ethdev/version.map b/lib/ethdev/version.map
> index a050baab0f..360898d067 100644
> --- a/lib/ethdev/version.map
> +++ b/lib/ethdev/version.map
> @@ -319,6 +319,7 @@ EXPERIMENTAL {
>
> # added in 24.03
> rte_eth_find_rss_algo;
> + rte_flow_calc_encap_hash;
> };
>
> INTERNAL {
> --
> 2.34.1
next prev parent reply other threads:[~2024-02-01 8:41 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-28 9:39 [PATCH 0/4] " Ori Kam
2024-01-28 9:39 ` [PATCH 1/4] ethdev: " Ori Kam
2024-02-01 8:40 ` Ori Kam [this message]
2024-02-06 22:39 ` Thomas Monjalon
2024-02-07 6:56 ` Ori Kam
2024-02-07 9:25 ` Thomas Monjalon
2024-01-28 9:39 ` [PATCH 2/4] net/mlx5/hws: introduce encap entropy hash calculation API Ori Kam
2024-01-28 9:39 ` [PATCH 3/4] net/mlx5: add calc encap hash support Ori Kam
2024-01-28 9:39 ` [PATCH 4/4] app/testpmd: add encap hash calculation Ori Kam
2024-01-31 18:30 ` [PATCH 0/4] introduce " Dariusz Sosnowski
2024-02-08 9:09 ` [PATCH v2 1/4] ethdev: " Ori Kam
2024-02-08 9:09 ` [PATCH v2 2/4] net/mlx5/hws: introduce encap entropy hash calculation API Ori Kam
2024-02-08 9:09 ` [PATCH v2 3/4] net/mlx5: add calc encap hash support Ori Kam
2024-02-08 9:09 ` [PATCH v2 4/4] app/testpmd: add encap hash calculation Ori Kam
2024-02-08 17:13 ` [PATCH v2 1/4] ethdev: introduce " Ferruh Yigit
2024-02-11 7:29 ` Ori Kam
2024-02-12 17:05 ` Ferruh Yigit
2024-02-12 18:44 ` Ori Kam
2024-02-12 20:09 ` Ferruh Yigit
2024-02-13 7:05 ` Ori Kam
2024-02-13 13:48 ` [PATCH v3 " Ori Kam
2024-02-13 13:48 ` [PATCH v3 2/4] net/mlx5/hws: introduce encap entropy hash calculation API Ori Kam
2024-02-13 13:48 ` [PATCH v3 3/4] net/mlx5: add calc encap hash support Ori Kam
2024-02-13 13:48 ` [PATCH v3 4/4] app/testpmd: add encap hash calculation Ori Kam
2024-02-13 14:16 ` [PATCH v4 1/4] ethdev: introduce " Ori Kam
2024-02-13 14:16 ` [PATCH v4 2/4] net/mlx5/hws: introduce encap entropy hash calculation API Ori Kam
2024-02-13 14:16 ` [PATCH v4 3/4] net/mlx5: add calc encap hash support Ori Kam
2024-02-13 14:16 ` [PATCH v4 4/4] app/testpmd: add encap hash calculation Ori Kam
2024-02-13 15:45 ` Ferruh Yigit
2024-02-13 15:45 ` [PATCH v4 1/4] ethdev: introduce " Ferruh Yigit
2024-02-13 15:45 ` Ferruh Yigit
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=MW2PR12MB46662B9ED86D8C5CBB5B11A1D6432@MW2PR12MB4666.namprd12.prod.outlook.com \
--to=orika@nvidia.com \
--cc=dev@dpdk.org \
--cc=ferruh.yigit@amd.com \
--cc=rasland@nvidia.com \
/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).