Re: [PATCH] PCI: handle pci_sriov_set_totalvfs(dev, 0)

[Edward Cree <ecree@solarflare.com>]

On 04/08/14 17:40, Alexander Duyck wrote:
> Edward,
>
> The concern isn't what is out there, but what will come of it as a
> result.  The question is should we allow setting the value to 0 to
> change the behavior from disabling the override to essentially disabling
> SR-IOV.
I still don't see why any driver would set an override and then want to
disable it; moreover, it seems like unnatural semantics to use 0 for
this (something like -1 would seem much more sensible) since most people
will expect 0 to mean, well, 0.

> If we consider it acceptable to use 0 as a disable value, and there are
> several people on this thread that don't, the secondary issue of this is
> the error return for sriov_numvfs_store which hasn't been addressed.
> Should we still be returning ERANGE if SR-IOV has essentially been
> disabled, or should we be returning some other error such as EBUSY,
> ENOMEM, ENODEV, or ENOSYS to indicate that there are no resources
> available for SR-IOV.
In my opinion we should still return ERANGE, as that's the immediate
error - user requested more VFs than were advertised.  I.e. it's exactly
the same as if someone requested 8 VFs on igb after igb reduced totalvfs
to 7; we don't return a different error code to say _why_ igb can only
support 7 VFs.  I don't see why 0 is special in this regard.

> I think you would be much better off just implementing sriov_configure
> for your PCI driver and placing your own error return there if you
> cannot allocate a vswitch.
It just seems silly to advertise VFs when we already know at PF probe
time that we've failed to allocate the vswitch.

-Edward