|SUCCESS| [V1,1/1] net/hinic3: Add VXLAN TSO function

dpdklab at iol.unh.edu dpdklab at iol.unh.edu
Wed May 20 14:56:28 CEST 2026


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

_AI Code Review_

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

commit f4eb788fbadb1e (assumed from context)
Author: Feifei Wang <wff_light at vip.163.com>
Subject: net/hinic3: Add VXLAN TSO function

The RTE_ETH_TX_OFFLOAD_VXLAN_TNL_TSO flag is added to support the VXLAN
TSO function.

> diff --git a/drivers/net/hinic3/hinic3_ethdev.c b/drivers/net/hinic3/hinic3_ethdev.c
> index f4eb788..fbadb1e 100644
> --- a/drivers/net/hinic3/hinic3_ethdev.c
> +++ b/drivers/net/hinic3/hinic3_ethdev.c
> @@ -696,7 +696,7 @@ hinic3_dev_infos_get(struct rte_eth_dev *dev, struct rte_eth_dev_info *info)
>  		RTE_ETH_TX_OFFLOAD_VLAN_INSERT | RTE_ETH_TX_OFFLOAD_IPV4_CKSUM |
>  		RTE_ETH_TX_OFFLOAD_UDP_CKSUM | RTE_ETH_TX_OFFLOAD_TCP_CKSUM |
>  		RTE_ETH_TX_OFFLOAD_SCTP_CKSUM |
> -		RTE_ETH_TX_OFFLOAD_OUTER_IPV4_CKSUM |
> +		RTE_ETH_TX_OFFLOAD_OUTER_IPV4_CKSUM | RTE_ETH_TX_OFFLOAD_VXLAN_TNL_TSO |
>  		RTE_ETH_TX_OFFLOAD_TCP_TSO | RTE_ETH_TX_OFFLOAD_MULTI_SEGS;

Does the code exceed 80 characters per line after adding
RTE_ETH_TX_OFFLOAD_VXLAN_TNL_TSO? The coding style guide requires lines
to be at most 80 characters unless absolutely necessary, and such long
assignments typically should be split across multiple lines for
readability.

Is the hardware capability to perform VXLAN TSO verified elsewhere in the
driver before advertising this offload? Simply adding the flag to
info->tx_offload_capa without corresponding hardware capability checks in
the transmit path could lead to incorrect packet processing.

Does the transmit function handle VXLAN TSO packets correctly? When
RTE_ETH_TX_OFFLOAD_VXLAN_TNL_TSO is advertised, the driver must properly
parse tunneled packets and configure the hardware descriptors accordingly
in the transmit path, otherwise packets may be corrupted or dropped.

>  	if (nic_dev->feature_cap & NIC_F_HTN_CMDQ)
>  		hinic3_dev_tnl_tso_support(info, nic_dev);

Does hinic3_dev_tnl_tso_support() already enable VXLAN TSO when
NIC_F_HTN_CMDQ is set? If so, does this patch create a conflict where
VXLAN TSO is unconditionally enabled above but also conditionally enabled
in hinic3_dev_tnl_tso_support(), potentially causing duplicate or
inconsistent capability advertisement?


More information about the test-report mailing list