|SUCCESS| [v6,2/2] net/hinic3: Modify SP230 VF device id

[dpdklab at iol.unh.edu]

Test-Label: ai-code-review
Test-Status: SUCCESS
https://dpdk.org/patch/164539

_AI Code Review_

=== Patch Review: series.patch (via Claude) ===
Review date: 2026-05-28

Reviewing series.patch against DPDK coding standards and contribution guidelines.

git sha: Not available (patch from mailing list)
Author: Feifei Wang <wangfeifei40 at huawei.com>
Subject: [v6 1/2] net/hinic3: Fix VXLAN TSO issue

This patch adds missing VXLAN TSO capability flag and removes a feature
capability check.

> diff --git a/drivers/net/hinic3/hinic3_ethdev.c b/drivers/net/hinic3/hinic3_ethdev.c
> index f4eb788..66c5c3a 100644
> --- a/drivers/net/hinic3/hinic3_ethdev.c
> +++ b/drivers/net/hinic3/hinic3_ethdev.c
> @@ -652,8 +652,12 @@ hinic3_dev_configure(struct rte_eth_dev *dev)
>  static void
>  hinic3_dev_tnl_tso_support(struct rte_eth_dev_info *info, struct hinic3_nic_dev *nic_dev)
>  {
> +	if (HINIC3_SUPPORT_VXLAN_OFFLOAD(nic_dev))
> +		info->tx_offload_capa |= RTE_ETH_TX_OFFLOAD_VXLAN_TNL_TSO;
> +
>  	if (HINIC3_SUPPORT_GENEVE_OFFLOAD(nic_dev))
>  		info->tx_offload_capa |= RTE_ETH_TX_OFFLOAD_GENEVE_TNL_TSO;
> +
>  	if (HINIC3_SUPPORT_IPXIP_OFFLOAD(nic_dev))
>  		info->tx_offload_capa |= RTE_ETH_TX_OFFLOAD_IPIP_TNL_TSO;
>  }

The addition of VXLAN TSO support looks reasonable and follows the same
pattern as GENEVE and IPIP checks.

> @@ -698,8 +702,8 @@ hinic3_dev_infos_get(struct rte_eth_dev *dev, struct rte_eth_dev_info *info)
>  		RTE_ETH_TX_OFFLOAD_SCTP_CKSUM |
>  		RTE_ETH_TX_OFFLOAD_OUTER_IPV4_CKSUM |
>  		RTE_ETH_TX_OFFLOAD_TCP_TSO | RTE_ETH_TX_OFFLOAD_MULTI_SEGS;
> -	if (nic_dev->feature_cap & NIC_F_HTN_CMDQ)
> -		hinic3_dev_tnl_tso_support(info, nic_dev);
> +
> +	hinic3_dev_tnl_tso_support(info, nic_dev);

Does removing the NIC_F_HTN_CMDQ check cause
hinic3_dev_tnl_tso_support() to be called unconditionally on hardware
that does not support tunnel offloads? The individual capability checks
inside hinic3_dev_tnl_tso_support() may protect against incorrect
capability advertisement, but does this change the behavior for devices
that previously would not call hinic3_dev_tnl_tso_support() at all?

---

git sha: Not available (patch from mailing list)
Author: Feifei Wang <wangfeifei40 at huawei.com>
Subject: [v6 2/2] net/hinic3: Modify SP230 VF device id

This patch modifies the VF device ID for SP230 NIC.

> diff --git a/drivers/net/hinic3/base/hinic3_csr.h b/drivers/net/hinic3/base/hinic3_csr.h
> index eceb34e..7cae241 100644
> --- a/drivers/net/hinic3/base/hinic3_csr.h
> +++ b/drivers/net/hinic3/base/hinic3_csr.h
> @@ -11,7 +11,7 @@
>  #define HINIC3_DEV_ID_VF_SP620	0x375F
>  
>  #define HINIC3_DEV_ID_SP230	0x0229
> -#define HINIC3_DEV_ID_VF_SP230	0x3750
> +#define HINIC3_DEV_ID_VF_SP230	0x022a

This changes the VF device ID from 0x3750 to 0x022a. Does this device ID
change affect existing deployments? Was the previous ID incorrect, or is
this a hardware revision change? If existing hardware with VF device ID
0x3750 is still in use, does removing this ID break support for those
devices?