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

[Alexander Duyck <alexander.h.duyck@intel.com>]

On 08/04/2014 08:45 AM, Edward Cree wrote:
> On 02/08/14 01:25, Ethan Zhao wrote:
>> 在 2014年8月1日，下午8:15，Edward Cree <ecree@solarflare.com> 写道：
>>> On 01/08/14 04:51, Ethan Zhao wrote:
>>>> So far seems no driver call pci_sriov_set_totalvfs() with numvfs = 0
>>>> and the patch will change the behavior of the drivers, but it will
>>>> definitely change the test cases and documents related to IOV.
>>> As for test cases and documents, I can't find any in the kernel tree
>> I mean some test cases or doc that are out of kernel tree ... such as some Distro,
>> not only Hardware vendors.
> I was under the impression that we don't care about breaking out-of-tree
> code.  Distros should be (and it looks like most are) using the
> kernel-doc to generate their documentation, and the kernel-doc doesn't
> say anything about what happens when passing 0.
> 
> -Edward

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.

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.

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.

Thanks,

Alex