On Tue, Oct 01, 2024 at 02:14:36PM +0100, Bruce Richardson wrote: > On Tue, Oct 01, 2024 at 11:12:54AM +0200, David Marchand wrote: > > Following two upstream Linux kernel changes (see links), the mac address > > of a iavf port, serviced by a i40e PF driver, is lost when the DPDK iavf > > driver probes the port again (which may be triggered at any point of a > > DPDK application life, like when a reset event is triggered by the PF). > > > > A first change results in the mac address of the VF port being reset to 0 > > during the VIRTCHNL_OP_GET_VF_RESOURCES query. > > The i40e PF driver change is pretty obscure but the iavf Linux driver does > > set VIRTCHNL_VF_OFFLOAD_USO. > > Announcing such a capability in the DPDK driver does not seem to be an > > issue, so do the same in DPDK to keep the legacy behavior of a fixed mac. > > > > Then a second change in the kernel results in the VF mac address being > > cleared when the VF driver remove its default mac address. > > Removing (unicast or multicast) mac addresses is not done by the kernel VF > > driver in general. > > The reason why the DPDK driver behaves like this is undocumented > > (and lost because the authors are not active anymore). > > Aligning DPDK behavior to the upstream kernel driver is safer in any > > case. > > > > Cc: sta...@dpdk.org > > > > Link: > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=fed0d9f13266 > > Link: > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ceb29474bbbc > > Signed-off-by: David Marchand <david.march...@redhat.com> > > --- > > Seems reasonable to me. > > Acked-by: Bruce Richardson <bruce.richard...@intel.com>
Applied to dpdk-next-net-intel. Thanks, /Bruce
