[PATCH v6 1/2] net/iavf: accept up to 32k unicast MAC addresses

[Burakov, Anatoly]

On 9/10/2026 2:13 PM, Burakov, Anatoly wrote:
> On 9/4/2026 2:28 PM, 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.
>>
>> Signed-off-by: David Marchand <david.marchand at redhat.com>
>> ---
> 
> On another note, I don't think this is even compatible with ethdev API.
> 
> In `ethdev_driver.h`:
> 
> struct __rte_cache_aligned rte_eth_dev_data {
>      ...
>      /**
>       * Device Ethernet link addresses.
>       * All entries are unique.
>       * The first entry (index zero) is the default address.
>       */
>      struct rte_ether_addr *mac_addrs;
>      /** Bitmap associating MAC addresses to pools */
>      uint64_t mac_pool_sel[RTE_ETH_NUM_RECEIVE_MAC_ADDR];
>      ...
> }
> 
> example of this bitmap in rte_eth_dev_mac_addr_remove:
> 
>      /* Update NIC */
>      dev->dev_ops->mac_addr_remove(dev, index);
> 
>      /* Update address in NIC data structure */
>      rte_ether_addr_copy(&null_mac_addr, &dev->data->mac_addrs[index]);
> 
>      /* reset pool bitmap */
>      dev->data->mac_pool_sel[index] = 0;
> 
>      rte_ethdev_trace_mac_addr_remove(port_id, addr);
> 
> meaning, the mac_addrs array and the mac_pool_sel have the same 
> limitation because they are indexed by the same index.
> 
> RTE_ETH_NUM_RECEIVE_MAC_ADDR is defined as 128, so correct me if I'm 
> wrong here, but according to ethdev API one cannot have more than 128 
> MAC addresses?
> 

I would even go as far as to suggest that ethdev API should probably 
check max MAC addrs number to make sure it doesn't exceed the size of 
RTE_ETH_NUM_RECEIVE_MAC_ADDR, because otherwise that's a latent 
potential buffer overrun?

-- 
Thanks,
Anatoly