On Fri, Jan 15, 2021 at 10:06:19AM -0400, Jason Gunthorpe wrote:

On Thu, Jan 14, 2021 at 05:56:20PM -0800, Alexander Duyck wrote:

quoted

That said, it only works at the driver level. So if the firmware is
the one that is having to do this it also occured to me that if this
update happened on FLR that would probably be preferred.

FLR is not free, I'd prefer not to require it just for some
philosophical reason.

quoted

Since the mlx5 already supports devlink I don't see any reason why the
driver couldn't be extended to also support the devlink resource
interface and apply it to interrupts.

So you are OK with the PF changing the VF as long as it is devlink not
sysfs? Seems rather arbitary?

Leon knows best, but if I recall devlink becomes wonky when the VF
driver doesn't provide a devlink instance. How does it do reload of a
VF then?

I think you end up with essentially the same logic as presented here
with sysfs.

The reasons why I decided to go with sysfs are:
1. This MSI-X table size change is applicable to ALL devices in the world,
and not only netdev.
2. This is purely PCI field and apply equally with same logic to all
subsystems and not to netdev only.
3. The sysfs interface is the standard way of configuring PCI/core, not
devlink.
4. This is how orchestration software provisioning VFs already. It fits
real world usage of SR-IOV, not the artificial one that is proposed during
the discussion.

So the idea to use devlink just because mlx5 supports it, sound really
wrong to me. If it was other driver from another subsystem without
devlink support, the request to use devlink won't never come.

Thanks

quoted

quoted

It is possible for vfio to fake the MSI-X capability and limit what a
user can access, but I don't think that's what is being done here.

Yeah, I am assuming that is what is being done here.

Just to be really clear, that assumption is wrong

Jason