|SUCCESS| [RFC, 8/8] net/ipn3ke: replace use of DPDK-specific memcpy function

[dpdklab at iol.unh.edu]

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

_AI Code Review_

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

commit 20260519160823.1004973-2-bruce.richardson at intel.com
Author: Bruce Richardson <bruce.richardson at intel.com>
Subject: [RFC PATCH 1/8] net/ice: replace use of DPDK-specific memcpy function

This patch replaces rte_memcpy() with standard memcpy() in the ice
driver for control path operations including flow configuration.

> diff --git a/drivers/net/intel/ice/base/ice_osdep.h b/drivers/net/intel/ice/base/ice_osdep.h
> index 21c460d007..5d92cf5aa4 100644
> --- a/drivers/net/intel/ice/base/ice_osdep.h
> +++ b/drivers/net/intel/ice/base/ice_osdep.h
> @@ -14,7 +14,6 @@
>  #include <stdbool.h>
>  
>  #include <rte_common.h>
> -#include <rte_memcpy.h>
>  #include <rte_malloc.h>
>  #include <rte_memzone.h>
>  #include <rte_byteorder.h>
> @@ -210,7 +209,7 @@ struct __rte_packed_begin ice_virt_mem {
>  #define ice_free(h, m)      ((void)h, rte_free(m))
>  
>  #define ice_memset(a, b, c, d) memset((a), (b), (c))
> -#define ice_memcpy(a, b, c, d) rte_memcpy((a), (b), (c))
> +#define ice_memcpy(a, b, c, d) memcpy((a), (b), (c))

Does the macro need four parameters when the 'd' parameter is completely
unused? Should this instead be a three-parameter macro, or is 'd' used
elsewhere for documentation purposes?

> @@ -238,7 +237,7 @@ ice_memdup(__rte_unused struct ice_hw *hw, const void *src, size_t size,
>  
>  	p = ice_malloc(hw, size);
>  	if (p)
> -		rte_memcpy(p, src, size);
> +		memcpy(p, src, size);

Does ice_memdup() check whether ice_malloc() returned NULL before calling
memcpy()? The code appears to dereference p through memcpy() when p could
be NULL, causing a potential null pointer dereference in memcpy()->p.

[ ... ]

> diff --git a/drivers/net/intel/ice/ice_dcf_ethdev.c b/drivers/net/intel/ice/ice_dcf_ethdev.c
> index 0d3599d7d0..4fce59617e 100644
> --- a/drivers/net/intel/ice/ice_dcf_ethdev.c
> +++ b/drivers/net/intel/ice/ice_dcf_ethdev.c

[ ... ]

> @@ -1345,11 +1345,11 @@ ice_dcf_dev_rss_reta_update(struct rte_eth_dev *dev,
>  			lut[i] = reta_conf[idx].reta[shift];
>  	}
>  
> -	rte_memcpy(hw->rss_lut, lut, reta_size);
> +	memcpy(hw->rss_lut, lut, reta_size);
>  	/* send virtchnnl ops to configure rss*/
>  	ret = ice_dcf_configure_rss_lut(hw);
>  	if (ret) /* revert back */
> -		rte_memcpy(hw->rss_lut, lut, reta_size);
> +		memcpy(hw->rss_lut, lut, reta_size);
>  	free(lut);

Does the error path in ice_dcf_dev_rss_reta_update() restore the wrong
data? The temporary lut was modified in the loop above, so reverting by
copying lut back appears to restore the new values instead of the
original values.

[ ... ]

commit 20260519160823.1004973-5-bruce.richardson at intel.com
Author: Bruce Richardson <bruce.richardson at intel.com>
Subject: [RFC PATCH 4/8] net/ixgbe: replace use of DPDK-specific memcpy function

> diff --git a/drivers/net/intel/ixgbe/ixgbe_fdir.c b/drivers/net/intel/ixgbe/ixgbe_fdir.c
> index 0bdfbd411a..003f8240bd 100644
> --- a/drivers/net/intel/ixgbe/ixgbe_fdir.c
> +++ b/drivers/net/intel/ixgbe/ixgbe_fdir.c
> @@ -53,7 +53,7 @@
>  #define IPV6_ADDR_TO_MASK(ipaddr, ipv6m) do { \
>  	uint8_t ipv6_addr[16]; \
>  	uint8_t i; \
> -	rte_memcpy(ipv6_addr, (ipaddr), sizeof(ipv6_addr));\
> +	memcpy(ipv6_addr, (ipaddr), sizeof(ipv6_addr));\
>  	(ipv6m) = 0; \
>  	for (i = 0; i < sizeof(ipv6_addr); i++) { \
>  		if (ipv6_addr[i] == UINT8_MAX) \
> @@ -73,7 +73,7 @@
>  		else \
>  			ipv6_addr[i] = 0; \
>  	} \
> -	rte_memcpy((ipaddr), ipv6_addr, sizeof(ipv6_addr));\
> +	memcpy((ipaddr), ipv6_addr, sizeof(ipv6_addr));\
>  } while (0)

In the IPV6_ADDR_TO_MASK macro, does the code verify ipaddr is non-NULL
before dereferencing it in memcpy()? Both memcpy() calls could
dereference NULL if ipaddr is not validated by the callers.

commit 20260519160823.1004973-8-bruce.richardson at intel.com
Author: Bruce Richardson <bruce.richardson at intel.com>
Subject: [RFC PATCH 7/8] net/cpfl: replace use of DPDK-specific memcpy function

No issues found in this patch.

commit 20260519160823.1004973-9-bruce.richardson at intel.com  
Author: Bruce Richardson <bruce.richardson at intel.com>
Subject: [RFC PATCH 8/8] net/ipn3ke: replace use of DPDK-specific memcpy function

> diff --git a/drivers/net/intel/ipn3ke/ipn3ke_representor.c b/drivers/net/intel/ipn3ke/ipn3ke_representor.c
> index cd34d08055..281c025820 100644
> --- a/drivers/net/intel/ipn3ke/ipn3ke_representor.c
> +++ b/drivers/net/intel/ipn3ke/ipn3ke_representor.c
> @@ -137,7 +137,7 @@ ipn3ke_rpst_dev_start(struct rte_eth_dev *dev)
>  
>  	if (hw->retimer.mac_type == IFPGA_RAWDEV_RETIMER_MAC_TYPE_10GE_XFI) {
>  		/* Set mac address */
> -		rte_memcpy(((char *)(&val)),
> +		memcpy(((char *)(&val)),

Does ipn3ke_rpst_dev_start() safely handle potential size mismatches when
copying from mac_addrs into val? The sizeof(uint32_t) copy followed by
sizeof(uint16_t) suggests val's actual size might not match the copies.