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

[Burakov, Anatoly]

On 9/10/2026 2:30 PM, David Marchand wrote:
> On Thu, 10 Sept 2026 at 14:20, Burakov, Anatoly
> <anatoly.burakov at intel.com> wrote:
>>
>> 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?
> 
> This limit is something that was put in place for VMDq.
> 
> I removed it in next-net (it did not hit main yet).
> https://git.dpdk.org/next/dpdk-next-net/commit?id=f9ddb36e00655e38c115502d5ee180d4fda633c0
> https://git.dpdk.org/next/dpdk-next-net/commit?id=31ea14ef354c8664482af27039ecd3c6130254b1
> 
> There may be some check missing in case a driver announces a
> max_mac_addrs larger than RTE_ETH_NUM_RECEIVE_MAC_ADDR with VMDq
> enabled.
> 
> 

OK, in that case I'll send AI to dig around ixgbe and see if we can 
tighten enforcement of this limit :)

-- 
Thanks,
Anatoly