On 31/07/14 18:55, Alexander Duyck wrote: > It sounds reasonable. My only real concern is the fact that the error > reported when attempting to enable the interface will be a ERANGE when > really a more appropriate error return might be something like a EBUSY > since it is the vswitch that is occupied. > > You might want to take a look at modifying sriov_numvfs_store so that if > the only option is 0 you return EBUSY for all non-zero values requested. > This way it will be more in sync with how we handle the case of > attempting to update the number of VFs when SR-IOV is already enabled. Seems mostly reasonable for sfc, but I wonder if EBUSY would necessarily be appropriate for all devices. Other devices might have other reasons why their driver_max_VFs is zero. So I think it's best to leave it as ERANGE - the proximate reason why numvfs can't be set is because totalvfs is 0; for the reason why totalvfs is 0, user can look at the logs. But I'm open to being persuaded otherwise. -Edward The information contained in this message is confidential and is intended for the addressee(s) only. If you have received this message in error, please notify the sender immediately and delete the message. Unless you are an addressee (or authorized to receive for an addressee), you may not use, copy or disclose to anyone this message or any information contained in this message. The unauthorized use, disclosure, copying or alteration of this message is strictly prohibited. -- 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
