[PATCH v7 4/4] net/iavf: accept up to 32k unicast MAC addresses
Burakov, Anatoly
anatoly.burakov at intel.com
Wed Sep 23 14:14:13 CEST 2026
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 at 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 at intel.com>
--
Thanks,
Anatoly
More information about the dev
mailing list