[dpdk-dev] [PATCH v2 1/2] drivers/i40e: fix X722 macro absence result in compile
hi,yigit
Because of remove "#ifdef x722" will related with some prior patch
and need related folks to make agreement on that, so we need to make a
discuss later to get a conclusion. we definitely confidence that we will
get the better balance base on the code maintenance effective. so just
ignore this patch and i will rework new patch later. Thanks your great
review and also appricate konstanitin's suggestion!
On 10/19/2016 12:22 AM, Ferruh Yigit wrote:
> On 10/17/2016 10:54 AM, Ananyev, Konstantin wrote:
>> Hi Jeff,
>>
>>> hi, Konstantin
>>> Thanks your constructive suggestion. I don't think your question is
>>> silly and we also think about the code style simply and effective, but
>>> may be i would interpret the reason why we do that.
>>>
>>> 1) Sure, user definitely can choose to define the macro or not when
>>> building dpdk i40e PMD, but i don't think it is
>>> necessary to invoke a ret_config option to let up layer user freedom use
>>> it, because only the older version i40e driver does not support X722,
>>> the newer version i40e driver will always support X722, so the macro
>>> will be default hard code in the makefile. and we will use mac.type to
>>> distinguish the difference register configure in run time. So we may
>>> consider the macro just like a flag that highlight the difference of the
>>> shared code between X710 and X722, that would benify the X710/X722 pmd
>>> development but hardly no use to exposure to the up layer user.
>>>
>>> 2) i think the answer also could find from above. But i think if we
>>> develop go to a certain stage in the future, mute the macro or use
>>> script to remove them like the way from hw driver, for support all
>>> device types maybe not a bad idea, right?
>> Sorry, but I still didn't get it.
>> If i40e driver will always support X722 then why do we need that macro at
>> all?
>> Why just not to remove it completely then?
>> Same about run-time vs build-time choice:
>> If let say i40e_get_rss_key() has to behave in a different way, why not to
>> create
>> i40e_get_rss_key_x722() and use it when hw mactype is x7222?
>> Or at least inside i40e_get_rss_key() do something like:
>> if (hw->mac.type == I40E_MAC_X722) {...} else {...}
>> ?
>> Why instead you have to pollute whole i40e code with all these #ifdef
>> x7222/#else ...?
>> Obviously that looks pretty ugly and hard to maintain.
> It is not possible to remove "#ifdef x7222" from shared code, but what
> about removing it from DPDK piece of the code, and code as it is always
> defined?
>
> If this is OK, this patch is not more required.
> And the removing #ifdef work can be done in another patch later.
>
>> Konstantin
>
[dpdk-dev] [PATCH v2 1/2] drivers/i40e: fix X722 macro absence result in compile
On 10/17/2016 10:54 AM, Ananyev, Konstantin wrote:
> Hi Jeff,
>
>>
>> hi, Konstantin
>> Thanks your constructive suggestion. I don't think your question is
>> silly and we also think about the code style simply and effective, but
>> may be i would interpret the reason why we do that.
>>
>> 1) Sure, user definitely can choose to define the macro or not when
>> building dpdk i40e PMD, but i don't think it is
>> necessary to invoke a ret_config option to let up layer user freedom use
>> it, because only the older version i40e driver does not support X722,
>> the newer version i40e driver will always support X722, so the macro
>> will be default hard code in the makefile. and we will use mac.type to
>> distinguish the difference register configure in run time. So we may
>> consider the macro just like a flag that highlight the difference of the
>> shared code between X710 and X722, that would benify the X710/X722 pmd
>> development but hardly no use to exposure to the up layer user.
>>
>> 2) i think the answer also could find from above. But i think if we
>> develop go to a certain stage in the future, mute the macro or use
>> script to remove them like the way from hw driver, for support all
>> device types maybe not a bad idea, right?
>
> Sorry, but I still didn't get it.
> If i40e driver will always support X722 then why do we need that macro at all?
> Why just not to remove it completely then?
> Same about run-time vs build-time choice:
> If let say i40e_get_rss_key() has to behave in a different way, why not to
> create
> i40e_get_rss_key_x722() and use it when hw mactype is x7222?
> Or at least inside i40e_get_rss_key() do something like:
> if (hw->mac.type == I40E_MAC_X722) {...} else {...}
> ?
> Why instead you have to pollute whole i40e code with all these #ifdef
> x7222/#else ...?
> Obviously that looks pretty ugly and hard to maintain.
It is not possible to remove "#ifdef x7222" from shared code, but what
about removing it from DPDK piece of the code, and code as it is always
defined?
If this is OK, this patch is not more required.
And the removing #ifdef work can be done in another patch later.
> Konstantin
[dpdk-dev] [PATCH v2 1/2] drivers/i40e: fix X722 macro absence result in compile
hi, Konstantin Thanks your constructive suggestion. I don't think your question is silly and we also think about the code style simply and effective, but may be i would interpret the reason why we do that. 1) Sure, user definitely can choose to define the macro or not when building dpdk i40e PMD, but i don't think it is necessary to invoke a ret_config option to let up layer user freedom use it, because only the older version i40e driver does not support X722, the newer version i40e driver will always support X722, so the macro will be default hard code in the makefile. and we will use mac.type to distinguish the difference register configure in run time. So we may consider the macro just like a flag that highlight the difference of the shared code between X710 and X722, that would benify the X710/X722 pmd development but hardly no use to exposure to the up layer user. 2) i think the answer also could find from above. But i think if we develop go to a certain stage in the future, mute the macro or use script to remove them like the way from hw driver, for support all device types maybe not a bad idea, right? On 10/16/2016 9:31 PM, Ananyev, Konstantin wrote: > Hi Jeff, > >> -Original Message- >> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Jeff Guo >> Sent: Sunday, October 16, 2016 2:40 AM >> To: Zhang, Helin ; Wu, Jingjing > intel.com> >> Cc: dev at dpdk.org; Guo, Jia >> Subject: [dpdk-dev] [PATCH v2 1/2] drivers/i40e: fix X722 macro absence >> result in compile >> >> Since some register only be supported by X722 but may not be supported >> by other NICs, so add X722 macro to distinguish that to avoid compile error >> when the X722 macro is undefined. > > Two probably silly questions: > 1) So who will setup X722_SUPPORT macro? > Is that a user responsibility when he is building dpdk i40e PMD? > If so, why it is not a rte_config option? > 2) Why this all has to be build time decision? > Why nor run-time? > Why i40e driver can't support all devices (including x722) > and invoke different config functions (write different registers) > based on device type/id information? > As it does for other device types/ids? > > Konstantin
[dpdk-dev] [PATCH v2 1/2] drivers/i40e: fix X722 macro absence result in compile
Hi Jeff,
> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Jeff Guo
> Sent: Sunday, October 16, 2016 2:40 AM
> To: Zhang, Helin ; Wu, Jingjing intel.com>
> Cc: dev at dpdk.org; Guo, Jia
> Subject: [dpdk-dev] [PATCH v2 1/2] drivers/i40e: fix X722 macro absence
> result in compile
>
> Since some register only be supported by X722 but may not be supported
> by other NICs, so add X722 macro to distinguish that to avoid compile error
> when the X722 macro is undefined.
Two probably silly questions:
1) So who will setup X722_SUPPORT macro?
Is that a user responsibility when he is building dpdk i40e PMD?
If so, why it is not a rte_config option?
2) Why this all has to be build time decision?
Why nor run-time?
Why i40e driver can't support all devices (including x722)
and invoke different config functions (write different registers)
based on device type/id information?
As it does for other device types/ids?
Konstantin
>
> Fixes: d0a349409bd7 (?i40e: support AQ based RSS config?)
> Fixes: 001a1c0f98f4 ("ethdev: get registers width")
> Fixes: a0454b5d2e08 (?i40e: update device ids?)
> Fixes: 647d1eaf758b (?i40evf: support AQ based RSS config?)
> Fixes: 3058891a2b02 (?net/i40e: move PCI device ids to the driver?)
> Fixes: d9efd0136ac1 (?i40e: add EEPROM and registers dumping?)
> Signed-off-by: Jeff Guo
>
> ---
> v2:
> fix compile error when x722 macro is not define.
> ---
> drivers/net/i40e/i40e_ethdev.c| 36 ++-
> drivers/net/i40e/i40e_ethdev.h| 17 +++
> drivers/net/i40e/i40e_ethdev_vf.c | 27 +++
> drivers/net/i40e/i40e_regs.h | 96
> +++
> drivers/net/i40e/i40e_rxtx.c | 18 +++-
> 5 files changed, 191 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
> index d0640b9..920fd6d 100644
> --- a/drivers/net/i40e/i40e_ethdev.c
> +++ b/drivers/net/i40e/i40e_ethdev.c
> @@ -468,13 +468,17 @@ static const struct rte_pci_id pci_id_i40e_map[] = {
> { RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_10G_BASE_T4) },
> { RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_25G_B) },
> { RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_25G_SFP28) },
> +#ifdef X722_SUPPORT
> +#ifdef X722_A0_SUPPORT
> { RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_X722_A0) },
> +#endif /* X722_A0_SUPPORT */
> { RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_KX_X722) },
> { RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_QSFP_X722) },
> { RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_SFP_X722) },
> { RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_1G_BASE_T_X722) },
> { RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_10G_BASE_T_X722) },
> { RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_SFP_I_X722) },
> +#endif /* X722_SUPPORT */
> { .vendor_id = 0, /* sentinel */ },
> };
>
> @@ -3182,6 +3186,7 @@ i40e_get_rss_lut(struct i40e_vsi *vsi, uint8_t *lut,
> uint16_t lut_size)
> if (!lut)
> return -EINVAL;
>
> +#ifdef X722_SUPPORT
> if (pf->flags & I40E_FLAG_RSS_AQ_CAPABLE) {
> ret = i40e_aq_get_rss_lut(hw, vsi->vsi_id, TRUE,
> lut, lut_size);
> @@ -3190,12 +3195,15 @@ i40e_get_rss_lut(struct i40e_vsi *vsi, uint8_t *lut,
> uint16_t lut_size)
> return ret;
> }
> } else {
> +#endif /* X722_SUPPORT */
> uint32_t *lut_dw = (uint32_t *)lut;
> uint16_t i, lut_size_dw = lut_size / 4;
>
> for (i = 0; i < lut_size_dw; i++)
> lut_dw[i] = I40E_READ_REG(hw, I40E_PFQF_HLUT(i));
> +#ifdef X722_SUPPORT
> }
> +#endif /* X722_SUPPORT */
>
> return 0;
> }
> @@ -3213,6 +3221,7 @@ i40e_set_rss_lut(struct i40e_vsi *vsi, uint8_t *lut,
> uint16_t lut_size)
> pf = I40E_VSI_TO_PF(vsi);
> hw = I40E_VSI_TO_HW(vsi);
>
> +#ifdef X722_SUPPORT
> if (pf->flags & I40E_FLAG_RSS_AQ_CAPABLE) {
> ret = i40e_aq_set_rss_lut(hw, vsi->vsi_id, TRUE,
> lut, lut_size);
> @@ -3221,13 +3230,16 @@ i40e_set_rss_lut(struct i40e_vsi *vsi, uint8_t *lut,
> uint16_t lut_size)
> return ret;
> }
> } else {
> +#endif /* X722_SUPPORT */
> uint32_t *lut_dw = (uint32_t *)lut;
> uint16_t i, lut_size_dw = lut_size / 4;
>
> for (i = 0; i < lut_size_dw; i++)
> I40E_WRITE_REG(hw, I40E_PFQF_HLUT(i), lut_dw[i]);
>
[dpdk-dev] [PATCH v2 1/2] drivers/i40e: fix X722 macro absence result in compile
Since some register only be supported by X722 but may not be supported
by other NICs, so add X722 macro to distinguish that to avoid compile error
when the X722 macro is undefined.
Fixes: d0a349409bd7 (?i40e: support AQ based RSS config?)
Fixes: 001a1c0f98f4 ("ethdev: get registers width")
Fixes: a0454b5d2e08 (?i40e: update device ids?)
Fixes: 647d1eaf758b (?i40evf: support AQ based RSS config?)
Fixes: 3058891a2b02 (?net/i40e: move PCI device ids to the driver?)
Fixes: d9efd0136ac1 (?i40e: add EEPROM and registers dumping?)
Signed-off-by: Jeff Guo
---
v2:
fix compile error when x722 macro is not define.
---
drivers/net/i40e/i40e_ethdev.c| 36 ++-
drivers/net/i40e/i40e_ethdev.h| 17 +++
drivers/net/i40e/i40e_ethdev_vf.c | 27 +++
drivers/net/i40e/i40e_regs.h | 96 +++
drivers/net/i40e/i40e_rxtx.c | 18 +++-
5 files changed, 191 insertions(+), 3 deletions(-)
diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
index d0640b9..920fd6d 100644
--- a/drivers/net/i40e/i40e_ethdev.c
+++ b/drivers/net/i40e/i40e_ethdev.c
@@ -468,13 +468,17 @@ static const struct rte_pci_id pci_id_i40e_map[] = {
{ RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_10G_BASE_T4) },
{ RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_25G_B) },
{ RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_25G_SFP28) },
+#ifdef X722_SUPPORT
+#ifdef X722_A0_SUPPORT
{ RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_X722_A0) },
+#endif /* X722_A0_SUPPORT */
{ RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_KX_X722) },
{ RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_QSFP_X722) },
{ RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_SFP_X722) },
{ RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_1G_BASE_T_X722) },
{ RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_10G_BASE_T_X722) },
{ RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_SFP_I_X722) },
+#endif /* X722_SUPPORT */
{ .vendor_id = 0, /* sentinel */ },
};
@@ -3182,6 +3186,7 @@ i40e_get_rss_lut(struct i40e_vsi *vsi, uint8_t *lut,
uint16_t lut_size)
if (!lut)
return -EINVAL;
+#ifdef X722_SUPPORT
if (pf->flags & I40E_FLAG_RSS_AQ_CAPABLE) {
ret = i40e_aq_get_rss_lut(hw, vsi->vsi_id, TRUE,
lut, lut_size);
@@ -3190,12 +3195,15 @@ i40e_get_rss_lut(struct i40e_vsi *vsi, uint8_t *lut,
uint16_t lut_size)
return ret;
}
} else {
+#endif /* X722_SUPPORT */
uint32_t *lut_dw = (uint32_t *)lut;
uint16_t i, lut_size_dw = lut_size / 4;
for (i = 0; i < lut_size_dw; i++)
lut_dw[i] = I40E_READ_REG(hw, I40E_PFQF_HLUT(i));
+#ifdef X722_SUPPORT
}
+#endif /* X722_SUPPORT */
return 0;
}
@@ -3213,6 +3221,7 @@ i40e_set_rss_lut(struct i40e_vsi *vsi, uint8_t *lut,
uint16_t lut_size)
pf = I40E_VSI_TO_PF(vsi);
hw = I40E_VSI_TO_HW(vsi);
+#ifdef X722_SUPPORT
if (pf->flags & I40E_FLAG_RSS_AQ_CAPABLE) {
ret = i40e_aq_set_rss_lut(hw, vsi->vsi_id, TRUE,
lut, lut_size);
@@ -3221,13 +3230,16 @@ i40e_set_rss_lut(struct i40e_vsi *vsi, uint8_t *lut,
uint16_t lut_size)
return ret;
}
} else {
+#endif /* X722_SUPPORT */
uint32_t *lut_dw = (uint32_t *)lut;
uint16_t i, lut_size_dw = lut_size / 4;
for (i = 0; i < lut_size_dw; i++)
I40E_WRITE_REG(hw, I40E_PFQF_HLUT(i), lut_dw[i]);
I40E_WRITE_FLUSH(hw);
+#ifdef X722_SUPPORT
}
+#endif /* X722_SUPPORT */
return 0;
}
@@ -3508,8 +3520,10 @@ i40e_pf_parameter_init(struct rte_eth_dev *dev)
pf->lan_nb_qps = 1;
} else {
pf->flags |= I40E_FLAG_RSS;
+#ifdef X722_SUPPORT
if (hw->mac.type == I40E_MAC_X722)
pf->flags |= I40E_FLAG_RSS_AQ_CAPABLE;
+#endif /* X722_SUPPORT */
pf->lan_nb_qps = pf->lan_nb_qp_max;
}
qp_count += pf->lan_nb_qps;
@@ -6302,6 +6316,7 @@ i40e_set_rss_key(struct i40e_vsi *vsi, uint8_t *key,
uint8_t key_len)
return -EINVAL;
}
+#ifdef X722_SUPPORT
if (pf->flags & I40E_FLAG_RSS_AQ_CAPABLE) {
struct i40e_aqc_get_set_rss_key_data *key_dw =
(struct i40e_aqc_get_set_rss_key_data *)key;
@@ -6311,13 +6326,16 @@ i40e_set_rss_key(struct i40e_vsi *vsi, uint8_t *key,
uint8_t key_len)
PMD_INIT_LOG(ERR, "Failed to configure RSS key "
"via AQ");
} else {
+#endif /* X722_SUPPORT */
uint32_t *hash_key = (uint32_t *)key;
uint16_t i;
for (i = 0; i <=
[dpdk-dev] [PATCH v2 1/2] drivers/i40e: fix X722 macro absence result in compile
Since some register only be supported by X722 but may not be supported
by other NICs, so add X722 macro to distinguish that to avoid compile error
when the X722 macro is undefined.
Fixes: d0a349409bd7 (?i40e: support AQ based RSS config?)
Fixes: 001a1c0f98f4 ("ethdev: get registers width")
Fixes: a0454b5d2e08 (?i40e: update device ids?)
Fixes: 647d1eaf758b (?i40evf: support AQ based RSS config?)
Fixes: 3058891a2b02 (?net/i40e: move PCI device ids to the driver?)
Fixes: d9efd0136ac1 (?i40e: add EEPROM and registers dumping?)
Signed-off-by: Jeff Guo
---
v2:
fix compile error when x722 macro is not define.
---
drivers/net/i40e/i40e_ethdev.c| 36 ++-
drivers/net/i40e/i40e_ethdev.h| 17 +++
drivers/net/i40e/i40e_ethdev_vf.c | 27 +++
drivers/net/i40e/i40e_regs.h | 96 +++
drivers/net/i40e/i40e_rxtx.c | 18 +++-
5 files changed, 191 insertions(+), 3 deletions(-)
diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
index d0640b9..920fd6d 100644
--- a/drivers/net/i40e/i40e_ethdev.c
+++ b/drivers/net/i40e/i40e_ethdev.c
@@ -468,13 +468,17 @@ static const struct rte_pci_id pci_id_i40e_map[] = {
{ RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_10G_BASE_T4) },
{ RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_25G_B) },
{ RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_25G_SFP28) },
+#ifdef X722_SUPPORT
+#ifdef X722_A0_SUPPORT
{ RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_X722_A0) },
+#endif /* X722_A0_SUPPORT */
{ RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_KX_X722) },
{ RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_QSFP_X722) },
{ RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_SFP_X722) },
{ RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_1G_BASE_T_X722) },
{ RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_10G_BASE_T_X722) },
{ RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_SFP_I_X722) },
+#endif /* X722_SUPPORT */
{ .vendor_id = 0, /* sentinel */ },
};
@@ -3182,6 +3186,7 @@ i40e_get_rss_lut(struct i40e_vsi *vsi, uint8_t *lut,
uint16_t lut_size)
if (!lut)
return -EINVAL;
+#ifdef X722_SUPPORT
if (pf->flags & I40E_FLAG_RSS_AQ_CAPABLE) {
ret = i40e_aq_get_rss_lut(hw, vsi->vsi_id, TRUE,
lut, lut_size);
@@ -3190,12 +3195,15 @@ i40e_get_rss_lut(struct i40e_vsi *vsi, uint8_t *lut,
uint16_t lut_size)
return ret;
}
} else {
+#endif /* X722_SUPPORT */
uint32_t *lut_dw = (uint32_t *)lut;
uint16_t i, lut_size_dw = lut_size / 4;
for (i = 0; i < lut_size_dw; i++)
lut_dw[i] = I40E_READ_REG(hw, I40E_PFQF_HLUT(i));
+#ifdef X722_SUPPORT
}
+#endif /* X722_SUPPORT */
return 0;
}
@@ -3213,6 +3221,7 @@ i40e_set_rss_lut(struct i40e_vsi *vsi, uint8_t *lut,
uint16_t lut_size)
pf = I40E_VSI_TO_PF(vsi);
hw = I40E_VSI_TO_HW(vsi);
+#ifdef X722_SUPPORT
if (pf->flags & I40E_FLAG_RSS_AQ_CAPABLE) {
ret = i40e_aq_set_rss_lut(hw, vsi->vsi_id, TRUE,
lut, lut_size);
@@ -3221,13 +3230,16 @@ i40e_set_rss_lut(struct i40e_vsi *vsi, uint8_t *lut,
uint16_t lut_size)
return ret;
}
} else {
+#endif /* X722_SUPPORT */
uint32_t *lut_dw = (uint32_t *)lut;
uint16_t i, lut_size_dw = lut_size / 4;
for (i = 0; i < lut_size_dw; i++)
I40E_WRITE_REG(hw, I40E_PFQF_HLUT(i), lut_dw[i]);
I40E_WRITE_FLUSH(hw);
+#ifdef X722_SUPPORT
}
+#endif /* X722_SUPPORT */
return 0;
}
@@ -3508,8 +3520,10 @@ i40e_pf_parameter_init(struct rte_eth_dev *dev)
pf->lan_nb_qps = 1;
} else {
pf->flags |= I40E_FLAG_RSS;
+#ifdef X722_SUPPORT
if (hw->mac.type == I40E_MAC_X722)
pf->flags |= I40E_FLAG_RSS_AQ_CAPABLE;
+#endif /* X722_SUPPORT */
pf->lan_nb_qps = pf->lan_nb_qp_max;
}
qp_count += pf->lan_nb_qps;
@@ -6302,6 +6316,7 @@ i40e_set_rss_key(struct i40e_vsi *vsi, uint8_t *key,
uint8_t key_len)
return -EINVAL;
}
+#ifdef X722_SUPPORT
if (pf->flags & I40E_FLAG_RSS_AQ_CAPABLE) {
struct i40e_aqc_get_set_rss_key_data *key_dw =
(struct i40e_aqc_get_set_rss_key_data *)key;
@@ -6311,13 +6326,16 @@ i40e_set_rss_key(struct i40e_vsi *vsi, uint8_t *key,
uint8_t key_len)
PMD_INIT_LOG(ERR, "Failed to configure RSS key "
"via AQ");
} else {
+#endif /* X722_SUPPORT */
uint32_t *hash_key = (uint32_t *)key;
uint16_t i;
for (i = 0; i <=
