ethdev: add calculate hash function

Message ID 20230926113753.28765-1-orika@nvidia.com (mailing list archive)
State Changes Requested, archived
Delegated to: Ferruh Yigit
Headers
Series ethdev: add calculate hash function |

Checks

Context Check Description
ci/checkpatch warning coding style issues
ci/loongarch-compilation success Compilation OK
ci/loongarch-unit-testing success Unit Testing PASS
ci/github-robot: build success github build: passed
ci/iol-mellanox-Performance success Performance Testing PASS
ci/iol-broadcom-Functional success Functional Testing PASS
ci/iol-broadcom-Performance success Performance Testing PASS
ci/iol-compile-amd64-testing success Testing PASS
ci/iol-unit-arm64-testing success Testing PASS
ci/iol-compile-arm64-testing success Testing PASS
ci/iol-unit-amd64-testing success Testing PASS
ci/iol-intel-Performance success Performance Testing PASS
ci/iol-intel-Functional success Functional Testing PASS
ci/iol-sample-apps-testing success Testing PASS
ci/Intel-compilation success Compilation OK
ci/intel-Testing success Testing PASS
ci/intel-Functional success Functional PASS

Commit Message

Ori Kam Sept. 26, 2023, 11:37 a.m. UTC
  rte_flow supports insert by index table[1].

Using the above table, the application can create rules
that are based on hash.
For example application can create the following logic in order
to create load balancing:
1. Create insert by index table with 2 rules, that hashes based on dmac
2. Insert to index 0 a rule that sends the traffic to port A.
3. Insert to index 1 a rule that sends the traffic to port B.

Let's also assume that before this table, there is a 5 tuple
match table that jumps to the above table.

So each packet that matches one of the 5 tuple rules is RSSed
to port A or B, based on dmac hash.

The issue arises when there is a miss on the 5 tuple table,
which resulted due to the packet being the first packet of this flow, or
fragmented packet or any other reason.
In this case, the application must calculate what would be the
hash calculated by the HW so it can send the packet to the correct
port.

This new API allows applications to calculate the hash value of a given
packet for a given table.

[1] - http://patches.dpdk.org/project/dpdk/patch/20230208030624.78465-2-akozyrev@nvidia.com/

Signed-off-by: Ori Kam <orika@nvidia.com>
---
 app/test-pmd/cmdline_flow.c  | 86 +++++++++++++++++++++++++++++++++++-
 app/test-pmd/config.c        | 54 ++++++++++++++++++++++
 app/test-pmd/testpmd.h       |  2 +
 lib/ethdev/rte_flow.c        | 21 +++++++++
 lib/ethdev/rte_flow.h        | 32 ++++++++++++++
 lib/ethdev/rte_flow_driver.h |  5 +++
 lib/ethdev/version.map       |  1 +
 7 files changed, 200 insertions(+), 1 deletion(-)
  

Comments

Dariusz Sosnowski Oct. 9, 2023, 8:15 a.m. UTC | #1
Hi,

> -----Original Message-----
> From: Ori Kam <orika@nvidia.com>
> Sent: Tuesday, September 26, 2023 13:38
> To: cristian.dumitrescu@intel.com; Aman Singh
> <aman.deep.singh@intel.com>; Yuying Zhang <yuying.zhang@intel.com>;
> NBU-Contact-Thomas Monjalon (EXTERNAL) <thomas@monjalon.net>;
> Ferruh Yigit <ferruh.yigit@amd.com>; Andrew Rybchenko
> <andrew.rybchenko@oktetlabs.ru>
> Cc: dev@dpdk.org; Ori Kam <orika@nvidia.com>; Raslan Darawsheh
> <rasland@nvidia.com>
> Subject: [PATCH] ethdev: add calculate hash function
> 
> External email: Use caution opening links or attachments
> 
> 
> rte_flow supports insert by index table[1].
> 
> Using the above table, the application can create rules that are based on hash.
> For example application can create the following logic in order to create load
> balancing:
> 1. Create insert by index table with 2 rules, that hashes based on dmac 2.
> Insert to index 0 a rule that sends the traffic to port A.
> 3. Insert to index 1 a rule that sends the traffic to port B.
> 
> Let's also assume that before this table, there is a 5 tuple match table that
> jumps to the above table.
> 
> So each packet that matches one of the 5 tuple rules is RSSed to port A or B,
> based on dmac hash.
> 
> The issue arises when there is a miss on the 5 tuple table, which resulted due
> to the packet being the first packet of this flow, or fragmented packet or any
> other reason.
> In this case, the application must calculate what would be the hash calculated
> by the HW so it can send the packet to the correct port.
> 
> This new API allows applications to calculate the hash value of a given packet
> for a given table.
> 
> [1] -
> http://patches.dpdk.org/project/dpdk/patch/20230208030624.78465-2-
> akozyrev@nvidia.com/
> 
> Signed-off-by: Ori Kam <orika@nvidia.com>
Acked-by: Dariusz Sosnowski <dsosnowski@nvidia.com>

Thanks,
Dariusz Sosnowski
  
Ferruh Yigit Oct. 10, 2023, 11:05 a.m. UTC | #2
On 9/26/2023 12:37 PM, Ori Kam wrote:
> rte_flow supports insert by index table[1].
> 
> Using the above table, the application can create rules
> that are based on hash.
> For example application can create the following logic in order
> to create load balancing:
> 1. Create insert by index table with 2 rules, that hashes based on dmac
> 2. Insert to index 0 a rule that sends the traffic to port A.
> 3. Insert to index 1 a rule that sends the traffic to port B.
> 
> Let's also assume that before this table, there is a 5 tuple
> match table that jumps to the above table.
> 
> So each packet that matches one of the 5 tuple rules is RSSed
> to port A or B, based on dmac hash.
> 
> The issue arises when there is a miss on the 5 tuple table,
> which resulted due to the packet being the first packet of this flow, or
> fragmented packet or any other reason.
> In this case, the application must calculate what would be the
> hash calculated by the HW so it can send the packet to the correct
> port.
> 
> This new API allows applications to calculate the hash value of a given
> packet for a given table.
> 
> [1] - http://patches.dpdk.org/project/dpdk/patch/20230208030624.78465-2-akozyrev@nvidia.com/
> 
> Signed-off-by: Ori Kam <orika@nvidia.com>
> ---
>  app/test-pmd/cmdline_flow.c  | 86 +++++++++++++++++++++++++++++++++++-
>  app/test-pmd/config.c        | 54 ++++++++++++++++++++++
>  app/test-pmd/testpmd.h       |  2 +
>  lib/ethdev/rte_flow.c        | 21 +++++++++
>  lib/ethdev/rte_flow.h        | 32 ++++++++++++++
>  lib/ethdev/rte_flow_driver.h |  5 +++
>  lib/ethdev/version.map       |  1 +
>  7 files changed, 200 insertions(+), 1 deletion(-)
> 

This is a new rte_flow API but unfortunately there isn't any
review/comment, at least it is experimental API. If there is no
objection/discussion in next few days, I will merge the feature.

Probably it will be another rte flow feature that only NVIDIA knows and
uses. While mentioned from using, is the driver update for the feature
planned for this release?


Meanwhile, can you please update the documentation, `rte_flow.rst` and
`testpmd_funcs.rst`?
Also can you please rebase on top of latest next-net, this patch
conflicts with merged group set miss action feature.
  
Ori Kam Oct. 10, 2023, 11:42 a.m. UTC | #3
Hi Ferruh,

> -----Original Message-----
> From: Ferruh Yigit <ferruh.yigit@amd.com>
> Sent: Tuesday, October 10, 2023 2:06 PM
> 
> On 9/26/2023 12:37 PM, Ori Kam wrote:
> > rte_flow supports insert by index table[1].
> >
> > Using the above table, the application can create rules
> > that are based on hash.
> > For example application can create the following logic in order
> > to create load balancing:
> > 1. Create insert by index table with 2 rules, that hashes based on dmac
> > 2. Insert to index 0 a rule that sends the traffic to port A.
> > 3. Insert to index 1 a rule that sends the traffic to port B.
> >
> > Let's also assume that before this table, there is a 5 tuple
> > match table that jumps to the above table.
> >
> > So each packet that matches one of the 5 tuple rules is RSSed
> > to port A or B, based on dmac hash.
> >
> > The issue arises when there is a miss on the 5 tuple table,
> > which resulted due to the packet being the first packet of this flow, or
> > fragmented packet or any other reason.
> > In this case, the application must calculate what would be the
> > hash calculated by the HW so it can send the packet to the correct
> > port.
> >
> > This new API allows applications to calculate the hash value of a given
> > packet for a given table.
> >
> > [1] - http://patches.dpdk.org/project/dpdk/patch/20230208030624.78465-2-
> akozyrev@nvidia.com/
> >
> > Signed-off-by: Ori Kam <orika@nvidia.com>
> > ---
> >  app/test-pmd/cmdline_flow.c  | 86
> +++++++++++++++++++++++++++++++++++-
> >  app/test-pmd/config.c        | 54 ++++++++++++++++++++++
> >  app/test-pmd/testpmd.h       |  2 +
> >  lib/ethdev/rte_flow.c        | 21 +++++++++
> >  lib/ethdev/rte_flow.h        | 32 ++++++++++++++
> >  lib/ethdev/rte_flow_driver.h |  5 +++
> >  lib/ethdev/version.map       |  1 +
> >  7 files changed, 200 insertions(+), 1 deletion(-)
> >
> 
> This is a new rte_flow API but unfortunately there isn't any
> review/comment, at least it is experimental API. If there is no
> objection/discussion in next few days, I will merge the feature.
> 

Thanks,

> Probably it will be another rte flow feature that only NVIDIA knows and
> uses. While mentioned from using, is the driver update for the feature
> planned for this release?
>

Yes, I hope to send the mlx5 patches in a few days. 
 
> 
> Meanwhile, can you please update the documentation, `rte_flow.rst` and
> `testpmd_funcs.rst`?
> Also can you please rebase on top of latest next-net, this patch
> conflicts with merged group set miss action feature.

Sure
  
fengchengwen Oct. 11, 2023, 2:11 a.m. UTC | #4
Hi,

On 2023/10/10 19:05, Ferruh Yigit wrote:
> On 9/26/2023 12:37 PM, Ori Kam wrote:
>> rte_flow supports insert by index table[1].
>>
>> Using the above table, the application can create rules
>> that are based on hash.
>> For example application can create the following logic in order
>> to create load balancing:
>> 1. Create insert by index table with 2 rules, that hashes based on dmac
>> 2. Insert to index 0 a rule that sends the traffic to port A.
>> 3. Insert to index 1 a rule that sends the traffic to port B.
>>
>> Let's also assume that before this table, there is a 5 tuple
>> match table that jumps to the above table.
>>
>> So each packet that matches one of the 5 tuple rules is RSSed
>> to port A or B, based on dmac hash.
>>
>> The issue arises when there is a miss on the 5 tuple table,
>> which resulted due to the packet being the first packet of this flow, or
>> fragmented packet or any other reason.
>> In this case, the application must calculate what would be the
>> hash calculated by the HW so it can send the packet to the correct
>> port.
>>
>> This new API allows applications to calculate the hash value of a given
>> packet for a given table.
>>
>> [1] - http://patches.dpdk.org/project/dpdk/patch/20230208030624.78465-2-akozyrev@nvidia.com/
>>
>> Signed-off-by: Ori Kam <orika@nvidia.com>
>> ---
>>  app/test-pmd/cmdline_flow.c  | 86 +++++++++++++++++++++++++++++++++++-
>>  app/test-pmd/config.c        | 54 ++++++++++++++++++++++
>>  app/test-pmd/testpmd.h       |  2 +
>>  lib/ethdev/rte_flow.c        | 21 +++++++++
>>  lib/ethdev/rte_flow.h        | 32 ++++++++++++++
>>  lib/ethdev/rte_flow_driver.h |  5 +++
>>  lib/ethdev/version.map       |  1 +
>>  7 files changed, 200 insertions(+), 1 deletion(-)
>>
> 
> This is a new rte_flow API but unfortunately there isn't any
> review/comment, at least it is experimental API. If there is no
> objection/discussion in next few days, I will merge the feature.
> 
> Probably it will be another rte flow feature that only NVIDIA knows and
> uses. While mentioned from using, is the driver update for the feature

The hns3 driver support subset of rte_flow, we found the rte_flow feature is very flexible.
And its implementation varies according to vendors.

Can the rte_flow be standardized ?

> planned for this release?
> 
> 
> Meanwhile, can you please update the documentation, `rte_flow.rst` and
> `testpmd_funcs.rst`?
> Also can you please rebase on top of latest next-net, this patch
> conflicts with merged group set miss action feature.
> 
> .
>
  
Ferruh Yigit Oct. 11, 2023, 8:34 a.m. UTC | #5
On 10/11/2023 3:11 AM, fengchengwen wrote:
> Hi,
> 
> On 2023/10/10 19:05, Ferruh Yigit wrote:
>> On 9/26/2023 12:37 PM, Ori Kam wrote:
>>> rte_flow supports insert by index table[1].
>>>
>>> Using the above table, the application can create rules
>>> that are based on hash.
>>> For example application can create the following logic in order
>>> to create load balancing:
>>> 1. Create insert by index table with 2 rules, that hashes based on dmac
>>> 2. Insert to index 0 a rule that sends the traffic to port A.
>>> 3. Insert to index 1 a rule that sends the traffic to port B.
>>>
>>> Let's also assume that before this table, there is a 5 tuple
>>> match table that jumps to the above table.
>>>
>>> So each packet that matches one of the 5 tuple rules is RSSed
>>> to port A or B, based on dmac hash.
>>>
>>> The issue arises when there is a miss on the 5 tuple table,
>>> which resulted due to the packet being the first packet of this flow, or
>>> fragmented packet or any other reason.
>>> In this case, the application must calculate what would be the
>>> hash calculated by the HW so it can send the packet to the correct
>>> port.
>>>
>>> This new API allows applications to calculate the hash value of a given
>>> packet for a given table.
>>>
>>> [1] - http://patches.dpdk.org/project/dpdk/patch/20230208030624.78465-2-akozyrev@nvidia.com/
>>>
>>> Signed-off-by: Ori Kam <orika@nvidia.com>
>>> ---
>>>  app/test-pmd/cmdline_flow.c  | 86 +++++++++++++++++++++++++++++++++++-
>>>  app/test-pmd/config.c        | 54 ++++++++++++++++++++++
>>>  app/test-pmd/testpmd.h       |  2 +
>>>  lib/ethdev/rte_flow.c        | 21 +++++++++
>>>  lib/ethdev/rte_flow.h        | 32 ++++++++++++++
>>>  lib/ethdev/rte_flow_driver.h |  5 +++
>>>  lib/ethdev/version.map       |  1 +
>>>  7 files changed, 200 insertions(+), 1 deletion(-)
>>>
>>
>> This is a new rte_flow API but unfortunately there isn't any
>> review/comment, at least it is experimental API. If there is no
>> objection/discussion in next few days, I will merge the feature.
>>
>> Probably it will be another rte flow feature that only NVIDIA knows and
>> uses. While mentioned from using, is the driver update for the feature
> 
> The hns3 driver support subset of rte_flow, we found the rte_flow feature is very flexible.
> And its implementation varies according to vendors.
> 
> Can the rte_flow be standardized ?
> 

Hi Chengwen,

Yes rte_flow is already implemented by many vendors, each uses some
subset of it. It is flexible and useful, no concern about it.

My point was, most of the new rte_flow features are coming from single
vendor and most of them are not fully reviewed by the wider community.

As some of the features merged without much review from wider community,
not everyone aware of them, and features are not fully benefited from,
although that is somewhat related to HW support as Jerin pointed before.


As hns3 is a user of the rte_flow already, it would be great to get more
feedback and review from hns3 maintainers, that boosts the confidence to
the new proposed features/APIs.


Thanks,
ferruh


>> planned for this release?
>>
>>
>> Meanwhile, can you please update the documentation, `rte_flow.rst` and
>> `testpmd_funcs.rst`?
>> Also can you please rebase on top of latest next-net, this patch
>> conflicts with merged group set miss action feature.
>>
>> .
>>
  

Patch

diff --git a/app/test-pmd/cmdline_flow.c b/app/test-pmd/cmdline_flow.c
index 94827bcc4a..e1e4bb49fa 100644
--- a/app/test-pmd/cmdline_flow.c
+++ b/app/test-pmd/cmdline_flow.c
@@ -101,6 +101,7 @@  enum index {
 	QUEUE,
 	PUSH,
 	PULL,
+	HASH,
 
 	/* Flex arguments */
 	FLEX_ITEM_INIT,
@@ -206,6 +207,11 @@  enum index {
 	TABLE_PATTERN_TEMPLATE,
 	TABLE_ACTIONS_TEMPLATE,
 
+	/* Hash calculation arguments. */
+	HASH_CALC_TABLE,
+	HASH_CALC_PATTERN_INDEX,
+	HASH_CALC_PATTERN,
+
 	/* Tunnel arguments. */
 	TUNNEL_CREATE,
 	TUNNEL_CREATE_TYPE,
@@ -2678,6 +2684,9 @@  static int parse_push(struct context *, const struct token *,
 static int parse_pull(struct context *, const struct token *,
 		      const char *, unsigned int,
 		      void *, unsigned int);
+static int parse_hash(struct context *, const struct token *,
+		      const char *, unsigned int,
+		      void *, unsigned int);
 static int parse_tunnel(struct context *, const struct token *,
 			const char *, unsigned int,
 			void *, unsigned int);
@@ -3035,7 +3044,8 @@  static const struct token token_list[] = {
 			      FLEX,
 			      QUEUE,
 			      PUSH,
-			      PULL)),
+			      PULL,
+			      HASH)),
 		.call = parse_init,
 	},
 	/* Top-level command. */
@@ -3680,6 +3690,33 @@  static const struct token token_list[] = {
 		.args = ARGS(ARGS_ENTRY(struct buffer, queue)),
 	},
 	/* Top-level command. */
+	[HASH] = {
+		.name = "hash",
+		.help = "calculate hash for a given pattern in a given template table",
+		.next = NEXT(NEXT_ENTRY(HASH_CALC_TABLE), NEXT_ENTRY(COMMON_PORT_ID)),
+		.args = ARGS(ARGS_ENTRY(struct buffer, port)),
+		.call = parse_hash,
+	},
+	/* Sub-level commands. */
+	[HASH_CALC_TABLE] = {
+		.name = "template_table",
+		.help = "specify table id",
+		.next = NEXT(NEXT_ENTRY(HASH_CALC_PATTERN_INDEX),
+			     NEXT_ENTRY(COMMON_TABLE_ID)),
+		.args = ARGS(ARGS_ENTRY(struct buffer,
+					args.vc.table_id)),
+		.call = parse_hash,
+	},
+	[HASH_CALC_PATTERN_INDEX] = {
+		.name = "pattern_template",
+		.help = "specify pattern template id",
+		.next = NEXT(NEXT_ENTRY(ITEM_PATTERN),
+			     NEXT_ENTRY(COMMON_UNSIGNED)),
+		.args = ARGS(ARGS_ENTRY(struct buffer,
+					args.vc.pat_templ_id)),
+		.call = parse_hash,
+	},
+	/* Top-level command. */
 	[INDIRECT_ACTION] = {
 		.name = "indirect_action",
 		.type = "{command} {port_id} [{arg} [...]]",
@@ -10449,6 +10486,48 @@  parse_pull(struct context *ctx, const struct token *token,
 	return len;
 }
 
+/** Parse tokens for hash calculation commands. */
+static int
+parse_hash(struct context *ctx, const struct token *token,
+	 const char *str, unsigned int len,
+	 void *buf, unsigned int size)
+{
+	struct buffer *out = buf;
+
+	/* Token name must match. */
+	if (parse_default(ctx, token, str, len, NULL, 0) < 0)
+		return -1;
+	/* Nothing else to do if there is no buffer. */
+	if (!out)
+		return len;
+	if (!out->command) {
+		if (ctx->curr != HASH)
+			return -1;
+		if (sizeof(*out) > size)
+			return -1;
+		out->command = ctx->curr;
+		ctx->objdata = 0;
+		ctx->object = out;
+		ctx->objmask = NULL;
+		out->args.vc.data = (uint8_t *)out + size;
+		return len;
+	}
+	switch (ctx->curr) {
+	case HASH_CALC_TABLE:
+	case HASH_CALC_PATTERN_INDEX:
+		return len;
+	case ITEM_PATTERN:
+		out->args.vc.pattern =
+			(void *)RTE_ALIGN_CEIL((uintptr_t)(out + 1),
+					       sizeof(double));
+		ctx->object = out->args.vc.pattern;
+		ctx->objmask = NULL;
+		return len;
+	default:
+		return -1;
+	}
+}
+
 static int
 parse_flex(struct context *ctx, const struct token *token,
 	     const char *str, unsigned int len,
@@ -12351,6 +12430,11 @@  cmd_flow_parsed(const struct buffer *in)
 	case PULL:
 		port_queue_flow_pull(in->port, in->queue);
 		break;
+	case HASH:
+		port_flow_hash_calc(in->port, in->args.vc.table_id,
+				    in->args.vc.pat_templ_id,
+				    in->args.vc.pattern);
+		break;
 	case QUEUE_AGED:
 		port_queue_flow_aged(in->port, in->queue,
 				     in->args.aged.destroy);
diff --git a/app/test-pmd/config.c b/app/test-pmd/config.c
index 11f3a22048..c244f1a071 100644
--- a/app/test-pmd/config.c
+++ b/app/test-pmd/config.c
@@ -6,6 +6,7 @@ 
 #include <ctype.h>
 #include <stdarg.h>
 #include <errno.h>
+#include <stdbool.h>
 #include <stdio.h>
 #include <stdlib.h>
 #include <string.h>
@@ -3301,6 +3302,59 @@  port_queue_flow_push(portid_t port_id, queueid_t queue_id)
 	return ret;
 }
 
+/** Calculate the hash result for a given pattern in a given table. */
+int
+port_flow_hash_calc(portid_t port_id, uint32_t table_id,
+		    uint8_t pattern_template_index, const struct rte_flow_item pattern[])
+{
+	uint32_t hash;
+	bool found;
+	struct port_table *pt;
+	struct rte_port *port;
+	struct rte_flow_error error;
+	int ret = 0;
+
+	if (port_id_is_invalid(port_id, ENABLED_WARN) ||
+	    port_id == (portid_t)RTE_PORT_ALL)
+		return -EINVAL;
+	port = &ports[port_id];
+
+	found = false;
+	pt = port->table_list;
+	while (pt) {
+		if (table_id == pt->id) {
+			found = true;
+			break;
+		}
+		pt = pt->next;
+	}
+	if (!found) {
+		printf("Table #%u is invalid\n", table_id);
+		return -EINVAL;
+	}
+
+	memset(&error, 0x55, sizeof(error));
+	ret = rte_flow_calc_table_hash(port_id, pt->table, pattern,
+				       pattern_template_index, &hash, &error);
+	if (ret < 0) {
+		printf("Failed to calculate hash ");
+		switch (abs(ret)) {
+		case ENODEV:
+			printf("no such device\n");
+			break;
+		case ENOTSUP:
+			printf("device doesn't support this operation\n");
+			break;
+		default:
+			printf("\n");
+			break;
+		}
+		return ret;
+	}
+	printf("Hash results 0x%x\n", hash);
+	return 0;
+}
+
 /** Pull queue operation results from the queue. */
 static int
 port_queue_aged_flow_destroy(portid_t port_id, queueid_t queue_id,
diff --git a/app/test-pmd/testpmd.h b/app/test-pmd/testpmd.h
index f1df6a8faf..4637a47c06 100644
--- a/app/test-pmd/testpmd.h
+++ b/app/test-pmd/testpmd.h
@@ -1009,6 +1009,8 @@  port_queue_action_handle_query_update(portid_t port_id,
 				      const struct rte_flow_action *action);
 int port_queue_flow_push(portid_t port_id, queueid_t queue_id);
 int port_queue_flow_pull(portid_t port_id, queueid_t queue_id);
+int port_flow_hash_calc(portid_t port_id, uint32_t table_id,
+			uint8_t pattern_template_index, const struct rte_flow_item pattern[]);
 void port_queue_flow_aged(portid_t port_id, uint32_t queue_id, uint8_t destroy);
 int port_flow_validate(portid_t port_id,
 		       const struct rte_flow_attr *attr,
diff --git a/lib/ethdev/rte_flow.c b/lib/ethdev/rte_flow.c
index 271d854f78..5f7dcdfdad 100644
--- a/lib/ethdev/rte_flow.c
+++ b/lib/ethdev/rte_flow.c
@@ -2431,3 +2431,24 @@  rte_flow_async_action_list_handle_query_update(uint16_t port_id, uint32_t queue_
 							     ret);
 	return ret;
 }
+
+int
+rte_flow_calc_table_hash(uint16_t port_id, 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)
+{
+	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_table_hash)
+		return rte_flow_error_set(error, ENOTSUP,
+					  RTE_FLOW_ERROR_TYPE_UNSPECIFIED, NULL,
+					  "action_list async query_update not supported");
+	dev = &rte_eth_devices[port_id];
+	ret = ops->flow_calc_table_hash(dev, table, pattern, pattern_template_index,
+					hash, error);
+	return flow_err(port_id, ret, error);
+}
diff --git a/lib/ethdev/rte_flow.h b/lib/ethdev/rte_flow.h
index 23addb4382..b8c28394a1 100644
--- a/lib/ethdev/rte_flow.h
+++ b/lib/ethdev/rte_flow.h
@@ -6624,6 +6624,38 @@  rte_flow_async_action_list_handle_query_update(uint16_t port_id, uint32_t queue_
 					  void *user_data,
 					  struct rte_flow_error *error);
 
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change without prior notice.
+ *
+ * Calculate the hash for a given pattern in a given table as
+ * calculated by the HW.
+ *
+ * @param port_id
+ *   Port identifier of Ethernet device.
+ * @param table
+ *   The table the SW wishes to simulate.
+ * @param pattern
+ *   The values to be used in the hash calculation.
+ * @param pattern_template_index
+ *   The pattern index in the table to be used for the calculation.
+ * @param hash
+ *   Used to return the calculated hash.
+ * @param 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.
+ */
+__rte_experimental
+int
+rte_flow_calc_table_hash(uint16_t port_id, 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);
+
 #ifdef __cplusplus
 }
 #endif
diff --git a/lib/ethdev/rte_flow_driver.h b/lib/ethdev/rte_flow_driver.h
index f9fb01b8a2..aa8635b1a8 100644
--- a/lib/ethdev/rte_flow_driver.h
+++ b/lib/ethdev/rte_flow_driver.h
@@ -358,6 +358,11 @@  struct rte_flow_ops {
 		 const void **update, void **query,
 		 enum rte_flow_query_update_mode mode,
 		 void *user_data, struct rte_flow_error *error);
+	/** @see rte_flow_calc_table_hash() */
+	int (*flow_calc_table_hash)
+		(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);
 };
 
 /**
diff --git a/lib/ethdev/version.map b/lib/ethdev/version.map
index b965d6aa52..1496d8caa6 100644
--- a/lib/ethdev/version.map
+++ b/lib/ethdev/version.map
@@ -312,6 +312,7 @@  EXPERIMENTAL {
 	rte_flow_async_action_list_handle_query_update;
 	rte_flow_async_actions_update;
 	rte_flow_restore_info_dynflag;
+	rte_flow_calc_table_hash;
 };
 
 INTERNAL {