[RFC] per-nic module parameters

[RFC] per-nic module parameters

[Brice Goglin]

Hello,

We're working on making myri10ge module parameters per-nic. It looks
like ixgb already does so with the following macro in ixgb_param.c:

#define IXGB_PARAM_INIT { [0 ... IXGB_MAX_NIC] = OPTION_UNSET }
#define IXGB_PARAM(X, desc)                                     \
        static int __devinitdata X[IXGB_MAX_NIC+1]              \
                = IXGB_PARAM_INIT;                              \
        static unsigned int num_##X = 0;                        \
        module_param_array_named(X, X, int, &num_##X, 0);       \
        MODULE_PARM_DESC(X, desc);

Is this the recommended way to implement per-nic module params? Or
should we do something else?

Thanks,
Brice

Re: [RFC] per-nic module parameters

[Stephen Hemminger]

On Fri, 24 Oct 2008 22:09:35 +0200
Brice Goglin <brice@myri.com> wrote:

> Hello,
> 
> We're working on making myri10ge module parameters per-nic. It looks
> like ixgb already does so with the following macro in ixgb_param.c:
> 
> #define IXGB_PARAM_INIT { [0 ... IXGB_MAX_NIC] = OPTION_UNSET }
> #define IXGB_PARAM(X, desc)                                     \
>         static int __devinitdata X[IXGB_MAX_NIC+1]              \
>                 = IXGB_PARAM_INIT;                              \
>         static unsigned int num_##X = 0;                        \
>         module_param_array_named(X, X, int, &num_##X, 0);       \
>         MODULE_PARM_DESC(X, desc);
> 
> Is this the recommended way to implement per-nic module params? Or
> should we do something else?

Module parameters are bad. They are device specific and awkward for
any general configuration system to deal with. As much as possible,
please convert any module parameters to real interfaces like netlink,
ethtool, or sysfs.

Re: [RFC] per-nic module parameters

[Ben Hutchings]

Stephen Hemminger wrote:
> On Fri, 24 Oct 2008 22:09:35 +0200
> Brice Goglin <brice@myri.com> wrote:
> 
> > Hello,
> > 
> > We're working on making myri10ge module parameters per-nic. It looks
> > like ixgb already does so with the following macro in ixgb_param.c:
> > 
> > #define IXGB_PARAM_INIT { [0 ... IXGB_MAX_NIC] = OPTION_UNSET }
> > #define IXGB_PARAM(X, desc)                                     \
> >         static int __devinitdata X[IXGB_MAX_NIC+1]              \
> >                 = IXGB_PARAM_INIT;                              \
> >         static unsigned int num_##X = 0;                        \
> >         module_param_array_named(X, X, int, &num_##X, 0);       \
> >         MODULE_PARM_DESC(X, desc);
> > 
> > Is this the recommended way to implement per-nic module params? Or
> > should we do something else?
> 
> Module parameters are bad. They are device specific and awkward for
> any general configuration system to deal with. As much as possible,
> please convert any module parameters to real interfaces like netlink,
> ethtool, or sysfs.

I agree in principle.  However, every distribution uses modutils and allows
default module parameters to be set in the same way.  So it's easy to tell
customers how to configure module parameters persistently.  The same cannot
be said for ethtool, unfortunately.

Ben.

-- 
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.

Re: [RFC] per-nic module parameters

[Chris Snook]

Ben Hutchings wrote:
> Stephen Hemminger wrote:
>> On Fri, 24 Oct 2008 22:09:35 +0200
>> Brice Goglin <brice@myri.com> wrote:
>>
>>> Hello,
>>>
>>> We're working on making myri10ge module parameters per-nic. It looks
>>> like ixgb already does so with the following macro in ixgb_param.c:
>>>
>>> #define IXGB_PARAM_INIT { [0 ... IXGB_MAX_NIC] = OPTION_UNSET }
>>> #define IXGB_PARAM(X, desc)                                     \
>>>         static int __devinitdata X[IXGB_MAX_NIC+1]              \
>>>                 = IXGB_PARAM_INIT;                              \
>>>         static unsigned int num_##X = 0;                        \
>>>         module_param_array_named(X, X, int, &num_##X, 0);       \
>>>         MODULE_PARM_DESC(X, desc);
>>>
>>> Is this the recommended way to implement per-nic module params? Or
>>> should we do something else?
>> Module parameters are bad. They are device specific and awkward for
>> any general configuration system to deal with. As much as possible,
>> please convert any module parameters to real interfaces like netlink,
>> ethtool, or sysfs.
> 
> I agree in principle.  However, every distribution uses modutils and allows
> default module parameters to be set in the same way.  So it's easy to tell
> customers how to configure module parameters persistently.  The same cannot
> be said for ethtool, unfortunately.

That makes it a distribution problem, maybe something LSB should address.  ixgb 
inherits this code from e1000, which has been around a very, very long time. 
It's still a sin that they didn't strip it out when they derived ixgb from 
e1000, but it's a less severe sin than writing new module parameter code from 
scratch.

Sometimes there are legitimate reasons to use module parameters, but duplicating 
ethtool functionality doesn't qualify.  Those parameters that e1000 still 
carries are there because now that they've documented it and customers are using 
it, they can't ever remove it.  Telling your customers to use ETHTOOL_OPTS if 
their distro has /etc/sysconfig/network-scripts/ifcfg-eth* files, or pre-up if 
their distro has /etc/network/interfaces is not difficult.

Interface consistency is a worthwhile goal, but you're creating a bigger 
consistency problem in the kernel than you're solving in the distributions if 
you do this, and you make it very difficult to ever go back once you realize the 
mistake.

-- Chris