ethdev: introduce entropy calculation

RFC In review Ori Kam 7 participants 19 messages Dec 10, 2023 – Jan 21, 2024

Share & tools

Ori Kam

author

2023-12-10 08:32 UTC #0 lore raw

RFC 1/1 ethdev: introduce entropy calculation

When offloading rules with the encap action, the HW may calculate entropy based on the encap protocol. Each HW can implement a different algorithm.

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.

Signed-off-by Ori Kam <[email protected]>

---
 lib/ethdev/rte_flow.h | 49 +++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 49 insertions(+)

lib/ethdev/rte_flow.h +49 -0

index affdc8121b..3989b089dd 100644
@@ -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.
+ * @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

Signature · 1 line

2.34.1

Dariusz Sosnowski

Acked-by on v1 1/1

2023-12-12 12:20 UTC #1 lore raw

Quoted 11 lines

Subject: [RFC] ethdev: introduce entropy calculation
When offloading rules with the encap action, the HW may calculate entropy based on the encap protocol.
Each HW can implement a different algorithm.
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.

Quoted 4 lines

Using the new API application can request the PMD to calculate the value as if the packet passed in the HW.
Signed-off-by Ori Kam <[email protected]>

Acked-by Dariusz Sosnowski <[email protected]>

Best regards,
Dariusz Sosnowski

Ferruh Yigit

2023-12-14 11:34 UTC #2 lore raw

In reply to Ori Kam

Quoted 3 lines · Ori Kam

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?

Quoted 7 lines

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.
Quoted 1 line
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?

Quoted 36 lines

Signed-off-by Ori Kam <[email protected]>

---
 lib/ethdev/rte_flow.h | 49 +++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 49 insertions(+)

lib/ethdev/rte_flow.h +23 -0

index affdc8121b..3989b089dd 100644
@@ -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

lib/ethdev/rte_flow.h rte_flow_calc_table_hash(uint16_t port_id, const struct rte_flow_template_table · line 6788

Quoted 10 lines

lib/ethdev/rte_flow.h +9 -0

+ *   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?

Quoted 20 lines

lib/ethdev/rte_flow.h +17 -0

+ * @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

Ori Kam

author

2023-12-14 14:16 UTC #3 lore raw

Hi Ferruh,

Quoted 6 lines

-----Original Message-----
From: Ferruh Yigit <[email protected]>
Sent: Thursday, December 14, 2023 1:35 PM
Quoted 1 line · Ori Kam
When offloading rules with the encap action, the HW may calculate entropy

Quoted 8 lines

based on the encap protocol.
Quoted 2 lines
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?

Sure, in some tunnel protocols, for example, VXLAN, NVGE it is possible to add entropy value in one of the fields of the tunnel. In VXLAN for example it is in the source port,
From the VXLAN protocol:
Source Port: 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 of the VM-to-VM traffic across the VXLAN overlay.
When calculating the UDP source port number in this manner, it
is RECOMMENDED that the value be in the dynamic/private port
range 49152-65535 [RFC6335].

Since encap groups number of different 5 tuples together, if HW doesn’t know how to RSS based on the inner application will not be able to get any distribution of packets.

This value is used to reflect the inner packet on the outer header, so distribution will be possible.

The main use case is, if application does full offload and implements the encap on the RX. For example:
Ingress/FDB match on 5 tuple encap send to hairpin / different port in case of switch.

The issue starts when there is a miss on the 5 tuple table for example, due to syn packet. A packet arrives at the application, and then the application offloads the rule.
So the application must encap the packet and set the same entropy as the HW will do for all the rest of the packets.

Quoted 5 lines

Quoted 4 lines
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),

Quoted 8 lines

Quoted 5 lines
then when encap is done in SW, application must apply the same entropy calculation algorithm.
Quoted 1 line
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?

The application will call this API when it gets a packet that it knows, that the rest of the packets from this connection will be offloaded and encaped by the HW.
(see above explanation)

Quoted 46 lines

Quoted 4 lines

Signed-off-by Ori Kam <[email protected]>
---
 lib/ethdev/rte_flow.h | 49

+++++++++++++++++++++++++++++++++++++++++++

lib/ethdev/rte_flow.h rte_flow_calc_table_hash(uint16_t port_id, const

Quoted 7 lines

 1 file changed, 49 insertions(+)

lib/ethdev/rte_flow.h +0 -0

index affdc8121b..3989b089dd 100644
@@ -6753,6 +6753,55 @@ rte_flow_calc_table_hash(uint16_t port_id, const

struct rte_flow_template_table

lib/ethdev/rte_flow.h rte_flow_calc_table_hash(uint16_t port_id, const · line 6753

Quoted 1 line

lib/ethdev/rte_flow.h +0 -0

 			 const struct rte_flow_item pattern[], uint8_t

pattern_template_index,

Quoted 31 lines

lib/ethdev/rte_flow.h +29 -0

 			 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

Quoted 8 lines

lib/ethdev/rte_flow.h rte_flow_calc_table_hash(uint16_t port_id, const struct rte_flow_template_table
Quoted 4 lines
lib/ethdev/rte_flow.h +3 -0
+ *   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?

Yes,

Quoted 25 lines

lib/ethdev/rte_flow.h rte_flow_calc_table_hash(uint16_t port_id, const struct rte_flow_template_table
Quoted 11 lines
lib/ethdev/rte_flow.h +9 -0
+ * @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
lib/ethdev/rte_flow.h rte_flow_calc_table_hash(uint16_t port_id, const struct rte_flow_template_table
Quoted 5 lines
lib/ethdev/rte_flow.h +5 -0
+ *               or the dest is not supported.
+ */
+__rte_experimental
+int
+rte_flow_calc_encap_entropy(uint16_t port_id, const struct rte_flow_item
pattern[],
lib/ethdev/rte_flow.h rte_flow_calc_table_hash(uint16_t port_id, const · line 6803
Quoted 1 line
lib/ethdev/rte_flow.h +1 -0
+			    enum rte_flow_entropy_dest dest_field, uint8_t
*entropy,
Quoted 5 lines
lib/ethdev/rte_flow.h +2 -0
+			    struct rte_flow_error *error);
+
 #ifdef __cplusplus
 }
#endif

Dumitrescu, Cristian

2023-12-14 15:25 UTC #4 lore raw

Hi Ori,

A few questions on top of Ferruh's questions for better understanding the concept inlined below:

Quoted 45 lines

-----Original Message-----
From: Ori Kam <[email protected]>
Sent: Thursday, December 14, 2023 2:17 PM
To: Ferruh Yigit <[email protected]>; Dariusz Sosnowski <[email protected]>; Dumitrescu, Cristian <[email protected]>; NBU-Contact-Thomas Monjalon (EXTERNAL) <[email protected]>; Andrew Rybchenko <[email protected]>
Cc: [email protected]; Raslan Darawsheh <[email protected]>
Subject: RE: [RFC] ethdev: introduce entropy calculation
Hi Ferruh,
Quoted 6 lines
-----Original Message-----
From: Ferruh Yigit <[email protected]>
Sent: Thursday, December 14, 2023 1:35 PM
Quoted 1 line · Ori Kam
When offloading rules with the encap action, the HW may calculate entropy
Quoted 8 lines
based on the encap protocol.
Quoted 2 lines
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?
Sure, in some tunnel protocols, for example, VXLAN, NVGE it is possible to add entropy value in one of the
fields of the tunnel. In VXLAN for example it is in the source port, From the VXLAN protocol:
Source Port: 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 of the VM-to-VM traffic across the VXLAN overlay. When calculating the UDP source port number in this manner, it is RECOMMENDED that the value be in the dynamic/private port range 49152-65535 [RFC6335].
Since encap groups number of different 5 tuples together, if HW doesn’t know how to RSS
based on the inner application will not be able to get any distribution of packets.

Quoted 9 lines

This value is used to reflect the inner packet on the outer header, so distribution will be possible.
The main use case is, if application does full offload and implements the encap on the RX.
For example:
Ingress/FDB match on 5 tuple encap send to hairpin / different port in case of switch.

Smart idea! So basically the user is able to get an idea on how good the RSS distribution is, correct?

Can you elaborate a bit on how the entropy is measured: is it a number, what is the range of values, does higher value means better, etc.

Quoted 7 lines

The issue starts when there is a miss on the 5 tuple table for example, due to syn packet.
A packet arrives at the application, and then the application offloads the rule. So the application must encap the packet and set the same entropy as the HW will do for all the rest
of the packets.

How can the app set the entropy?

Quoted 93 lines

Quoted 5 lines
Quoted 4 lines
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),
Quoted 8 lines
Quoted 5 lines
then when encap is done in SW, application must apply the same entropy calculation algorithm.
Quoted 1 line
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?
The application will call this API when it gets a packet that it knows, that the rest of the
packets from this connection will be offloaded and encaped by the HW. (see above explanation)
Quoted 46 lines
Quoted 4 lines
Signed-off-by Ori Kam <[email protected]>
---
 lib/ethdev/rte_flow.h | 49
+++++++++++++++++++++++++++++++++++++++++++
lib/ethdev/rte_flow.h rte_flow_calc_table_hash(uint16_t port_id, const
Quoted 7 lines
 1 file changed, 49 insertions(+)
lib/ethdev/rte_flow.h +0 -0
index affdc8121b..3989b089dd 100644
@@ -6753,6 +6753,55 @@ rte_flow_calc_table_hash(uint16_t port_id, const
struct rte_flow_template_table
lib/ethdev/rte_flow.h rte_flow_calc_table_hash(uint16_t port_id, const · line 6753
Quoted 1 line
lib/ethdev/rte_flow.h +0 -0
 			 const struct rte_flow_item pattern[], uint8_t
pattern_template_index,
Quoted 31 lines
lib/ethdev/rte_flow.h +29 -0
 			 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
Quoted 8 lines
lib/ethdev/rte_flow.h rte_flow_calc_table_hash(uint16_t port_id, const struct rte_flow_template_table
Quoted 4 lines
lib/ethdev/rte_flow.h +3 -0
+ *   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?
Yes,
Quoted 18 lines
lib/ethdev/rte_flow.h rte_flow_calc_table_hash(uint16_t port_id, const struct rte_flow_template_table
Quoted 11 lines
lib/ethdev/rte_flow.h +9 -0
+ * @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
lib/ethdev/rte_flow.h rte_flow_calc_table_hash(uint16_t port_id, const struct rte_flow_template_table
Quoted 5 lines
lib/ethdev/rte_flow.h +5 -0
+ *               or the dest is not supported.
+ */
+__rte_experimental
+int
+rte_flow_calc_encap_entropy(uint16_t port_id, const struct rte_flow_item
pattern[],

Quoted 7 lines

Quoted 7 lines
lib/ethdev/rte_flow.h rte_flow_calc_table_hash(uint16_t port_id, const · line 6803
Quoted 1 line
lib/ethdev/rte_flow.h +1 -0
+			    enum rte_flow_entropy_dest dest_field, uint8_t
*entropy,
Quoted 5 lines
lib/ethdev/rte_flow.h +2 -0
+			    struct rte_flow_error *error);
+
 #ifdef __cplusplus
 }
#endif

Thanks,
Cristian

Ori Kam

author

2023-12-14 17:18 UTC #5 lore raw

Hi Andrew,

Quoted 63 lines

-----Original Message-----
From: Dumitrescu, Cristian <[email protected]>
Sent: Thursday, December 14, 2023 5:25 PM
Hi Ori,
A few questions on top of Ferruh's questions for better understanding the concept inlined below:
Quoted 6 lines
-----Original Message-----
From: Ori Kam <[email protected]>
Sent: Thursday, December 14, 2023 2:17 PM
To: Ferruh Yigit <[email protected]>; Dariusz Sosnowski <[email protected]>; Dumitrescu, Cristian <[email protected]>; NBU-Contact-Thomas Monjalon
(EXTERNAL)
Quoted 5 lines
<[email protected]>; Andrew Rybchenko <[email protected]>
Cc: [email protected]; Raslan Darawsheh <[email protected]>
Subject: RE: [RFC] ethdev: introduce entropy calculation
Quoted 8 lines
Hi Ferruh,
Quoted 6 lines
-----Original Message-----
From: Ferruh Yigit <[email protected]>
Sent: Thursday, December 14, 2023 1:35 PM
Quoted 1 line · Ori Kam
When offloading rules with the encap action, the HW may calculate
entropy
Quoted 22 lines
Quoted 8 lines
based on the encap protocol.
Quoted 2 lines
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?
Sure, in some tunnel protocols, for example, VXLAN, NVGE it is possible to add entropy value in one of the
fields of the tunnel. In VXLAN for example it is in the source port, From the VXLAN protocol:
Source Port: 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 of the VM-to-VM traffic across the VXLAN overlay. When calculating the UDP source port number in this manner, it is RECOMMENDED that the value be in the dynamic/private port range 49152-65535 [RFC6335].
Quoted 3 lines
Since encap groups number of different 5 tuples together, if HW doesn’t know how to RSS
based on the inner application will not be able to get any distribution of
packets.
Quoted 2 lines
This value is used to reflect the inner packet on the outer header, so
distribution
Quoted 3 lines
will be possible.
The main use case is, if application does full offload and implements the encap
on

Quoted 9 lines

Quoted 5 lines
the RX.
For example:
Ingress/FDB match on 5 tuple encap send to hairpin / different port in case of switch.
Smart idea! So basically the user is able to get an idea on how good the RSS distribution is, correct?

Not exactly, this simply allows the distribution.
Maybe entropy is a bad name, this is the name they use in the protocol, but in reality this is some hash calculated on the packet header before the encap and set in the encap header. Using this hash results in entropy for the packets. Which can be used for load balancing.

Maybe better name would be:
Rte_flow_calc_entropy_hash?

or maybe rte_flow_calc_encap_hash (I like it less since it looks like we calculate the hash on the encap data and not the inner part)

what do you think?

Quoted 3 lines

Can you elaborate a bit on how the entropy is measured: is it a number, what is the range of values, does higher value means better, etc.

Please see my above answer, this is not entropy value but value used for entropy.

Quoted 10 lines

Quoted 1 line
The issue starts when there is a miss on the 5 tuple table for example, due to
syn
Quoted 6 lines
packet.
A packet arrives at the application, and then the application offloads the rule. So the application must encap the packet and set the same entropy as the HW will do for all the rest
of the packets.
How can the app set the entropy?

It can't, it is assumed that the HW is configured ether hardcoded or by using other means with the algorithm. The application doesn't know and doesn't care about what is the calculation only about the result.

Quoted 109 lines

Quoted 8 lines
Quoted 8 lines
Quoted 5 lines
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),
Quoted 2 lines
then when encap is done in SW, application must apply the same entropy calculation algorithm.
Quoted 8 lines
Quoted 6 lines
Quoted 3 lines
Quoted 1 line
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?
The application will call this API when it gets a packet that it knows, that the
rest
Quoted 8 lines
of the
packets from this connection will be offloaded and encaped by the HW. (see above explanation)
Quoted 4 lines
Quoted 4 lines
Signed-off-by Ori Kam <[email protected]>
---
 lib/ethdev/rte_flow.h | 49
Quoted 8 lines
Quoted 8 lines
+++++++++++++++++++++++++++++++++++++++++++
lib/ethdev/rte_flow.h rte_flow_calc_table_hash(uint16_t port_id,
Quoted 7 lines
 1 file changed, 49 insertions(+)
lib/ethdev/rte_flow.h +0 -0
index affdc8121b..3989b089dd 100644
@@ -6753,6 +6753,55 @@ rte_flow_calc_table_hash(uint16_t port_id,
const
Quoted 27 lines
Quoted 27 lines
struct rte_flow_template_table
lib/ethdev/rte_flow.h rte_flow_calc_table_hash(uint16_t port_id, · line 6753
Quoted 1 line
lib/ethdev/rte_flow.h +0 -0
 			 const struct rte_flow_item pattern[], uint8_t
pattern_template_index,
Quoted 24 lines
lib/ethdev/rte_flow.h +22 -0
 			 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.
+ *
Quoted 8 lines
Quoted 8 lines
lib/ethdev/rte_flow.h rte_flow_calc_table_hash(uint16_t port_id, const struct rte_flow_template_table
Quoted 8 lines
lib/ethdev/rte_flow.h +8 -0
+ * @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,
Quoted 5 lines
Quoted 5 lines
Quoted 3 lines
lib/ethdev/rte_flow.h +2 -0
+ *   so entropy[0] is the MSB.
+ *   The number of bytes is based on the destination field type.
 
Quoted 15 lines
Quoted 2 lines
Is the size same as field size in the 'dest_field'? Like for 'RTE_FLOW_ENTROPY_DEST_UDP_SRC_PORT' is it two bytes?
Yes,
Quoted 11 lines
Quoted 11 lines
lib/ethdev/rte_flow.h +9 -0
+ * @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
Quoted 6 lines
Quoted 6 lines
entropy
lib/ethdev/rte_flow.h rte_flow_calc_table_hash(uint16_t port_id, const struct rte_flow_template_table
Quoted 5 lines
lib/ethdev/rte_flow.h +5 -0
+ *               or the dest is not supported.
+ */
+__rte_experimental
+int
+rte_flow_calc_encap_entropy(uint16_t port_id, const struct
rte_flow_item
Quoted 8 lines
Quoted 8 lines
pattern[],
lib/ethdev/rte_flow.h rte_flow_calc_table_hash(uint16_t port_id, · line 6803
Quoted 1 line
lib/ethdev/rte_flow.h +1 -0
+			    enum rte_flow_entropy_dest dest_field, uint8_t
*entropy,
Quoted 5 lines
lib/ethdev/rte_flow.h +2 -0
+			    struct rte_flow_error *error);
+
 #ifdef __cplusplus
 }
#endif
Thanks,
Cristian

Stephen Hemminger

2023-12-14 17:26 UTC #6 lore raw

Quoted 26 lines · On Thu, 14 Dec 2023 17:18:25 +0000 Ori Kam <[email protected]> wrote:

Quoted 11 lines
Quoted 3 lines
Since encap groups number of different 5 tuples together, if HW doesn’t know how to RSS
based on the inner application will not be able to get any distribution of
packets.
Quoted 2 lines
This value is used to reflect the inner packet on the outer header, so
distribution
Quoted 3 lines
will be possible.
The main use case is, if application does full offload and implements the encap
on
Quoted 9 lines
Quoted 5 lines
the RX.
For example:
Ingress/FDB match on 5 tuple encap send to hairpin / different port in case of switch.
Smart idea! So basically the user is able to get an idea on how good the RSS distribution is, correct?
Not exactly, this simply allows the distribution.
Maybe entropy is a bad name, this is the name they use in the protocol, but in reality this is some hash calculated on the packet header before the encap and set in the encap header. Using this hash results in entropy for the packets. Which can be used for load balancing.

Quoted 6 lines

Maybe better name would be:
Rte_flow_calc_entropy_hash?
or maybe rte_flow_calc_encap_hash (I like it less since it looks like we calculate the hash on the encap data and not the inner part)
what do you think?

Entropy has meaning in crypto and random numbers generators that is different from this usage. So entropy is bad name to use. Maybe rte_flow_hash_distribution?

Ferruh Yigit

2023-12-15 13:44 UTC #7 lore raw

Quoted 32 lines · Stephen Hemminger

Quoted 29 lines · On Thu, 14 Dec 2023 17:18:25 +0000 Ori Kam <[email protected]> wrote:
Quoted 11 lines
Quoted 3 lines
Since encap groups number of different 5 tuples together, if HW doesn’t know how to RSS
based on the inner application will not be able to get any distribution of
packets.
Quoted 2 lines
This value is used to reflect the inner packet on the outer header, so
distribution
Quoted 3 lines
will be possible.
The main use case is, if application does full offload and implements the encap
on
Quoted 9 lines
Quoted 5 lines
the RX.
For example:
Ingress/FDB match on 5 tuple encap send to hairpin / different port in case of switch.
Smart idea! So basically the user is able to get an idea on how good the RSS distribution is, correct?
Not exactly, this simply allows the distribution.
Maybe entropy is a bad name, this is the name they use in the protocol, but in reality this is some hash calculated on the packet header before the encap and set in the encap header. Using this hash results in entropy for the packets. Which can be used for load balancing.
Maybe better name would be:
Rte_flow_calc_entropy_hash?

Quoted 7 lines

Quoted 3 lines
or maybe rte_flow_calc_encap_hash (I like it less since it looks like we calculate the hash on the encap data and not the inner part)
what do you think?
Entropy has meaning in crypto and random numbers generators that is different from this usage. So entropy is bad name to use. Maybe rte_flow_hash_distribution?

Hi Ori,

Thank you for the description, it is more clear now.

And unless this is specifically defined as 'entropy' in spec, I am too for rename.

At least in VXLAN spec, it is mentioned that this field is to "enable a level of entropy", but not exactly names it as entropy.

Thomas Monjalon

2023-12-15 16:21 UTC #8 lore raw

15/12/2023 14:44, Ferruh Yigit:

Quoted 43 lines · Stephen Hemminger

Quoted 32 lines
Quoted 29 lines · On Thu, 14 Dec 2023 17:18:25 +0000 Ori Kam <[email protected]> wrote:
Quoted 11 lines
Quoted 3 lines
Since encap groups number of different 5 tuples together, if HW doesn’t know how to RSS
based on the inner application will not be able to get any distribution of
packets.
Quoted 2 lines
This value is used to reflect the inner packet on the outer header, so
distribution
Quoted 3 lines
will be possible.
The main use case is, if application does full offload and implements the encap
on
Quoted 9 lines
Quoted 5 lines
the RX.
For example:
Ingress/FDB match on 5 tuple encap send to hairpin / different port in case of switch.
Smart idea! So basically the user is able to get an idea on how good the RSS distribution is, correct?
Not exactly, this simply allows the distribution.
Maybe entropy is a bad name, this is the name they use in the protocol, but in reality this is some hash calculated on the packet header before the encap and set in the encap header. Using this hash results in entropy for the packets. Which can be used for load balancing.
Maybe better name would be:
Rte_flow_calc_entropy_hash?
Quoted 7 lines
Quoted 3 lines
or maybe rte_flow_calc_encap_hash (I like it less since it looks like we calculate the hash on the encap data and not the inner part)
what do you think?
Entropy has meaning in crypto and random numbers generators that is different from this usage. So entropy is bad name to use. Maybe rte_flow_hash_distribution?
Hi Ori,

Quoted 7 lines

Thank you for the description, it is more clear now.
And unless this is specifically defined as 'entropy' in spec, I am too for rename.
At least in VXLAN spec, it is mentioned that this field is to "enable a level of entropy", but not exactly names it as entropy.

Exactly my thought about the naming.
Good to see I am not alone thinking this naming is disturbing :)

Andrew Rybchenko

2023-12-16 09:03 UTC #9 lore raw

Quoted 46 lines · Thomas Monjalon

15/12/2023 14:44, Ferruh Yigit:
Quoted 45 lines · Stephen Hemminger
Quoted 32 lines
Quoted 29 lines · On Thu, 14 Dec 2023 17:18:25 +0000 Ori Kam <[email protected]> wrote:
Quoted 11 lines
Quoted 3 lines
Since encap groups number of different 5 tuples together, if HW doesn’t know how to RSS
based on the inner application will not be able to get any distribution of
packets.
Quoted 2 lines
This value is used to reflect the inner packet on the outer header, so
distribution
Quoted 3 lines
will be possible.
The main use case is, if application does full offload and implements the encap
on
Quoted 9 lines
Quoted 5 lines
the RX.
For example:
Ingress/FDB match on 5 tuple encap send to hairpin / different port in case of switch.
Smart idea! So basically the user is able to get an idea on how good the RSS distribution is, correct?
Not exactly, this simply allows the distribution.
Maybe entropy is a bad name, this is the name they use in the protocol, but in reality this is some hash calculated on the packet header before the encap and set in the encap header. Using this hash results in entropy for the packets. Which can be used for load balancing.
Maybe better name would be:
Rte_flow_calc_entropy_hash?
Quoted 7 lines
Quoted 3 lines
or maybe rte_flow_calc_encap_hash (I like it less since it looks like we calculate the hash on the encap data and not the inner part)
what do you think?
Entropy has meaning in crypto and random numbers generators that is different from this usage. So entropy is bad name to use. Maybe rte_flow_hash_distribution?
Hi Ori,
Thank you for the description, it is more clear now.

Quoted 8 lines

Quoted 5 lines
And unless this is specifically defined as 'entropy' in spec, I am too for rename.
At least in VXLAN spec, it is mentioned that this field is to "enable a level of entropy", but not exactly names it as entropy.
Exactly my thought about the naming.
Good to see I am not alone thinking this naming is disturbing :)

I'd avoid usage of term "entropy" in this patch. It is very confusing.

Ori Kam

author

2023-12-27 15:20 UTC #10 lore raw

Hi Andrew, Stephen, Ferruh and Thomas,

Quoted 64 lines

-----Original Message-----
From: Andrew Rybchenko <[email protected]>
Sent: Saturday, December 16, 2023 11:04 AM
Quoted 6 lines · Thomas Monjalon
15/12/2023 14:44, Ferruh Yigit:
Quoted 5 lines · Stephen Hemminger
Quoted 4 lines
Quoted 1 line · On Thu, 14 Dec 2023 17:18:25 +0000 Ori Kam <[email protected]> wrote:
Quoted 1 line
Quoted 1 line
Since encap groups number of different 5 tuples together, if HW
doesn’t know
Quoted 9 lines
Quoted 9 lines
Quoted 9 lines
Quoted 9 lines
Quoted 9 lines
Quoted 2 lines
how to RSS
based on the inner application will not be able to get any distribution of
packets.
Quoted 2 lines
This value is used to reflect the inner packet on the outer header, so
distribution
Quoted 3 lines
will be possible.
The main use case is, if application does full offload and implements
the encap
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
on
Quoted 3 lines
the RX.
For example:
Ingress/FDB match on 5 tuple encap send to hairpin / different port in
case of
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 2 lines
switch.
Smart idea! So basically the user is able to get an idea on how good the
RSS
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
Quoted 2 lines
distribution is, correct?
Not exactly, this simply allows the distribution.
Maybe entropy is a bad name, this is the name they use in the protocol,
but in reality
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
this is some hash calculated on the packet header before the encap and
set in the encap header.
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Using this hash results in entropy for the packets. Which can be used for
load balancing.
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
Maybe better name would be:
Rte_flow_calc_entropy_hash?
or maybe rte_flow_calc_encap_hash (I like it less since it looks like we
calculate the hash on the encap data and not the inner part)
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 2 lines
what do you think?
Entropy has meaning in crypto and random numbers generators that is
different from
Quoted 1 line
Quoted 1 line
Quoted 1 line
this usage. So entropy is bad name to use. Maybe
rte_flow_hash_distribution?
Quoted 9 lines
Quoted 9 lines
Quoted 1 line
Hi Ori,
Thank you for the description, it is more clear now.
And unless this is specifically defined as 'entropy' in spec, I am too for rename.

Quoted 7 lines

Quoted 5 lines
Quoted 2 lines
At least in VXLAN spec, it is mentioned that this field is to "enable a level of entropy", but not exactly names it as entropy.
Exactly my thought about the naming.
Good to see I am not alone thinking this naming is disturbing :)
I'd avoid usage of term "entropy" in this patch. It is very confusing.

What about rte_flow_calc_encap_hash?

Dumitrescu, Cristian

2024-01-04 13:01 UTC #11 lore raw

Quoted 82 lines

-----Original Message-----
From: Ori Kam <[email protected]>
Sent: Wednesday, December 27, 2023 3:20 PM
To: Andrew Rybchenko <[email protected]>; NBU-Contact- Thomas Monjalon (EXTERNAL) <[email protected]>; Stephen Hemminger <[email protected]>; Ferruh Yigit <[email protected]>
Cc: Dumitrescu, Cristian <[email protected]>; Dariusz Sosnowski <[email protected]>; [email protected]; Raslan Darawsheh <[email protected]>
Subject: RE: [RFC] ethdev: introduce entropy calculation
Hi Andrew, Stephen, Ferruh and Thomas,
Quoted 67 lines
-----Original Message-----
From: Andrew Rybchenko <[email protected]>
Sent: Saturday, December 16, 2023 11:04 AM
Quoted 6 lines · Thomas Monjalon
15/12/2023 14:44, Ferruh Yigit:
Quoted 5 lines · Stephen Hemminger
Quoted 4 lines
Quoted 1 line · On Thu, 14 Dec 2023 17:18:25 +0000 Ori Kam <[email protected]> wrote:
Quoted 1 line
Quoted 1 line
Since encap groups number of different 5 tuples together, if HW
doesn’t know
Quoted 9 lines
Quoted 9 lines
Quoted 9 lines
Quoted 9 lines
Quoted 9 lines
Quoted 2 lines
how to RSS
based on the inner application will not be able to get any distribution of
packets.
Quoted 2 lines
This value is used to reflect the inner packet on the outer header, so
distribution
Quoted 3 lines
will be possible.
The main use case is, if application does full offload and implements
the encap
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
on
Quoted 3 lines
the RX.
For example:
Ingress/FDB match on 5 tuple encap send to hairpin / different port in
case of
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 2 lines
switch.
Smart idea! So basically the user is able to get an idea on how good the
RSS
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
Quoted 2 lines
distribution is, correct?
Not exactly, this simply allows the distribution.
Maybe entropy is a bad name, this is the name they use in the protocol,
but in reality
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
this is some hash calculated on the packet header before the encap and
set in the encap header.
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Using this hash results in entropy for the packets. Which can be used for
load balancing.
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
Maybe better name would be:
Rte_flow_calc_entropy_hash?
or maybe rte_flow_calc_encap_hash (I like it less since it looks like we
calculate the hash on the encap data and not the inner part)
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 2 lines
what do you think?
Entropy has meaning in crypto and random numbers generators that is
different from
Quoted 1 line
Quoted 1 line
Quoted 1 line
this usage. So entropy is bad name to use. Maybe
rte_flow_hash_distribution?
Quoted 12 lines
Quoted 11 lines
Quoted 1 line
Hi Ori,
Thank you for the description, it is more clear now.
And unless this is specifically defined as 'entropy' in spec, I am too for rename.
At least in VXLAN spec, it is mentioned that this field is to "enable a level of entropy", but not exactly names it as entropy.

Quoted 8 lines

Quoted 4 lines
Quoted 2 lines
Exactly my thought about the naming.
Good to see I am not alone thinking this naming is disturbing :)
I'd avoid usage of term "entropy" in this patch. It is very confusing.
What about rte_flow_calc_encap_hash?

How about simply rte_flow_calc_hash? My understanding is this is a general-purpose hash that is not limited to encapsulation work.

Ori Kam

author

2024-01-04 14:33 UTC #12 lore raw

Hi Cristian,

Quoted 13 lines

-----Original Message-----
From: Dumitrescu, Cristian <[email protected]>
Sent: Thursday, January 4, 2024 2:57 PM
Quoted 10 lines
Quoted 10 lines
Quoted 9 lines
Quoted 6 lines
And unless this is specifically defined as 'entropy' in spec, I am too for rename.
At least in VXLAN spec, it is mentioned that this field is to "enable a level of entropy", but not exactly names it as entropy.
Exactly my thought about the naming.
Good to see I am not alone thinking this naming is disturbing :)

Quoted 7 lines

Quoted 5 lines
Quoted 1 line
I'd avoid usage of term "entropy" in this patch. It is very confusing.
What about rte_flow_calc_encap_hash?
How about simply rte_flow_calc_hash? My understanding is this is a general- purpose hash that is not limited to encapsulation work.

Unfortunately, this is not a general-purpose hash. HW may implement a different hash for each use case. also, the hash result is length differs depending on the feature and even the target field.

We can take your naming idea and change the parameters a bit:
rte_flow_calc_hash(port, feature, *attribute, pattern, hash_len, *hash)

For the feature we will have at this point:
NVGRE_HASH,
SPORT_HASH

The attribute parameter will be empty for now, but it may be used later to add extra information for the hash if more information is required, for example, some key.
In addition, we will also be able to merge the current function rte_flow_calc_table_hash, if we pass the missing parameters (table id, template id) in the attribute field.

What do you think?

Thomas Monjalon

2024-01-04 18:19 UTC #13 lore raw

04/01/2024 15:33, Ori Kam:

Quoted 32 lines

Hi Cristian,
Quoted 12 lines
From: Dumitrescu, Cristian <[email protected]>
Sent: Thursday, January 4, 2024 2:57 PM
Quoted 10 lines
Quoted 10 lines
Quoted 9 lines
Quoted 6 lines
And unless this is specifically defined as 'entropy' in spec, I am too for rename.
At least in VXLAN spec, it is mentioned that this field is to "enable a level of entropy", but not exactly names it as entropy.
Exactly my thought about the naming.
Good to see I am not alone thinking this naming is disturbing :)
Quoted 7 lines
Quoted 5 lines
Quoted 1 line
I'd avoid usage of term "entropy" in this patch. It is very confusing.
What about rte_flow_calc_encap_hash?
How about simply rte_flow_calc_hash? My understanding is this is a general- purpose hash that is not limited to encapsulation work.
Unfortunately, this is not a general-purpose hash. HW may implement a different hash for each use case. also, the hash result is length differs depending on the feature and even the target field.
We can take your naming idea and change the parameters a bit:
rte_flow_calc_hash(port, feature, *attribute, pattern, hash_len, *hash)
For the feature we will have at this point:
NVGRE_HASH,
SPORT_HASH

Quoted 6 lines

The attribute parameter will be empty for now, but it may be used later to add extra information for the hash if more information is required, for example, some key.
In addition, we will also be able to merge the current function rte_flow_calc_table_hash, if we pass the missing parameters (table id, template id) in the attribute field.
What do you think?

I like the idea of having a single function for HW hashes. Is there an impact on performance? How much is it sensitive?

Ori Kam

author

2024-01-07 09:37 UTC #14 lore raw

Quoted 44 lines

-----Original Message-----
From: Thomas Monjalon <[email protected]>
Sent: Thursday, January 4, 2024 8:19 PM
04/01/2024 15:33, Ori Kam:
Quoted 20 lines
Hi Cristian,
Quoted 18 lines
From: Dumitrescu, Cristian <[email protected]>
Sent: Thursday, January 4, 2024 2:57 PM
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 6 lines
And unless this is specifically defined as 'entropy' in spec, I am too for rename.
At least in VXLAN spec, it is mentioned that this field is to "enable a level of entropy", but not exactly names it as entropy.
Quoted 8 lines
Quoted 4 lines
Quoted 2 lines
Exactly my thought about the naming.
Good to see I am not alone thinking this naming is disturbing :)
I'd avoid usage of term "entropy" in this patch. It is very confusing.
What about rte_flow_calc_encap_hash?
How about simply rte_flow_calc_hash? My understanding is this is a
general-
Quoted 3 lines
Quoted 1 line
purpose hash that is not limited to encapsulation work.
Unfortunately, this is not a general-purpose hash. HW may implement a
different hash for each use case.
Quoted 1 line
also, the hash result is length differs depending on the feature and even the
target field.
Quoted 9 lines
We can take your naming idea and change the parameters a bit:
rte_flow_calc_hash(port, feature, *attribute, pattern, hash_len, *hash)
For the feature we will have at this point:
NVGRE_HASH,
SPORT_HASH
The attribute parameter will be empty for now, but it may be used later to
add extra information
Quoted 2 lines
for the hash if more information is required, for example, some key. In addition, we will also be able to merge the current function

Quoted 9 lines

rte_flow_calc_table_hash,
Quoted 3 lines
if we pass the missing parameters (table id, template id) in the attribute field.
What do you think?
I like the idea of having a single function for HW hashes. Is there an impact on performance? How much is it sensitive?

It is sensitive since we expect this function to be called for each packet. This may not be such a great idea.
So, back to square one and keep the rte_flow_calc_encap_hash

Andrew Rybchenko

2023-12-16 09:19 UTC #15 lore raw

In reply to Ori Kam

Quoted 10 lines · Ori Kam

When offloading rules with the encap action, the HW may calculate entropy based on the encap protocol. Each HW can implement a different algorithm.
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.

I'm still wondering why the API is required. Does app install encap rule when the first packet is processed? The rule can contain all outer headers (as it is calculated in SW anyway) and HW does not need to calculate anything.

Quoted 15 lines

Signed-off-by Ori Kam <[email protected]>

---
  lib/ethdev/rte_flow.h | 49 +++++++++++++++++++++++++++++++++++++++++++
  1 file changed, 49 insertions(+)

lib/ethdev/rte_flow.h +1 -0

index affdc8121b..3989b089dd 100644
@@ -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);
 
+/**

lib/ethdev/rte_flow.h rte_flow_calc_table_hash(uint16_t port_id, const struct rte_flow_template_table · line 6766

Quoted 10 lines

lib/ethdev/rte_flow.h +10 -0

+ * @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,

And source and destination are used together but for different purposes it is very hard to follow which is used for which purpose. I'd avoid term "dest" in the enum naming. May be present "flow" is already good enough to highlight that it is per-flow? rte_flow_encap_hash? rte_flow_encap_field_hash?

Quoted 5 lines

lib/ethdev/rte_flow.h +5 -0

+	/* Calculate entropy placed in NVGRE flow ID field. */
+	RTE_FLOW_ENTROPY_DEST_NVGRE_FLOW_ID,
+};
+
+/**

lib/ethdev/rte_flow.h rte_flow_calc_table_hash(uint16_t port_id, const struct rte_flow_template_table · line 6781

Quoted 10 lines

lib/ethdev/rte_flow.h +10 -0

+ * @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.

Is it inner packet fields? Should all fields be used for hash calculation? May be it is better to describe as inner packet headers? How does app know which headers to extract and provide?

lib/ethdev/rte_flow.h rte_flow_calc_table_hash(uint16_t port_id, const struct rte_flow_template_table

Quoted 6 lines

lib/ethdev/rte_flow.h +6 -0

+ * @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.f

API contract is a bit unclear here. May be it is safer to provide buffer size explicitly?

Quoted 20 lines

lib/ethdev/rte_flow.h +17 -0

+ * @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

Ori Kam

author

2023-12-17 10:07 UTC #16 lore raw

Hi Andrew,

Quoted 15 lines

-----Original Message-----
From: Andrew Rybchenko <[email protected]>
Sent: Saturday, December 16, 2023 11:19 AM
Quoted 1 line · Ori Kam
When offloading rules with the encap action, the HW may calculate entropy
based on the encap protocol.
Quoted 4 lines
Each HW can implement a different algorithm.
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),
Quoted 3 lines
then when encap is done in SW, application must apply the same entropy calculation algorithm.

Quoted 7 lines

Quoted 2 lines
Using the new API application can request the PMD to calculate the value as if the packet passed in the HW.
I'm still wondering why the API is required. Does app install encap rule when the first packet is processed? The rule can contain all outer headers (as it is calculated in SW anyway) and HW does not need to calculate anything.

Yes, the application installs a rule based on the first packet.
as a result, all the rest of the packets are encaped by the HW.
This API allows the application to use the same value as the HW will use when encapsulating the packet. In other words, we have 2 paths:
Path 1 SW, for the first packet
Path 2 HW, all the rest of the packest

Quoted 27 lines

Quoted 5 lines
Signed-off-by Ori Kam <[email protected]>
---
  lib/ethdev/rte_flow.h | 49
+++++++++++++++++++++++++++++++++++++++++++
lib/ethdev/rte_flow.h rte_flow_calc_table_hash(uint16_t port_id, const
Quoted 7 lines
  1 file changed, 49 insertions(+)
lib/ethdev/rte_flow.h +0 -0
index affdc8121b..3989b089dd 100644
@@ -6753,6 +6753,55 @@ rte_flow_calc_table_hash(uint16_t port_id, const
struct rte_flow_template_table
lib/ethdev/rte_flow.h rte_flow_calc_table_hash(uint16_t port_id, const · line 6753
Quoted 1 line
lib/ethdev/rte_flow.h +0 -0
  			 const struct rte_flow_item pattern[], uint8_t
pattern_template_index,
Quoted 11 lines
lib/ethdev/rte_flow.h +9 -0
  			 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 {

Quoted 8 lines

lib/ethdev/rte_flow.h rte_flow_calc_table_hash(uint16_t port_id, const struct rte_flow_template_table · line 6766
Quoted 2 lines
lib/ethdev/rte_flow.h +2 -0
+	/* Calculate entropy placed in UDP source port field. */
+	RTE_FLOW_ENTROPY_DEST_UDP_SRC_PORT,
And source and destination are used together but for different purposes it is very hard to follow which is used for which purpose. I'd avoid term "dest" in the enum naming. May be present "flow" is already good enough to highlight that it is per-flow? rte_flow_encap_hash? rte_flow_encap_field_hash?

I'm open to any suggestions, this enum is supposed to show to which
field the HW insert the calculated value. This field is defined by the encapsulation protocol. For example, VXLAN the hash is stored in source port, while in NVGRE it is stored in flow_id field. The destination field also impact the size.

What do you think about:
RTE_FLOW_ENCAP_HASH_SRC_PORT?

What about if we change the destination to enum that will hold the destination tunnel type RTE_FLOW_TUNNEL_TYPE_VXLAN,
RTE_FLOW_TUNNEL_TYPE_NVGRE

Quoted 12 lines

lib/ethdev/rte_flow.h +11 -0

+	/* 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.
+ *

Quoted 8 lines

lib/ethdev/rte_flow.h rte_flow_calc_table_hash(uint16_t port_id, const struct rte_flow_template_table · line 6781
Quoted 4 lines
lib/ethdev/rte_flow.h +4 -0
+ * @param[in] port_id
+ *   Port identifier of Ethernet device.
+ * @param[in] pattern
+ *   The values to be used in the entropy calculation.
Is it inner packet fields? Should all fields be used for hash calculation? May be it is better to describe as inner packet headers? How does app know which headers to extract and provide?

The fields are the outer fields that will become inner fields, after the encapsulation. The fields are dependent on the HW (in standard case 5 tuple). but applications can /should set all the fields he got from the packet, at the end those are the fields that the HW will see.

Quoted 10 lines

lib/ethdev/rte_flow.h rte_flow_calc_table_hash(uint16_t port_id, const struct rte_flow_template_table
Quoted 7 lines
lib/ethdev/rte_flow.h +6 -0
+ * @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.f
API contract is a bit unclear here. May be it is safer to provide buffer size explicitly?

The size of the field is defined by the destination field, which in turn is defined by the protocol.

I don't think adding size has any meaning when you know that the value is going to be set in source port which has the size of 16 bites.
Based on enum suggestion of tunnel type. I think it will also explain the dest and size. What do you think?

Quoted 24 lines

lib/ethdev/rte_flow.h rte_flow_calc_table_hash(uint16_t port_id, const struct rte_flow_template_table
Quoted 10 lines
lib/ethdev/rte_flow.h +9 -0
+ * @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
lib/ethdev/rte_flow.h rte_flow_calc_table_hash(uint16_t port_id, const struct rte_flow_template_table
Quoted 5 lines
lib/ethdev/rte_flow.h +5 -0
+ *               or the dest is not supported.
+ */
+__rte_experimental
+int
+rte_flow_calc_encap_entropy(uint16_t port_id, const struct rte_flow_item
pattern[],
lib/ethdev/rte_flow.h rte_flow_calc_table_hash(uint16_t port_id, const · line 6802
Quoted 1 line
lib/ethdev/rte_flow.h +1 -0
+			    enum rte_flow_entropy_dest dest_field, uint8_t
*entropy,
Quoted 5 lines
lib/ethdev/rte_flow.h +2 -0
+			    struct rte_flow_error *error);
+
  #ifdef __cplusplus
  }
  #endif

Andrew Rybchenko

2024-01-12 07:46 UTC #17 lore raw

Hi Ori,

sorry for delay with reply.

Quoted 25 lines · Ori Kam

Hi Andrew,
Quoted 15 lines
-----Original Message-----
From: Andrew Rybchenko <[email protected]>
Sent: Saturday, December 16, 2023 11:19 AM
Quoted 1 line · Ori Kam
When offloading rules with the encap action, the HW may calculate entropy
based on the encap protocol.
Quoted 4 lines
Each HW can implement a different algorithm.
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),
Quoted 3 lines
then when encap is done in SW, application must apply the same entropy calculation algorithm.
Quoted 7 lines
Quoted 2 lines
Using the new API application can request the PMD to calculate the value as if the packet passed in the HW.
I'm still wondering why the API is required. Does app install encap rule when the first packet is processed? The rule can contain all outer headers (as it is calculated in SW anyway) and HW does not need to calculate anything.

Quoted 6 lines

Yes, the application installs a rule based on the first packet.
as a result, all the rest of the packets are encaped by the HW.
This API allows the application to use the same value as the HW will use when encapsulating the packet. In other words, we have 2 paths:
Path 1 SW, for the first packet
Path 2 HW, all the rest of the packest

I get it, but I still don't understand why HW should calculate something. Can it simply use value provided by SW in encap rule? If so, calculation becomes not HW-specific and does not require driver callback.

Quoted 34 lines

Quoted 25 lines
Quoted 3 lines
Signed-off-by Ori Kam <[email protected]>
---
   lib/ethdev/rte_flow.h | 49
+++++++++++++++++++++++++++++++++++++++++++
lib/ethdev/rte_flow.h rte_flow_calc_table_hash(uint16_t port_id, const
Quoted 7 lines
   1 file changed, 49 insertions(+)
lib/ethdev/rte_flow.h +0 -0
index affdc8121b..3989b089dd 100644
@@ -6753,6 +6753,55 @@ rte_flow_calc_table_hash(uint16_t port_id, const
struct rte_flow_template_table
lib/ethdev/rte_flow.h rte_flow_calc_table_hash(uint16_t port_id, const · line 6753
Quoted 1 line
lib/ethdev/rte_flow.h +0 -0
   			 const struct rte_flow_item pattern[], uint8_t
pattern_template_index,
Quoted 11 lines
lib/ethdev/rte_flow.h +9 -0
   			 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 {
Quoted 8 lines
lib/ethdev/rte_flow.h rte_flow_calc_table_hash(uint16_t port_id, const struct rte_flow_template_table · line 6766
Quoted 2 lines
lib/ethdev/rte_flow.h +2 -0
+	/* Calculate entropy placed in UDP source port field. */
+	RTE_FLOW_ENTROPY_DEST_UDP_SRC_PORT,
And source and destination are used together but for different purposes it is very hard to follow which is used for which purpose. I'd avoid term "dest" in the enum naming. May be present "flow" is already good enough to highlight that it is per-flow? rte_flow_encap_hash? rte_flow_encap_field_hash?

Quoted 7 lines

I'm open to any suggestions, this enum is supposed to show to which
field the HW insert the calculated value. This field is defined by the encapsulation protocol. For example, VXLAN the hash is stored in source port, while in NVGRE it is stored in flow_id field. The destination field also impact the size.
What do you think about:
RTE_FLOW_ENCAP_HASH_SRC_PORT?

Sounds better.

Quoted 3 lines

What about if we change the destination to enum that will hold the destination tunnel type RTE_FLOW_TUNNEL_TYPE_VXLAN,
RTE_FLOW_TUNNEL_TYPE_NVGRE

It could be an option as well, but binds tunnel type to size of hash to be calculated. It looks OK right now, but may be wrong in the future.

Quoted 20 lines

Quoted 11 lines
Quoted 11 lines
lib/ethdev/rte_flow.h +11 -0
+	/* 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.
+ *
Quoted 8 lines
lib/ethdev/rte_flow.h rte_flow_calc_table_hash(uint16_t port_id, const struct rte_flow_template_table · line 6781
Quoted 4 lines
lib/ethdev/rte_flow.h +4 -0
+ * @param[in] port_id
+ *   Port identifier of Ethernet device.
+ * @param[in] pattern
+ *   The values to be used in the entropy calculation.
Is it inner packet fields? Should all fields be used for hash calculation? May be it is better to describe as inner packet headers? How does app know which headers to extract and provide?

Quoted 3 lines

The fields are the outer fields that will become inner fields, after the encapsulation. The fields are dependent on the HW (in standard case 5 tuple). but applications can /should set all the fields he got from the packet, at the end those are the fields that the HW will see.

OK I see.

Quoted 11 lines

Quoted 10 lines
lib/ethdev/rte_flow.h rte_flow_calc_table_hash(uint16_t port_id, const struct rte_flow_template_table
Quoted 7 lines
lib/ethdev/rte_flow.h +6 -0
+ * @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.f
API contract is a bit unclear here. May be it is safer to provide buffer size explicitly?

Quoted 6 lines

The size of the field is defined by the destination field, which in turn is defined by the protocol.
I don't think adding size has any meaning when you know that the value is going to be set in source port which has the size of 16 bites.
Based on enum suggestion of tunnel type. I think it will also explain the dest and size. What do you think?

I see, but IMHO it is still very unsafe. Simply too error prone and there is not way to catch it. IMHO buffer size will not overload it too much, but will make API clearer and safer.

Quoted 26 lines

Quoted 25 lines
lib/ethdev/rte_flow.h rte_flow_calc_table_hash(uint16_t port_id, const struct rte_flow_template_table
Quoted 11 lines
lib/ethdev/rte_flow.h +9 -0
+ * @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
lib/ethdev/rte_flow.h rte_flow_calc_table_hash(uint16_t port_id, const struct rte_flow_template_table
Quoted 5 lines
lib/ethdev/rte_flow.h +5 -0
+ *               or the dest is not supported.
+ */
+__rte_experimental
+int
+rte_flow_calc_encap_entropy(uint16_t port_id, const struct rte_flow_item
pattern[],
lib/ethdev/rte_flow.h rte_flow_calc_table_hash(uint16_t port_id, const · line 6802
Quoted 1 line
lib/ethdev/rte_flow.h +1 -0
+			    enum rte_flow_entropy_dest dest_field, uint8_t
*entropy,
Quoted 5 lines
lib/ethdev/rte_flow.h +2 -0
+			    struct rte_flow_error *error);
+
   #ifdef __cplusplus
   }
   #endif

Ori Kam

author

2024-01-21 09:36 UTC #18 lore raw

Hi Andrew,

Quoted 44 lines

-----Original Message-----
From: Andrew Rybchenko <[email protected]>
Sent: Friday, January 12, 2024 9:46 AM
To: Ori Kam <[email protected]>; Dariusz Sosnowski <[email protected]>; [email protected]; [email protected]; NBU-Contact-Thomas Monjalon (EXTERNAL) <[email protected]>
Cc: [email protected]; Raslan Darawsheh <[email protected]>
Subject: Re: [RFC] ethdev: introduce entropy calculation
Hi Ori,
sorry for delay with reply.
Quoted 20 lines · Ori Kam
Hi Andrew,
Quoted 18 lines
-----Original Message-----
From: Andrew Rybchenko <[email protected]>
Sent: Saturday, December 16, 2023 11:19 AM
Quoted 1 line · Ori Kam
When offloading rules with the encap action, the HW may calculate entropy
based on the encap protocol.
Quoted 4 lines
Each HW can implement a different algorithm.
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),
Quoted 5 lines
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.
Quoted 8 lines
Quoted 4 lines
I'm still wondering why the API is required. Does app install encap rule when the first packet is processed? The rule can contain all outer headers (as it is calculated in SW anyway) and HW does not need to calculate anything.
Yes, the application installs a rule based on the first packet. as a result, all the rest of the packets are encaped by the HW. This API allows the application to use the same value as the HW will use when
encapsulating the packet.

Quoted 8 lines

Quoted 3 lines
In other words, we have 2 paths:
Path 1 SW, for the first packet
Path 2 HW, all the rest of the packest
I get it, but I still don't understand why HW should calculate something. Can it simply use value provided by SW in encap rule? If so, calculation becomes not HW-specific and does not require driver callback.

The value is calculated per 5 tuple, it is possible that the SW will create
the encap flow with the required data. But this means that this rule should be per tuple.
On the other hand, if the application wants to save HW resources and it can create a single encapsulation rule that will encapsulate all flows. In the last case the HW must calculate the value since the SW can't configure the same value for all flows.

Example for such a use case:
Group 0:
Match 5 tuple
Actions: NAT + counter + jump to group 2

Group 2
Match *
Actions: VXLAN encap

In the above case the application only use one HW resource for encapsulation.

I hope the use case is clearer to you

Quoted 40 lines

Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
Signed-off-by Ori Kam <[email protected]>
---
   lib/ethdev/rte_flow.h | 49
Quoted 8 lines
Quoted 8 lines
+++++++++++++++++++++++++++++++++++++++++++
lib/ethdev/rte_flow.h rte_flow_calc_table_hash(uint16_t port_id,
Quoted 7 lines
   1 file changed, 49 insertions(+)
lib/ethdev/rte_flow.h +0 -0
index affdc8121b..3989b089dd 100644
@@ -6753,6 +6753,55 @@ rte_flow_calc_table_hash(uint16_t port_id,
const
Quoted 23 lines
Quoted 14 lines
struct rte_flow_template_table
lib/ethdev/rte_flow.h rte_flow_calc_table_hash(uint16_t port_id, · line 6753
Quoted 1 line
lib/ethdev/rte_flow.h +0 -0
   			 const struct rte_flow_item pattern[], uint8_t
pattern_template_index,
Quoted 11 lines
lib/ethdev/rte_flow.h +9 -0
   			 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 {
Quoted 8 lines
lib/ethdev/rte_flow.h rte_flow_calc_table_hash(uint16_t port_id, const struct rte_flow_template_table · line 6766
Quoted 2 lines
lib/ethdev/rte_flow.h +2 -0
+	/* Calculate entropy placed in UDP source port field. */
+	RTE_FLOW_ENTROPY_DEST_UDP_SRC_PORT,
And source and destination are used together but for different purposes it is very hard to follow which is used for which purpose. I'd avoid term "dest" in the enum naming. May be present "flow" is already good enough to highlight that it is per-flow? rte_flow_encap_hash? rte_flow_encap_field_hash?
Quoted 2 lines
I'm open to any suggestions, this enum is supposed to show to which field the HW insert the calculated value. This field is defined by the
encapsulation

Quoted 8 lines

Quoted 1 line
protocol. For example, VXLAN the hash is stored in source port, while in
NVGRE it is stored in
Quoted 4 lines
flow_id field. The destination field also impact the size.
What do you think about:
RTE_FLOW_ENCAP_HASH_SRC_PORT?
Sounds better.

Great

Quoted 9 lines

Quoted 2 lines
What about if we change the destination to enum that will hold the
destination tunnel type
Quoted 2 lines
RTE_FLOW_TUNNEL_TYPE_VXLAN,
RTE_FLOW_TUNNEL_TYPE_NVGRE
It could be an option as well, but binds tunnel type to size of hash to be calculated. It looks OK right now, but may be wrong in the future.

Lets start with this and if needed update.

Quoted 46 lines

Quoted 20 lines
Quoted 11 lines
Quoted 11 lines
lib/ethdev/rte_flow.h +11 -0
+	/* 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.
+ *
Quoted 8 lines
lib/ethdev/rte_flow.h rte_flow_calc_table_hash(uint16_t port_id, const struct rte_flow_template_table · line 6781
Quoted 4 lines
lib/ethdev/rte_flow.h +4 -0
+ * @param[in] port_id
+ *   Port identifier of Ethernet device.
+ * @param[in] pattern
+ *   The values to be used in the entropy calculation.
Is it inner packet fields? Should all fields be used for hash calculation? May be it is better to describe as inner packet headers? How does app know which headers to extract and provide?
Quoted 1 line
The fields are the outer fields that will become inner fields, after the
encapsulation.
Quoted 1 line
The fields are dependent on the HW (in standard case 5 tuple). but applications
can /should set
Quoted 1 line
all the fields he got from the packet, at the end those are the fields that the
HW will see.
OK I see.
Quoted 5 lines
Quoted 5 lines
lib/ethdev/rte_flow.h rte_flow_calc_table_hash(uint16_t port_id, const struct rte_flow_template_table
Quoted 5 lines
lib/ethdev/rte_flow.h +4 -0
+ * @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,
Quoted 7 lines
Quoted 5 lines
lib/ethdev/rte_flow.h rte_flow_calc_table_hash(uint16_t port_id, · line 6787
Quoted 2 lines
lib/ethdev/rte_flow.h +2 -0
+ *   so entropy[0] is the MSB.
+ *   The number of bytes is based on the destination field type.f
API contract is a bit unclear here. May be it is safer to provide buffer size explicitly?
The size of the field is defined by the destination field, which in turn is defined
by the
Quoted 3 lines
protocol.
I don't think adding size has any meaning when you know that the value is

Quoted 8 lines

going to be set
Quoted 2 lines
in source port which has the size of 16 bites.
Based on enum suggestion of tunnel type. I think it will also explain the dest
and size. What do you think?
I see, but IMHO it is still very unsafe. Simply too error prone and there is not way to catch it. IMHO buffer size will not overload it too much, but will make API clearer and safer.

O.K we can add buffer size, even just for the ability to validate.

Quoted 28 lines

Quoted 12 lines
Quoted 12 lines
lib/ethdev/rte_flow.h rte_flow_calc_table_hash(uint16_t port_id, const struct rte_flow_template_table
Quoted 12 lines
lib/ethdev/rte_flow.h +9 -0
+ * @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
Quoted 15 lines
Quoted 14 lines
entropy
lib/ethdev/rte_flow.h rte_flow_calc_table_hash(uint16_t port_id, const struct rte_flow_template_table
Quoted 5 lines
lib/ethdev/rte_flow.h +5 -0
+ *               or the dest is not supported.
+ */
+__rte_experimental
+int
+rte_flow_calc_encap_entropy(uint16_t port_id, const struct rte_flow_item
pattern[],
lib/ethdev/rte_flow.h rte_flow_calc_table_hash(uint16_t port_id, · line 6802
Quoted 1 line
lib/ethdev/rte_flow.h +1 -0
+			    enum rte_flow_entropy_dest dest_field, uint8_t
*entropy,
Quoted 5 lines
lib/ethdev/rte_flow.h +2 -0
+			    struct rte_flow_error *error);
+
   #ifdef __cplusplus
   }
   #endif