> On Wed, 15 Nov 2023 08:14:06 -0800 Stephen Hemminger wrote: > > Jakub is right that in an ideal world, this could all be managed by > > userspace. But the management of network devices in Linux is a > > dumpster fire! Every distro invents there own solution, last time I > > counted there were six different tools claiming to be the "one network > > device manager to rule them all". And that doesn't include all the > > custom scripts and vendor appliances. > > To be clear, I thought Long Li was saying that the goal is work around cases where > VF is probed before netvsc. That seems like something that can be prevented by > the hypervisor. Hi Jakub, I think you misunderstood my response, here is the response again. (quote) The current workflow in the kernel looks like this: 1. VF net device is created and expose to user-mode 2. VF is bonded to NETVSC (if NETVSC exists on the system) With the current kernel behavior, the user-mode can possibly see the VF after 1, and before 2 when VF is bonded. When this happens, the user-mode doesn't know if the VF will be bonded in the future (it may never happen on systems without NETVSC). In this case, it doesn't know if it should configure the VF or not. (end quote) The problem is not that VF could be probed before netvsc. The problem is that it's possible that VF is probed, exposed to user-mode earlier than netvsc has a chance to bond it. Thanks, Long
