On Fri, 2012-07-20 at 13:29 -0600, Chris Friesen wrote: > On 07/20/2012 11:42 AM, Ben Hutchings wrote: > > > > The ethtool API is typically used for net device operations that can be > > largely devolved to individual drivers, and which the network stack can > > mostly ignore (though offload features are an historical exception to > > this). It started with Ethernet link settings, but many operations are > > applicable (and implemented by) other types of network device. > > That (potentially) accounts for all network devices, but it leaves all > the other devices that could export virtual functions. > > Why should I need to use a different API to enable virtual functions on > my network device and my storage controller? Indeed; I was merely making the point that it would be quite valid to use that means for setting VF network parameters for any network device that supports IOV. > (And why should "ethtool" or "ip" care that it's a virtual function?) VFs may be assigned to a guest which is not fully trusted by the hypervisor or privileged domain. (This can sometimes be true for PFs too, depending on the capabilities of the hypervisor and guest OS.) Some configuration may therefore need to be done via a trusted PF. > What Don and I are suggesting is that the concept of virtual functions > is a PCI thing, so it should be dealt with at the PCI layer. Regardless > of the type of device the export of virtual functions is conceptually > the same thing, so it should use the same API. > > Once the device exists, then domain-specific APIs would be used to > configure it the same way that they would configure a physical device. To an extent, but not entirely. Currently, the assigned MAC address and (optional) VLAN tag for each networking VF are configured via the PF net device (though this is done though the rtnetlink API rather than ethtool). Ben. -- Ben Hutchings, Staff Engineer, Solarflare Not speaking for my employer; that's the marketing department's job. They asked us to note that Solarflare product names are trademarked. -- 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
