[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5009B186.6000806@genband.com>
Date: Fri, 20 Jul 2012 13:29:10 -0600
From: Chris Friesen <chris.friesen@...band.com>
To: Ben Hutchings <bhutchings@...arflare.com>
CC: Don Dutile <ddutile@...hat.com>,
David Miller <davem@...emloft.net>, yuvalmin@...adcom.com,
gregory.v.rose@...el.com, netdev@...r.kernel.org,
linux-pci@...r.kernel.org
Subject: Re: New commands to configure IOV features
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? (And why should "ethtool"
or "ip" care that it's a virtual function?)
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.
Chris
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists