Subject: Re: [PATCH net-next 02/12] tipc: Add "max_ports" configuration parameter

From: Paul Gortmaker <[email-masked]>
Date: Fri, 31 May 2013 13:48:56 -0400

On 13-05-30 06:49 PM, David Miller wrote:
> From: Paul Gortmaker <[email-masked]>
> Date: Thu, 30 May 2013 15:36:07 -0400
> 
>> From: Erik Hugne <[email-masked]>
>>
>> Introduce the "max_ports" module parameter, which allows the maximum
>> number of ports supported by TIPC to be changed from the default value
>> at boot, or at module load time. Because of the way the port reference
>> table is structured and initiated, this value must be known at module
>> start time, and can not be changed later.
>>
>> Until now this value has been set via a macro, and hence things
>> have to be recompiled if the value is to be changed. The Kconfig
>> knob and the dead code intended to change this parameter at runtime
>> are dropped.
>>
>> Considering TIPC node addresses are unique on the entire node, the
>> 64k port limit has proven to be a little too strict.  We increase the
>> allowed max to 128k. This is safe since the protocol headers allow
>> for up to 2^32 -1 ports.
>>
>> Usage for module: "insmod tipc.ko max_ports=<value>" ; at boot, append
>> "tipc.max_ports=<value>" to the kernel command line.
>>
>> Signed-off-by: Erik Hugne <[email-masked]>
>> Reviewed-by: Jon Maloy <[email-masked]>
>> Signed-off-by: Paul Gortmaker <[email-masked]>
> 
> View compile time constants and module parameters as artificial
> limits, they are terrible and unnecessary.

I can't argue with that; I was thinking that the module param was
better than a recompile, but as you say, not having it at all is
yet better again.  I'll drop this patch, and if the reimplementation
isn't ready before 3.10-rc6, I'll just resend the series without it.

Thanks,
Paul.
--

> 
> There is no reason you cannot restructure this table so that you
> can dynamically size it at run time.
> 
> Please reimplement it in that way.
> 
> Thanks.
>