On Thu, 10 Sept 2026 at 14:20, Burakov, Anatoly <[email protected]> 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 <[email protected]> > >> --- > > > > 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. -- David Marchand
