From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com ([209.132.183.28]:25627 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751624Ab2GTP4y (ORCPT ); Fri, 20 Jul 2012 11:56:54 -0400 Message-ID: <50097FBD.9080202@redhat.com> Date: Fri, 20 Jul 2012 11:56:45 -0400 From: Don Dutile MIME-Version: 1.0 To: Chris Friesen CC: David Miller , yuvalmin@broadcom.com, bhutchings@solarflare.com, gregory.v.rose@intel.com, netdev@vger.kernel.org, linux-pci@vger.kernel.org Subject: Re: New commands to configure IOV features References: <5003DC9B.8000706@broadcom.com> <5005BD00.4090106@redhat.com> <5005D45D.1040302@genband.com> <20120717.141153.46613285253481776.davem@davemloft.net> <500978C7.5050004@genband.com> In-Reply-To: <500978C7.5050004@genband.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Sender: linux-pci-owner@vger.kernel.org List-ID: 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