From mboxrd@z Thu Jan 1 00:00:00 1970 From: Don Dutile Subject: Re: New commands to configure IOV features Date: Fri, 20 Jul 2012 11:56:45 -0400 Message-ID: <50097FBD.9080202@redhat.com> References: <5003DC9B.8000706@broadcom.com> <5005BD00.4090106@redhat.com> <5005D45D.1040302@genband.com> <20120717.141153.46613285253481776.davem@davemloft.net> <500978C7.5050004@genband.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: David Miller , yuvalmin@broadcom.com, bhutchings@solarflare.com, gregory.v.rose@intel.com, netdev@vger.kernel.org, linux-pci@vger.kernel.org To: Chris Friesen Return-path: In-Reply-To: <500978C7.5050004@genband.com> Sender: linux-pci-owner@vger.kernel.org List-Id: netdev.vger.kernel.org On 07/20/2012 11:27 AM, Chris Friesen wrote: > On 07/17/2012 03:11 PM, David Miller wrote: >> From: Chris Friesen >> Date: Tue, 17 Jul 2012 15:08:45 -0600 >> >>> From that perspective a sysfs-based interface is ideal since it is >>> directly scriptable. >> >> As is anything ethtool or netlink based, since we have 'ethtool' >> and 'ip' for scripting. > > I'm not picky...whatever works. > > To me the act of creating virtual functions seems generic enough (I'm aware of SR-IOV capable storage controllers, I'm sure there is other hardware as well) that ethtool/ip don't really seem like the most appropriate tools for the job. > Yes, and then there are 'other network' controllers too ... IB which I don't know if it adheres to ethtool, since it's not an Ethernet device ... isn't that why they call it Infiniband ... ;-) ) In the telecom space, they use NTBs and PCI as a 'network' ... I know, not common in Linux space, and VFs in that space aren't being discussed (that I've ever heard), but another example where 'network' != Ethernet, so ethtool doesn't solve PCI-level configuration/use. So, VFs are a PCI defined entity, so their enable/disablement should be handled by PCI. Conversely, when dealing with networking attributes of a PCI-VF ethernet-nic, networking tools should be used, not PCI tools. > I would have thought it would make more sense as a generic PCI functionality, in which case I'm not aware of an existing binary tool that would be a logical choice to extend. > > Chris