RFC: how to control device specific features. sysfs or mod param?

RFC: how to control device specific features. sysfs or mod param?

[Peter P Waskiewicz Jr]

This is a general question to folks to get some kind of consensus on
controlling device-specific modes.  Currently in ixgbe, I can have two
different modes of our Flow Director mechanism.  One is the current one
in use today, the other is part of a patchset for programming n-tuple
filters that will be submitted soon.

My question is I want to toggle the underlying hardware mode to use one
or the other filter mechanism.  I can either do this using a module
parameter, which I'd like to avoid, or I can do this in a sysfs
parameter.  What do people think is the best approach?  Is there another
option I'm not considering here?

Thanks,
-PJ Waskiewicz

Re: RFC: how to control device specific features. sysfs or mod param?

[David Miller]

From: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>
Date: Sat, 05 Dec 2009 01:55:55 -0800

> My question is I want to toggle the underlying hardware mode to use one
> or the other filter mechanism.  I can either do this using a module
> parameter, which I'd like to avoid, or I can do this in a sysfs
> parameter.  What do people think is the best approach?  Is there another
> option I'm not considering here?

Other than sysfs another option to consider is trying to fit
this into the ethtool framework somehow.

Re: RFC: how to control device specific features. sysfs or mod param?

[Peter P Waskiewicz Jr]

On Sat, 2009-12-05 at 02:13 -0800, David Miller wrote:
> From: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>
> Date: Sat, 05 Dec 2009 01:55:55 -0800
> 
> > My question is I want to toggle the underlying hardware mode to use one
> > or the other filter mechanism.  I can either do this using a module
> > parameter, which I'd like to avoid, or I can do this in a sysfs
> > parameter.  What do people think is the best approach?  Is there another
> > option I'm not considering here?
> 
> Other than sysfs another option to consider is trying to fit
> this into the ethtool framework somehow.

Yes, I looked at either ethtool or extending any of the existing
rtnetlink interfaces.  But my problem with those is this setting is very
specific to my hardware, and I'm not sure anyone else could benefit from
this.

I could try and make it as generic as possible, say pass a 32 or 64-bit
generic bitfield to a driver through an ethtool operation, and each
driver would apply some secret sauce based on the bitfield?

The sysfs option seems somewhat natural though.  It's part of the driver
itself, and would be a toggle switch for that specific driver.

I have no attachment to any of these options.  I just want whatever is
maintainable, makes sense, and if others can benefit, that's a great
bonus.

-PJ

Re: RFC: how to control device specific features. sysfs or mod param?

[David Miller]

From: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>
Date: Sat, 05 Dec 2009 02:22:53 -0800

> Yes, I looked at either ethtool or extending any of the existing
> rtnetlink interfaces.  But my problem with those is this setting is very
> specific to my hardware, and I'm not sure anyone else could benefit from
> this.
> 
> I could try and make it as generic as possible, say pass a 32 or 64-bit
> generic bitfield to a driver through an ethtool operation, and each
> driver would apply some secret sauce based on the bitfield?

We support device specific statistics in a nice way in ethtool, why
don't we do something similar for device specific settings?

A variable length array of names (strings) and values.

This is pretty straightforward for what %99.9999 of uses will be,
boolean enables.  If we make the value type a u32 we can handle pretty
much all the other cases as well.

Re: RFC: how to control device specific features. sysfs or mod param?

[Peter P Waskiewicz Jr]

On Sat, 2009-12-05 at 02:25 -0800, David Miller wrote:
> From: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>
> Date: Sat, 05 Dec 2009 02:22:53 -0800
> 
> > Yes, I looked at either ethtool or extending any of the existing
> > rtnetlink interfaces.  But my problem with those is this setting is very
> > specific to my hardware, and I'm not sure anyone else could benefit from
> > this.
> > 
> > I could try and make it as generic as possible, say pass a 32 or 64-bit
> > generic bitfield to a driver through an ethtool operation, and each
> > driver would apply some secret sauce based on the bitfield?
> 
> We support device specific statistics in a nice way in ethtool, why
> don't we do something similar for device specific settings?
> 
> A variable length array of names (strings) and values.
> 
> This is pretty straightforward for what %99.9999 of uses will be,
> boolean enables.  If we make the value type a u32 we can handle pretty
> much all the other cases as well.

That does make sense.  I'll try and put something together to make this
work.

Thanks Dave,
-PJ