|SUCCESS| [v5,1/1] net/hinic3: Fix VXLAN TSO issue

[dpdklab at iol.unh.edu]

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

_AI Code Review_

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

DPDK Patch Review

Commit: (SHA from patch file metadata)
Author: Feifei Wang <wangfeifei40 at huawei.com>
Subject: net/hinic3: Fix VXLAN TSO issue

This patch addresses a missing flag bit for VXLAN TSO support in the
hinic3 driver, which previously caused incorrect hardware capability
detection.

> From: Feifei Wang <wangfeifei40 at huawei.com>
> 
> VXLAN TSO lacks a flag bit, causing the processing function
> to determine that the hardware does not support it, leading
> to improper handling.
> 
> Fixes: 7608f0367d ("net/hinic3: add dev ops")
> Cc: stable at dpdk.org
> 
> Signed-off-by: Feifei Wang <wangfeifei40 at huawei.com>
> ---
>  drivers/net/hinic3/hinic3_ethdev.c | 8 ++++++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
> 
> 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;
> +

Does the patch unconditionally advertise VXLAN TSO capability when
HINIC3_SUPPORT_VXLAN_OFFLOAD is true, regardless of whether the hardware
truly supports TSO for VXLAN? This pattern differs from GENEVE and IPXIP
handling below.

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

Does removing the NIC_F_HTN_CMDQ feature check allow
hinic3_dev_tnl_tso_support() to advertise tunnel TSO capabilities on
hardware that doesn't support them? The original code gated this entire
function behind NIC_F_HTN_CMDQ. Are the individual
HINIC3_SUPPORT_*_OFFLOAD macros within hinic3_dev_tnl_tso_support()
sufficient to prevent advertising unsupported capabilities?

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