Re: [PATCH v7 4/4] net/iavf: accept up to 32k unicast MAC addresses

["Burakov, Anatoly" <anatoly.burakov@intel.com>]

On 9/14/2026 10:17 AM, David Marchand wrote:
> E810 hardware provides 32k switch lookups.
> Thanks to this, it is possible to allow a lot more secondary mac
> addresses than what is possible today.
> 
> In practice, the maximum number of macs available per port may be lower
> and depends on usage by other (trusted?) VFs on the same PF.
> There is no way to figure out this limit but to try adding a mac address
> and get an error from the PF driver.
> 
> Mailbox exchanges are limited to IAVF_AQ_BUF_SZ, segment messages
> accordingly.
> 
> Since unicast and multicast addresses arrays are sized with two
> different constants, prefer RTE_DIM() whenever possible.
> 
> Signed-off-by: David Marchand <david.marchand@redhat.com>
> ---
> Changes since v6:
> - reused helper added in previous commit,
> - used RTE_DIM() instead of macro constants,
> 
> Changes since v5:
> - separated from series that went in next-net,
> - rebased,
> 
> Changes since v4:
> - rebased,
> 
> Changes since v2:
> - added an entry in release notes,
> - removed unneeded temp variable,
> 
> Changes since v1:
> - fixed buffer overflow on mailbox messages during port restart/VF reset,
> 
> ---

<snip>

>   
> diff --git a/drivers/net/intel/iavf/iavf_vchnl.c b/drivers/net/intel/iavf/iavf_vchnl.c
> index decfae3182..418a7e897e 100644
> --- a/drivers/net/intel/iavf/iavf_vchnl.c
> +++ b/drivers/net/intel/iavf/iavf_vchnl.c
> @@ -1712,8 +1712,8 @@ iavf_send_eth_addr_list(struct iavf_adapter *adapter, const char *caller,
>   void
>   iavf_add_del_secondary_mac_addr(struct iavf_adapter *adapter, bool add)
>   {
> +	uint8_t cmd_buffer[IAVF_ETH_ADDR_CMD_SIZE(IAVF_ETH_ADDR_PER_REQ)] = {0};
>   	struct iavf_info *vf = IAVF_DEV_PRIVATE_TO_VF(adapter);
> -	uint8_t cmd_buffer[IAVF_ETH_ADDR_CMD_SIZE(RTE_DIM(vf->mac_addrs))] = {0};
>   	struct virtchnl_ether_addr_list *list;
>   
>   	list = (struct virtchnl_ether_addr_list *)cmd_buffer;
> @@ -1730,6 +1730,12 @@ iavf_add_del_secondary_mac_addr(struct iavf_adapter *adapter, bool add)
>   			memcpy(vc_addr->addr, addr->addr_bytes, sizeof(addr->addr_bytes));
>   			vc_addr->type = VIRTCHNL_ETHER_ADDR_EXTRA;
>   		}
> +
> +		if (list->num_elements == IAVF_ETH_ADDR_PER_REQ) {
> +			if (iavf_send_eth_addr_list(adapter, __func__, list, add))
> +				return;
> +			list->num_elements = 0;
> +		}
>   	}

Nitpick over my previous comment, but I really don't understand why 
resetting a list in the middle of a loop is 1) not a nested loop, 
cognitively speaking, and 2) more clear than just having every inner 
loop start at 0 and end at ETH_ADDR_PER_REQ while having an outer loop 
go from zero until RTE_DIM(vf->mac_addrs) which is what ends up 
happening when this problem is modeled anyway. This to me reads like an 
attempt at avoiding having a nested loop by breaking the loop up in the 
middle, all for the sake of not having nested loops.

However, it works and not worth a respin, so

Acked-by: Anatoly Burakov <anatoly.burakov@intel.com>

-- 
Thanks,
Anatoly