> > 1. Added module parameters sr_iov and probe_vf for controlling enablement of > > SRIOV mode. > > This sort of option is useful in many drivers, and ideally would be > specified in some generic way rather than a module parameters. However > I can't see a good way to make it configurable after the net device is > registered. > > Currently the in-tree drivers have: > > be2net: num_vfs > cxgb4: num_vfs [array] > igb: max_vfs > ixgbe: max_vfs > > Consider renaming 'sr_iov' to one of the above rather than adding to the > variation.
Good point, we probably should rename it. > > The 'probe_vf' parameter is very odd. Why do you think it is necessary > to make this a module parameter? It should be possible to bind and > unbind the driver from each VF dynamically via sysfs but this parameter > appears to restrict that. > We have same driver acting both as VF and PF, so once the VFs are being created (pci_enable_sriov), The probe function is being called for all of them. In many cases this is not what we want, but rather pass the vfs to guest OS. The module parameter is meant to ease the life of the administrator. > [...] > > 3. Added port_type_array as a module parameter to allow driver startup with > > ports configured as desired. > > In SRIOV mode, only ETH is supported, and this array is ignored; > > otherwise, > > for the case where the FW supports both port types (ETH and IB), the > > port_type_array parameter is used. > > By default, the port_type_array is set to configure both ports as IB. > [...] > > You seem to be saying that this can be reconfigured after startup - in > which case is the module parameter really necessary? Maybe I misunderstand. In SRIOV mode we don't allow dynamic link layer type changes, so the type is set by module parameter. Thanks, Yevgeny
