[PATCH v2 1/4] ethdev: introduce encap hash calculation

[Ferruh Yigit]

On 2/8/2024 9:09 AM, Ori Kam wrote:
> During encapsulation of a packet, it is possible to change some
> outer headers to improve flow destribution.
> For example, from VXLAN RFC:
> "It is recommended that the UDP source port number
> be calculated using a hash of fields from the inner packet --
> one example being a hash of the inner Ethernet frame's headers.
> This is to enable a level of entropy for the ECMP/load-balancing"
> 
> The tunnel protocol defines which outer field should hold this hash,
> but it doesn't define the hash calculation algorithm.
> 
> An application that uses flow offloads gets the first few packets
> (exception path) and then decides to offload the flow.
> As a result, there are two
> different paths that a packet from a given flow may take.
> SW for the first few packets or HW for the rest.
> When the packet goes through the SW, the SW encapsulates the packet
> and must use the same hash calculation as the HW will do for
> the rest of the packets in this flow.
> 
> the new function rte_flow_calc_encap_hash can query the hash value
> fromm the driver for a given packet as if the packet was passed
> through the HW.
> 
> Signed-off-by: Ori Kam <orika at nvidia.com>
> Acked-by: Dariusz Sosnowski <dsosnowski at nvidia.com>
> 

<...>

> +int
> +rte_flow_calc_encap_hash(uint16_t port_id, const struct rte_flow_item pattern[],
> +			 enum rte_flow_encap_hash_field dest_field, uint8_t hash_len,
> +			 uint8_t *hash, struct rte_flow_error *error)
> +{
> +	int ret;
> +	struct rte_eth_dev *dev;
> +	const struct rte_flow_ops *ops;
> +
> +	RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
> +	ops = rte_flow_ops_get(port_id, error);
> +	if (!ops || !ops->flow_calc_encap_hash)
> +		return rte_flow_error_set(error, ENOTSUP,
> +					  RTE_FLOW_ERROR_TYPE_UNSPECIFIED, NULL,
> +					  "calc encap hash is not supported");
> +	if ((dest_field == RTE_FLOW_ENCAP_HASH_FIELD_SRC_PORT && hash_len != 2) ||
> +	    (dest_field == RTE_FLOW_ENCAP_HASH_FIELD_NVGRE_FLOW_ID && hash_len != 1))
>

If there is a fixed mapping with the dest_field and the size, instead of
putting this information into check code, what do you think to put it
into the data structure?

I mean instead of using enum for dest_filed, it can be a struct that is
holding enum and its expected size, this clarifies what the expected
size for that field.

> +		return rte_flow_error_set(error, EINVAL,
> +					  RTE_FLOW_ERROR_TYPE_UNSPECIFIED, NULL,
> +					  "hash len doesn't match the requested field len");
> +	dev = &rte_eth_devices[port_id];
> +	ret = ops->flow_calc_encap_hash(dev, pattern, dest_field, hash, error);
>

'hash_len' is get by API, but it is not passed to dev_ops, does this
mean this information hardcoded in the driver as well, if so why
duplicate this information in driver instead off passing hash_len to driver?


> +	return flow_err(port_id, ret, error);
> +}
> diff --git a/lib/ethdev/rte_flow.h b/lib/ethdev/rte_flow.h
> index 1267c146e5..2bdf3a4a17 100644
> --- a/lib/ethdev/rte_flow.h
> +++ b/lib/ethdev/rte_flow.h
> @@ -6783,6 +6783,57 @@ rte_flow_calc_table_hash(uint16_t port_id, const struct rte_flow_template_table
>  			 const struct rte_flow_item pattern[], uint8_t pattern_template_index,
>  			 uint32_t *hash, struct rte_flow_error *error);
>  
> +/**
> + * @warning
> + * @b EXPERIMENTAL: this API may change without prior notice.
> + *
> + * Destination field type for the hash calculation, when encap action is used.
> + *
> + * @see function rte_flow_calc_encap_hash
> + */
> +enum rte_flow_encap_hash_field {
> +	/* Calculate hash placed in UDP source port field. */
> +	RTE_FLOW_ENCAP_HASH_FIELD_SRC_PORT,
> +	/* Calculate hash placed in NVGRE flow ID field. */
> +	RTE_FLOW_ENCAP_HASH_FIELD_NVGRE_FLOW_ID,
> +};
>

Indeed above enum represents a field in a network protocol, right?
Instead of having a 'RTE_FLOW_ENCAP_HASH_' specific one, can re-using
'enum rte_flow_field_id' work?