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 -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
