netdev - Re: [PATCH net-next 2/2] bonding: make hard-coded defines configurable at build

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]

Message-ID: <CAADnVQKeFOhbZOSHtpodnWb6OXem79jjozHm=Qgzz8PyVTryRg@mail.gmail.com>
Date:	Tue, 15 Jul 2014 11:55:29 -0700
From:	Alexei Starovoitov <alexei.starovoitov@...il.com>
To:	Veaceslav Falico <vfalico@...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 10:53 AM, Veaceslav Falico <vfalico@...il.com> wrote:
> On Tue, Jul 15, 2014 at 10:33:25AM -0700, Alexei Starovoitov wrote:
> ..snip...
>
>> For 3 vlan case to be useful, first somebody needs to define a meaning
>> for it and real use case. I haven't seen one.
>
>
> You also haven't seen switches that support it, however juniper switches do
> support them, as a quick google shows. I can guess that cisco can also be
> made to support them.

I don't think juniper switches support them either.
Please send the link to the spec.
Protocol parsers in HW fail to parse beyond two, since behavior
is undefined and it's considered invalid packet.
I'm talking about broadcom/intel/cisco asics.
Generally speaking I think it's a mistake of linux stack to support
any nested level. Not too long ago we saw issues with broken hw
offloads for basic qinq. I won't be surprised if creating triple stacked
vlan devices actually breaks all sort of things.

> I'll happily drop any/all of these configs if I'd see a reason NOT to add
> them. Till now I haven't seen anything except "I don't know why should I
> use it", and that's not a valid reason to me, sorry.

correct. I don't see a good reason to change these defaults and you also
seem to acknowledge the same. To me it's a red flag when somebody
requests a feature without proper justification.
--
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