Thread (15 messages) flat view 15 messages, 4 authors, 2014-07-16

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

From: Alexei Starovoitov <hidden>
Date: 2014-07-15 18:55:31

On Tue, Jul 15, 2014 at 10:53 AM, Veaceslav Falico [off-list ref] wrote:
On Tue, Jul 15, 2014 at 10:33:25AM -0700, Alexei Starovoitov wrote:
..snip...
quoted
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.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help