Matthew Wilcox wrote: > Wouldn't it be more useful to have the iov/N directories > be a symlink to the actual pci_dev used by the virtual > function? The main concern here is that a VF may be disabed such as when PF enter D3 state or undergo an reset and thus be plug-off, but user won't re-configure the VF in case the PF return back to working state. > >> +For network device, there are: >> + - /sys/bus/pci/devices/BB:DD.F/iov/N/mac >> + - /sys/bus/pci/devices/BB:DD.F/iov/N/vlan >> + (value update will notify PF driver) > > We already have tools to set the MAC and VLAN parameters > for network devices. Do you mean Ethtool? If yes, it is impossible for SR-IOV since the configuration has to be done in PF side, rather than VF. > > I'm not 100% convinced about this API. The assumption > here is that the driver will do it, but I think it should > probably be in the core. The driver probably wants to be Our concern is that the PF driver may put an default state when it is loaded so that SR-IOV can work without any user level configuration, but of course the driver won't dynamically change it. Do u mean we remove this ability? > notified that the PCI core is going to create a virtual > function, and would it please prepare to do so, but I'm > not convinced this should be triggered by the driver. > How would the driver decide to create a new virtual > function? > > > From my reading of the SR-IOV spec, this isn't how it's > supposed to work. The device is supposed to be a fully > functional PCI device that on demand can start peeling > off virtual functions; it's not supposed to boot up and > initialise all its virtual functions at once. The spec defines either we enable all VFs or Disable. Per VF enabling is not supported. Is this what you concern? Thanks, eddie -- 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
