[v2,1/3] lib/ethdev: add ethdev op to get hash index
Checks
Commit Message
From: Vamsi Attunuru <vattunuru@marvell.com>
Some networking devices may use custom algos for computing
hash indices and spread the packets accordingly.
Patch adds an eth_dev op to get the hash index correspond
to the given hash value received in the initial packet on
the given port.
Some of the applications compute hash index from the hash
value received in the initial packet and than configure
the rxq to lcore mapping to make sure the mapped lcore/rxq
would receive the upcoming traffic that has similar hash.
Such applications may use these API to get the hash index
used by the PMD for spreading those traffic.
Signed-off-by: Vamsi Attunuru <vattunuru@marvell.com>
---
lib/librte_ethdev/rte_ethdev.c | 13 +++++++++++++
lib/librte_ethdev/rte_ethdev.h | 20 ++++++++++++++++++++
lib/librte_ethdev/rte_ethdev_core.h | 5 +++++
lib/librte_ethdev/rte_ethdev_version.map | 3 +++
4 files changed, 41 insertions(+)
Comments
On 10/15/2019 10:52 AM, vattunuru@marvell.com wrote:
> From: Vamsi Attunuru <vattunuru@marvell.com>
>
> Some networking devices may use custom algos for computing
> hash indices and spread the packets accordingly.
>
> Patch adds an eth_dev op to get the hash index correspond
> to the given hash value received in the initial packet on
> the given port.
>
> Some of the applications compute hash index from the hash
> value received in the initial packet and than configure
> the rxq to lcore mapping to make sure the mapped lcore/rxq
> would receive the upcoming traffic that has similar hash.
> Such applications may use these API to get the hash index
> used by the PMD for spreading those traffic.
Hi Vamsi,
Can you please describe this usecase?
If the application is receiving the packet, it already knows which queue it is
coming from, what is the benefit of the getting hash index?
The concern is adding a new API which is specific to a use case and HW and won't
be used in long term. That will only create technical dept for us.
>
> Signed-off-by: Vamsi Attunuru <vattunuru@marvell.com>
<...>
> -----Original Message-----
> From: dev <dev-bounces@dpdk.org> On Behalf Of Ferruh Yigit
> Sent: Tuesday, October 15, 2019 10:17 PM
> To: Vamsi Krishna Attunuru <vattunuru@marvell.com>; dev@dpdk.org
> Cc: arybchenko@solarflare.com; Jerin Jacob Kollanukkaran
> <jerinj@marvell.com>; thomas@monjalon.net
> Subject: Re: [dpdk-dev] [PATCH v2 1/3] lib/ethdev: add ethdev op to get hash
> index
>
> On 10/15/2019 10:52 AM, vattunuru@marvell.com wrote:
> > From: Vamsi Attunuru <vattunuru@marvell.com>
> >
> > Some networking devices may use custom algos for computing hash
> > indices and spread the packets accordingly.
> >
> > Patch adds an eth_dev op to get the hash index correspond to the given
> > hash value received in the initial packet on the given port.
> >
> > Some of the applications compute hash index from the hash value
> > received in the initial packet and than configure the rxq to lcore
> > mapping to make sure the mapped lcore/rxq would receive the upcoming
> > traffic that has similar hash.
> > Such applications may use these API to get the hash index used by the
> > PMD for spreading those traffic.
>
> Hi Vamsi,
>
> Can you please describe this usecase?
> If the application is receiving the packet, it already knows which queue it is
> coming from, what is the benefit of the getting hash index?
Hi Ferruh,
I think the commit msg is incomplete and did not explain the use case clearly, my apologies.
Actual usecase is when application precalculates the hash value using some hashlib for a specific type of packet headers with the same hash key that's configured in the HW, application would compute hash_index as hash % reta_size and predict the packets on the computed queue index. But these hash_index computation might be different from PMD/HW computed index(based it's algo design). To fix those disparity, these API been introduced which can be used during configuration time to have
required lcore-rq mapping.
>
> The concern is adding a new API which is specific to a use case and HW and
> won't be used in long term. That will only create technical dept for us.
>
> >
> > Signed-off-by: Vamsi Attunuru <vattunuru@marvell.com>
>
> <...>
On 10/15/2019 6:28 PM, Vamsi Krishna Attunuru wrote:
>
>
>> -----Original Message-----
>> From: dev <dev-bounces@dpdk.org> On Behalf Of Ferruh Yigit
>> Sent: Tuesday, October 15, 2019 10:17 PM
>> To: Vamsi Krishna Attunuru <vattunuru@marvell.com>; dev@dpdk.org
>> Cc: arybchenko@solarflare.com; Jerin Jacob Kollanukkaran
>> <jerinj@marvell.com>; thomas@monjalon.net
>> Subject: Re: [dpdk-dev] [PATCH v2 1/3] lib/ethdev: add ethdev op to get hash
>> index
>>
>> On 10/15/2019 10:52 AM, vattunuru@marvell.com wrote:
>>> From: Vamsi Attunuru <vattunuru@marvell.com>
>>>
>>> Some networking devices may use custom algos for computing hash
>>> indices and spread the packets accordingly.
>>>
>>> Patch adds an eth_dev op to get the hash index correspond to the given
>>> hash value received in the initial packet on the given port.
>>>
>>> Some of the applications compute hash index from the hash value
>>> received in the initial packet and than configure the rxq to lcore
>>> mapping to make sure the mapped lcore/rxq would receive the upcoming
>>> traffic that has similar hash.
>>> Such applications may use these API to get the hash index used by the
>>> PMD for spreading those traffic.
>>
>> Hi Vamsi,
>>
>> Can you please describe this usecase?
>> If the application is receiving the packet, it already knows which queue it is
>> coming from, what is the benefit of the getting hash index?
>
> Hi Ferruh,
>
> I think the commit msg is incomplete and did not explain the use case clearly, my apologies.
> Actual usecase is when application precalculates the hash value using some hashlib for a specific type of packet headers with the same hash key that's configured in the HW, application would compute hash_index as hash % reta_size and predict the packets on the computed queue index. But these hash_index computation might be different from PMD/HW computed index(based it's algo design). To fix those disparity, these API been introduced which can be used during configuration time to have
> required lcore-rq mapping.
Does application tries to predict in which queue a specific flow will land? And
configure RETA table OR do the lcore-queue mapping accordingly?
Not sure if other PMDs need this too but API seems trivial and it doesn't affect
existing code, so no objection from my end for the API. Can you please check the
unit test comments?
>
>
>>
>> The concern is adding a new API which is specific to a use case and HW and
>> won't be used in long term. That will only create technical dept for us.
>>
>>>
>>> Signed-off-by: Vamsi Attunuru <vattunuru@marvell.com>
>>
>> <...>
>
On 10/15/2019 10:52 AM, vattunuru@marvell.com wrote:
> From: Vamsi Attunuru <vattunuru@marvell.com>
>
> Some networking devices may use custom algos for computing
> hash indices and spread the packets accordingly.
>
> Patch adds an eth_dev op to get the hash index correspond
> to the given hash value received in the initial packet on
> the given port.
>
> Some of the applications compute hash index from the hash
> value received in the initial packet and than configure
> the rxq to lcore mapping to make sure the mapped lcore/rxq
> would receive the upcoming traffic that has similar hash.
> Such applications may use these API to get the hash index
> used by the PMD for spreading those traffic.
>
> Signed-off-by: Vamsi Attunuru <vattunuru@marvell.com>
<...>
> @@ -364,6 +364,10 @@ typedef int (*rss_hash_conf_get_t)(struct rte_eth_dev *dev,
> struct rte_eth_rss_conf *rss_conf);
> /**< @internal Get current RSS hash configuration of an Ethernet device */
>
> +typedef int (*rss_hash_index_get_t)(struct rte_eth_dev *dev,
> + uint32_t hash, uint32_t *hash_idx);
> +/**< @internal Get RSS hash id of given hash value */
s/hash id/hash index/ ?
@@ -3140,6 +3140,19 @@ rte_eth_dev_rss_hash_conf_get(uint16_t port_id,
}
int
+rte_eth_dev_rss_hash_index_get(uint16_t port_id,
+ uint32_t hash, uint32_t *hash_idx)
+{
+ struct rte_eth_dev *dev;
+
+ RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
+ dev = &rte_eth_devices[port_id];
+ RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->rss_hash_index_get, -ENOTSUP);
+ return eth_err(port_id, (*dev->dev_ops->rss_hash_index_get)(dev, hash,
+ hash_idx));
+}
+
+int
rte_eth_dev_udp_tunnel_port_add(uint16_t port_id,
struct rte_eth_udp_tunnel *udp_tunnel)
{
@@ -3306,6 +3306,26 @@ rte_eth_dev_rss_hash_conf_get(uint16_t port_id,
struct rte_eth_rss_conf *rss_conf);
/**
+ * Get hash index of the given hash value that received in mbuf from this port.
+ *
+ * @param port_id
+ * The port identifier of the Ethernet device.
+ * @param hash
+ * The hash value used to compute hash_idx.
+ * @param hash_idx
+ * Where to store the computed hash_idx
+ * @return
+ * - (0) if successful.
+ * - (-ENODEV) if port identifier is invalid.
+ * - (-EIO) if device is removed.
+ * - (-ENOTSUP) if hardware doesn't support RSS.
+ */
+__rte_experimental
+int
+rte_eth_dev_rss_hash_index_get(uint16_t port_id,
+ uint32_t hash, uint32_t *hash_idx);
+
+ /**
* Add UDP tunneling port for a specific type of tunnel.
* The packets with this UDP port will be identified as this type of tunnel.
* Before enabling any offloading function for a tunnel, users can call this API
@@ -364,6 +364,10 @@ typedef int (*rss_hash_conf_get_t)(struct rte_eth_dev *dev,
struct rte_eth_rss_conf *rss_conf);
/**< @internal Get current RSS hash configuration of an Ethernet device */
+typedef int (*rss_hash_index_get_t)(struct rte_eth_dev *dev,
+ uint32_t hash, uint32_t *hash_idx);
+/**< @internal Get RSS hash id of given hash value */
+
typedef int (*eth_dev_led_on_t)(struct rte_eth_dev *dev);
/**< @internal Turn on SW controllable LED on an Ethernet device */
@@ -595,6 +599,7 @@ struct eth_dev_ops {
rss_hash_update_t rss_hash_update; /** Configure RSS hash protocols. */
rss_hash_conf_get_t rss_hash_conf_get; /** Get current RSS hash configuration. */
+ rss_hash_index_get_t rss_hash_index_get; /** Get RSS hash idx. */
reta_update_t reta_update; /** Update redirection table. */
reta_query_t reta_query; /** Query redirection table. */
@@ -283,4 +283,7 @@ EXPERIMENTAL {
# added in 19.08
rte_eth_read_clock;
+
+ # added in 19.11
+ rte_eth_dev_rss_hash_index_get;
};