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: <20140715191810.GA16963@mikrodark.usersys.redhat.com>
Date:	Tue, 15 Jul 2014 21:18:11 +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 11:55:29AM -0700, Alexei Starovoitov wrote:
>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.

No spec, but a reply from a juniper employee, as it states:

http://forums.juniper.net/t5/Ethernet-Switching/Is-it-possible-to-do-QinQinQ/td-p/29409

Also, it's a valid use case, described there.

>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.

You're mentioning it for the 3rd or 4th time already. Can you please
provide a proof? It'd be interesting to read, as I see over the net that
people are managing to do triple vlan tagging on cisco.

Also, could you explain what do you mean by "undefined behaviour"? I can't
really understand what can be undefined in 3 tags.

>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.

That's not the problem with any nested vlan level, but with hw offload. I
guess it's the source/consiquencies thing.

>
>> 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.

You're putting words in my mouth for the second time already. I didn't say
that I don't see a good reason to change the defaults, I've said that I
don't see a good reason to drop this enhancement only because someone
doesn't know what to use it for.

>To me it's a red flag when somebody
>requests a feature without proper justification.

The feature is there already. It's just a configuration to enable this
feature without changing one define.

And, also, the any-level nesting in linux stack *is* already present, and
bonding just tries to stay up-to-date with that.
--
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