Message-ID: <C5551D9AAB213A418B7FD5E4A6F30A0789282B02@ORSMSX108.amr.corp.intel.com>
Date:	Thu, 5 Mar 2015 00:34:05 +0000
From:	"Rose, Gregory V" <gregory.v.rose@...el.com>
To:	"Kirsher, Jeffrey T" <jeffrey.t.kirsher@...el.com>,
	David Miller <davem@...emloft.net>,
	Linux Netdev List <netdev@...r.kernel.org>
CC:	"Brandeburg, Jesse" <jesse.brandeburg@...el.com>,
	"Nelson, Shannon" <shannon.nelson@...el.com>,
	"Ronciak, John" <john.ronciak@...el.com>
Subject: RE: [Fwd: Re: [PATCH -next] net: i40e: fix build, depends on
 CONFIGFS_FS]


> -------- Forwarded Message --------
> From: David Miller <davem@...emloft.net>
> To: rdunlap@...radead.org
> Cc: netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
> linux.nics@...el.com, jeffrey.t.kirsher@...el.com
> Subject: Re: [PATCH -next] net: i40e: fix build, depends on CONFIGFS_FS
> Date: Tue, 3 Mar 2015 15:02:07 -0500
> 

[snip]

> 
> Intel guys, I am furiously mad.
> 
> I've told you guys a thousand times to use portable, reasonable mechanisms
> to configure your hardware.  Using facilities that can be used for other
> cards from other vendors with similar facilities.

We're sorry for causing heartburn on this however the very technology we're attempting to configure is itself not portable.  Dell NPAR is a vendor specific vertical technology that bypasses and subverts the standard industry technology for I/O partitioning - i.e. SR-IOV.  We looked for ways to do this using standard tools found three issues.

	* The 'ip link' command would be used for bandwidth partitioning
	* ethtool would be used for permanently committing the bandwidth values to non-volatile RAM
	* We cannot autocommit the BW settings to NVM in the 'ip link' tool because of customer requirements

We felt requiring users to use two separate tools to configure the same area of HW functionality seemed onerous to us.  And polluting the ip and ethtool utilities with Dell NPAR specific feature support means there will be many non-Dell systems carrying code that could cause problems.

> 
> If such portable netdevice configuration frameworks do not exist, create
> it.

See above for our problem with doing so in this case.

Dell will be the only vendor selling systems with Ethernet NICs that support this feature.  Dell will be providing documentation to their users about how to use configfs for configuration of this feature.  Dell will be taking the customer calls that result from any issues that arise.

Anyone who doesn't want this configfs functionality is free to compile it out and not use it and it is turned off by default.

> 
> Every time you make a device specific mechanism for configuration, a small
> kitten dies somewhere in the world.
> 
> Please remove all of this configfs crap for twiddling bandwidth et al.
> knobs, before I do it for you.

We'll do that if you insist but keep in mind that there is also some confusing direction coming from Greg KH regarding use of configfs.

Here:

http://marc.info/?l=linux-netdev&m=135792876523408&w=2

And Here:

http://marc.info/?l=linux-netdev&m=142074512422335&w=2

We were told to go ahead and use configfs because that's why it's part of the kernel - a standard interface that is published and known.
 
If you still want us to rip this out and rewrite it all then we can go back to Dell and tell them that the Linux maintainers have shot this configuration mechanism down and that we're working on a different approach but in that case I'd really like your ideas and thoughts about the issues I describe above with using the 'ip' and 'ethtool' commands.

Thanks and regards,

- Greg

Powered by blists - more mailing lists