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 <or...@nvidia.com>
> Acked-by: Dariusz Sosnowski <dsosnow...@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?
