[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1341252445.2590.12.camel@bwh-desktop.uk.solarflarecom.com>
Date: Mon, 2 Jul 2012 19:07:25 +0100
From: Ben Hutchings <bhutchings@...arflare.com>
To: David Miller <davem@...emloft.net>
CC: <ogerlitz@...lanox.com>, <roland@...nel.org>,
<yevgenyp@...lanox.com>, <oren@...lanox.com>,
<netdev@...r.kernel.org>, <hadarh@...lanox.co.il>
Subject: Re: [PATCH net-next 06/10] {NET,IB}/mlx4: Add device managed flow
steering firmware API
On Mon, 2012-07-02 at 01:34 -0700, David Miller wrote:
> From: Or Gerlitz <ogerlitz@...lanox.com>
> Date: Mon, 2 Jul 2012 10:55:28 +0300
>
> > On 7/2/2012 12:42 AM, David Miller wrote:
> >> [...] Module parameters stink because every driver is going to provide
> >> the knob differently, with a different name, and different
> >> semantics. This creates a terrible user experience, and I will not
> >> allow it.
> >
> > OK, so if looking on what we are left with on the table, seems that
> > sysfs entry on the mlx4_core
> > level (as we do for the port link type {IB, Eth} or IB port MTU) could
> > be fine here, Roland, agree?
>
> No way.
>
> You have to create a real interface, that other vendors with similar
> chips can consistently use.
But there may not be enough commonality to define a non- vendor-specific
API. And ethtool really isn't a good way to expose parameters that are
per-controller rather than per-net-device, particularly if changing them
may disrupt all running net devices on that controller and not just the
one used to invoke SIOCETHTOOL.
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 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