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 <[email protected]>
---
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 <[email protected]>
--
Thanks,
Anatoly
