lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Tue, 15 Jul 2014 18:18:02 +0200
From:	Veaceslav Falico <vfalico@...il.com>
To:	Alexei Starovoitov <alexei.starovoitov@...il.com>
Cc:	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	Jay Vosburgh <j.vosburgh@...il.com>,
	Andy Gospodarek <andy@...yhouse.net>
Subject: Re: [PATCH net-next 2/2] bonding: make hard-coded defines
 configurable at build

On Tue, Jul 15, 2014 at 08:48:01AM -0700, Alexei Starovoitov wrote:
>On Tue, Jul 15, 2014 at 3:15 AM, Veaceslav Falico <vfalico@...il.com> wrote:
>> CC: Jay Vosburgh <j.vosburgh@...il.com>
>> CC: Andy Gospodarek <andy@...yhouse.net>
>> Signed-off-by: Veaceslav Falico <vfalico@...il.com>
>> ---
>>  drivers/net/bonding/Kconfig   | 16 ++++++++++++++++
>>  drivers/net/bonding/bonding.h |  6 +++---
>>  2 files changed, 19 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/net/bonding/Kconfig b/drivers/net/bonding/Kconfig
>> index 7b1a0fa..28fb3af 100644
>> --- a/drivers/net/bonding/Kconfig
>> +++ b/drivers/net/bonding/Kconfig
>> @@ -15,3 +15,19 @@ menuconfig BONDING
>>
>>           To compile this driver as a module, choose M here: the module
>>           will be called bonding.
>> +
>> +if BONDING
>> +
>> +config BOND_MAX_VLAN_ENCAP
>> +       int "Maximum number of stacked vlans on top of bonding"
>> +       default "2"
>> +
>
>I don't think we should allow changing these defaults so easily.
>Not a single HW supports 3 vlan tags. There is no standard for it either.
>Why you would ever change this?

There have been discussions about vlan nestings for bonding, and the
outcome was that more than 2 are possible. Also, iirc, no standard limits
it to only 2.

I'm not sure about the "changing these defaults so easily" - this default
limits the depth at which we traverse the vlan tree when sending packets in
arp monitor, so it has no actual impact on the work of vlans themselves.

>
>> +config BOND_MAX_ARP_TARGETS
>> +       int "Maximum number of ip targets arp monitor supports"
>> +       default "16"
>> +
>> +config BOND_DEFAULT_MIIMON
>> +       int "Default miimon monitoring frequency in milliseconds"
>> +       default "100"
>
>or this?

This is the default value chosen when there's no configuration/illegal
configuration, so it's a good point to configure it at build.

>imo existing built-ins are fine and adding extra knobs just scary.
>Users will have different numbers here and somebody would
>need to make sure that all different defaults still work.
>We should be minimizing the number of knobs instead.

These defaults are scalable by their nature, and there are people
maintaining their own patches to change them. So making them available to
be configured at compile time is a good thing to do, I think.
--
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ