|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

Commit: [Unable to determine - patch format]
Author: Feifei Wang <wff_light at vip.163.com>

Subject: [v6 1/2] net/hinic3: Fix VXLAN TSO issue

This patch adds missing VXLAN TSO capability advertisement and removes a
conditional check that was preventing tunnel TSO capabilities from being
reported.

> 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;
>  }

[ ... ]

> @@ -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);

The removal of the NIC_F_HTN_CMDQ check means hinic3_dev_tnl_tso_support()
will now be called unconditionally. Inside that function, the individual
capability checks (HINIC3_SUPPORT_VXLAN_OFFLOAD, etc.) will guard each
feature. However, does this introduce any risk for hardware that does not
support the HTN command queue? Could calling hinic3_dev_tnl_tso_support()
on hardware without NIC_F_HTN_CMDQ support cause the driver to advertise
tunnel offload capabilities that the hardware cannot actually perform?

>  
>  	info->hash_key_size = HINIC3_RSS_KEY_SIZE;
>  	info->reta_size = HINIC3_RSS_INDIR_SIZE;

---

Commit: [Unable to determine - patch format]
Author: Feifei Wang <wff_light at vip.163.com>

Subject: [v6 2/2] net/hinic3: Modify SP230 VF device id

This patch changes the VF device ID for SP230 hardware from 0x3750 to
0x022a.

> 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 change looks fine for correctness. The new device ID follows the
pattern of being close to the PF device ID (0x0229 and 0x022a).

>  
>  #define HINIC3_DEV_ID_SP920	0x0224