[dpdk-dev,3/5] i40e: support selecting hash functions
Commit Message
Toeplitz and simple XOR hash functions are supported by
hardware, code changes are to tell the hardware which hash
function is selected according to the configuration.
Signed-off-by: Helin Zhang <helin.zhang@intel.com>
---
config/common_bsdapp | 1 +
config/common_linuxapp | 1 +
lib/librte_pmd_i40e/i40e_ethdev.c | 30 ++++++++++++++++++++++++++++++
3 files changed, 32 insertions(+)
Comments
2014-07-24 14:42, Helin Zhang:
> Toeplitz and simple XOR hash functions are supported by
> hardware, code changes are to tell the hardware which hash
> function is selected according to the configuration.
>
> Signed-off-by: Helin Zhang <helin.zhang@intel.com>
> +CONFIG_RTE_LIBRTE_I40E_HASH_FUNC_TOEPLITZ=y
Is it really a good idea to configure this kind of thing at build time?
Maybe yes, I'm not sure.
On Thu, Jul 24, 2014 at 09:59:23AM +0200, Thomas Monjalon wrote:
> Is it really a good idea to configure this kind of thing at build time?
> Maybe yes, I'm not sure.
Whether it's safe to set at runtime probably depends what happens to the card
if it gets changed. Do you have to reset the card or the port? Or is it OK if
it's more dynamic?
Matthew.
2014-07-24 01:01, Matthew Hall:
> On Thu, Jul 24, 2014 at 09:59:23AM +0200, Thomas Monjalon wrote:
> > Is it really a good idea to configure this kind of thing at build time?
> > Maybe yes, I'm not sure.
>
> Whether it's safe to set at runtime probably depends what happens to the card
> if it gets changed. Do you have to reset the card or the port? Or is it OK if
> it's more dynamic?
No, we can change configuration with rte_eth_dev_configure() before
initializing port. So it is truly configurable.
Requiring recompilation means it's not really configurable between 2 runs.
And it breaks binary packaging for Linux distributions.
Many things in DPDK are configured at build time. But we should wonder if
it's really a good design.
If no reboot of the card is needed then it's probably better to add it to one of the ethtool style APIs...
> -----Original Message-----
> From: Matthew Hall [mailto:mhall@mhcomputing.net]
> Sent: Thursday, July 24, 2014 4:15 PM
> To: Thomas Monjalon; Zhang, Helin
> Cc: dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH 3/5] i40e: support selecting hash functions
>
> If no reboot of the card is needed then it's probably better to add it to one of
> the ethtool style APIs...
> --
> Sent from my mobile device.
>
> On July 24, 2014 1:07:37 AM PDT, Thomas Monjalon
> <thomas.monjalon@6wind.com> wrote:
> >2014-07-24 01:01, Matthew Hall:
> >> On Thu, Jul 24, 2014 at 09:59:23AM +0200, Thomas Monjalon wrote:
> >> > Is it really a good idea to configure this kind of thing at build
> >time?
> >> > Maybe yes, I'm not sure.
> >>
> >> Whether it's safe to set at runtime probably depends what happens to
> >the card
> >> if it gets changed. Do you have to reset the card or the port? Or is
> >it OK if
> >> it's more dynamic?
> >
> >No, we can change configuration with rte_eth_dev_configure() before
> >initializing port. So it is truly configurable.
> >Requiring recompilation means it's not really configurable between 2
> >runs.
> >And it breaks binary packaging for Linux distributions.
> >
> >Many things in DPDK are configured at build time. But we should wonder
> >if it's really a good design.
Hi Thomas, Matt
Good points! Thank you guys!
Regards,
Helin
@@ -187,6 +187,7 @@ CONFIG_RTE_LIBRTE_I40E_16BYTE_RX_DESC=n
CONFIG_RTE_LIBRTE_I40E_QUEUE_NUM_PER_VF=4
# interval up to 8160 us, aligned to 2 (or default value)
CONFIG_RTE_LIBRTE_I40E_ITR_INTERVAL=-1
+CONFIG_RTE_LIBRTE_I40E_HASH_FUNC_TOEPLITZ=y
#
# Compile burst-oriented VIRTIO PMD driver
@@ -210,6 +210,7 @@ CONFIG_RTE_LIBRTE_I40E_16BYTE_RX_DESC=n
CONFIG_RTE_LIBRTE_I40E_QUEUE_NUM_PER_VF=4
# interval up to 8160 us, aligned to 2 (or default value)
CONFIG_RTE_LIBRTE_I40E_ITR_INTERVAL=-1
+CONFIG_RTE_LIBRTE_I40E_HASH_FUNC_TOEPLITZ=y
#
# Compile burst-oriented VIRTIO PMD driver
@@ -203,6 +203,7 @@ static int i40e_dev_rss_hash_update(struct rte_eth_dev *dev,
struct rte_eth_rss_conf *rss_conf);
static int i40e_dev_rss_hash_conf_get(struct rte_eth_dev *dev,
struct rte_eth_rss_conf *rss_conf);
+static void i40e_select_hash_function(struct i40e_hw *hw);
/* Default hash key buffer for RSS */
static uint32_t rss_key_default[I40E_PFQF_HKEY_MAX_INDEX + 1];
@@ -384,6 +385,9 @@ eth_i40e_dev_init(__rte_unused struct eth_driver *eth_drv,
return ret;
}
+ /* Select hash functions */
+ i40e_select_hash_function(hw);
+
/* Initialize the shared code (base driver) */
ret = i40e_init_shared_code(hw);
if (ret) {
@@ -3956,3 +3960,29 @@ i40e_pf_config_mq_rx(struct i40e_pf *pf)
return 0;
}
+
+static void
+i40e_select_hash_function(struct i40e_hw *hw)
+{
+ uint32_t reg;
+
+ reg = I40E_READ_REG(hw, I40E_GLQF_CTL);
+#ifdef RTE_LIBRTE_I40E_HASH_FUNC_TOEPLITZ
+ if (reg & I40E_GLQF_CTL_HTOEP_MASK) {
+ PMD_DRV_LOG(DEBUG, "Hash function already set to Hoeplitz\n");
+ return;
+ }
+ reg |= I40E_GLQF_CTL_HTOEP_MASK;
+#else
+ if (!(reg & I40E_GLQF_CTL_HTOEP_MASK)) {
+ PMD_DRV_LOG(DEBUG, "Hash function already set to "
+ "Simple XOR\n");
+ return;
+ }
+ reg &= ~I40E_GLQF_CTL_HTOEP_MASK;
+#endif
+ PMD_DRV_LOG(INFO, "Hash function set to %s\n",
+ (reg & I40E_GLQF_CTL_HTOEP_MASK) ? "Toeplitz" : "XOR");
+ I40E_WRITE_REG(hw, I40E_GLQF_CTL, reg);
+ I40E_WRITE_FLUSH(hw);
+}