On Tue, Oct 27, 2026 at 03:46:58PM +0000, Bruce Richardson wrote: > On Tue, Oct 27, 2026 at 02:02:46PM +0100, David Marchand wrote: > > On Tue, 27 Oct 2026 at 10:59, David Marchand <[email protected]> > > wrote: > > > > > > The MAC address removal was checking if the hardware supports VMDq > > > (I40E_FLAG_VMDQ) to decide whether to use pool-based removal. > > > However, ethdev only populates mac_pool_sel[] when VMDq mode is actually > > > configured. As a result, when VMDq is supported but not configured, > > > mac_pool_sel is 0 and no MAC address gets removed. > > > > > > Fix by checking if VMDq mode is configured, matching the condition > > > used by ethdev to manage mac_pool_sel[]. > > > > > > Bugzilla ID: 2074 > > > Fixes: 774365884bb8 ("net/i40e: fix MAC address removal") > > > > > > Signed-off-by: David Marchand <[email protected]> > > > > AI review raises a concern that dev_conf is the requested > > configuration and proposes to rely on mac_pool_sel[index] == 0. > > This should be safe since i40e max mac_addrs count is 64 but maybe > > worth adding a build check here. > > > > Bruce, wdyt? > > > I think it's fine. After a successful config, the dev_conf contains the > actually used config, so its fine to test against. And if the config is > unsuccessful, we shouldn't be calling this function at all. > > Acked-by: Bruce Richardson <[email protected]> > Applied to dpdk-next-net-intel,
Thanks, /Bruce
