DPDK patches and discussions
 help / color / mirror / Atom feed
From: Ori Kam <orika@nvidia.com>
To: <dsosnowski@nvidia.com>, <ferruh.yigit@amd.com>,
	<cristian.dumitrescu@intel.com>, <andrew.rybchenko@oktetlabs.ru>,
	<stephen@networkplumber.org>,
	Thomas Monjalon <thomas@monjalon.net>
Cc: <dev@dpdk.org>, <orika@nvidia.com>, <rasland@nvidia.com>
Subject: [PATCH v4 1/4] ethdev: introduce encap hash calculation
Date: Tue, 13 Feb 2024 16:16:37 +0200	[thread overview]
Message-ID: <20240213141640.19812-1-orika@nvidia.com> (raw)
In-Reply-To: <20240128093943.4461-1-orika@nvidia.com>

During encapsulation of a packet, it is possible to change some
outer headers to improve flow destribution.
For example, from VXLAN RFC:
"It is recommended that the UDP source port number
be calculated using a hash of fields from the inner packet --
one example being a hash of the inner Ethernet frame's headers.
This is to enable a level of entropy for the ECMP/load-balancing"

The tunnel protocol defines which outer 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
(exception path) 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.

the new function rte_flow_calc_encap_hash can query the hash value
from the driver for a given packet as if the packet was passed
through the HW.

Signed-off-by: Ori Kam <orika@nvidia.com>
Acked-by: Dariusz Sosnowski <dsosnowski@nvidia.com>
---
 doc/guides/prog_guide/rte_flow.rst     | 14 +++++++
 doc/guides/rel_notes/release_24_03.rst |  6 ++-
 lib/ethdev/rte_flow.c                  | 29 ++++++++++++++
 lib/ethdev/rte_flow.h                  | 53 ++++++++++++++++++++++++++
 lib/ethdev/rte_flow_driver.h           |  5 +++
 lib/ethdev/version.map                 |  1 +
 6 files changed, 107 insertions(+), 1 deletion(-)

diff --git a/doc/guides/prog_guide/rte_flow.rst b/doc/guides/prog_guide/rte_flow.rst
index 34dc06ec66..294862d502 100644
--- a/doc/guides/prog_guide/rte_flow.rst
+++ b/doc/guides/prog_guide/rte_flow.rst
@@ -4226,6 +4226,20 @@ as it would be calculated in the HW.
                             uint8_t pattern_template_index,
 			                   uint32_t *hash, struct rte_flow_error *error);
 
+Calculate encapsulation hash
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Calculating hash of a packet as it would be calculated by the HW, when encapsulating
+a packet.
+
+When the HW execute an encapsulation action, for example VXLAN tunnel,
+it may calculate an hash of the packet to be encapsulated.
+This hash is stored in the outer header of the tunnel.
+This allow better spreading of traffic.
+
+This function can be used for packets of a flow that are not offloaded and
+pass through the SW instead of the HW, for example, SYN/FIN packets.
+
 .. _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 358998e988..cf114ead89 100644
--- a/doc/guides/rel_notes/release_24_03.rst
+++ b/doc/guides/rel_notes/release_24_03.rst
@@ -60,6 +60,11 @@ New Features
   * Added new function ``rte_eth_find_rss_algo`` to get RSS hash
     algorithm by its name.
 
+* **Added hash calculation of an encapsulated packet as done by the HW.**
+
+  Added function to calculate hash when doing tunnel encapsulation:
+  ``rte_flow_calc_encap_hash()``
+
 * **Added flow matching of random value.**
 
   * Added ``RTE_FLOW_ITEM_TYPE_RANDOM`` to match random value.
@@ -102,7 +107,6 @@ New Features
   * Added HW steering support for modify field ``RTE_FLOW_FIELD_GENEVE_OPT_CLASS`` flow action.
   * Added HW steering support for modify field ``RTE_FLOW_FIELD_GENEVE_OPT_DATA`` flow action.
 
-
 Removed Items
 -------------
 
diff --git a/lib/ethdev/rte_flow.c b/lib/ethdev/rte_flow.c
index b06da0cc00..7a4f7a94f6 100644
--- a/lib/ethdev/rte_flow.c
+++ b/lib/ethdev/rte_flow.c
@@ -2484,3 +2484,32 @@ 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_NVGRE_FLOW_ID)
+		return rte_flow_error_set(error, EINVAL,
+					  RTE_FLOW_ERROR_TYPE_UNSPECIFIED, NULL,
+					  "hash dest field is not defined");
+	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 09c1b13381..48e4f47844 100644
--- a/lib/ethdev/rte_flow.h
+++ b/lib/ethdev/rte_flow.h
@@ -6846,6 +6846,59 @@ 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.
+ * The encap field implies the size, meaning XXX_SRC_PORT hash len is 2 bytes,
+ * while XXX_NVGRE_FLOW_ID hash len is 1 byte.
+ *
+ * @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.
+ *
+ * Simulate HW hash calculation that is done when an encap action is being used.
+ * This hash can be stored in tunnel outer header to improve packet distribution.
+ *
+ * @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 dest_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


  parent reply	other threads:[~2024-02-13 14:17 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
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 ` Ori Kam [this message]
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=20240213141640.19812-1-orika@nvidia.com \
    --to=orika@nvidia.com \
    --cc=andrew.rybchenko@oktetlabs.ru \
    --cc=cristian.dumitrescu@intel.com \
    --cc=dev@dpdk.org \
    --cc=dsosnowski@nvidia.com \
    --cc=ferruh.yigit@amd.com \
    --cc=rasland@nvidia.com \
    --cc=stephen@networkplumber.org \
    --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).