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

[Veaceslav Falico <vfalico@gmail.com>]

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