Re: PATCH: VLAN support for 3c59x/3c90x

From: Ben Greear
Date: Sat Jul 31 2004 - 12:08:01 EST


Matti Aarnio wrote:

Also the Linux kernel isn't very well happy with multi-path stacking
of layer-2 driver modules. A side-effect from all of these things might
be, that setting up some dozen VLANs to an ethernet with result in
two, or in worst case, a dozen+1 setup runs. And if last VLAN setup
is (for any reason) smaller MTU value than 1500, it might even result
in entire driver to be configured for e.g. 1280+4 byte MTU..

If the VLAN code shrinks the MTU on the underlying device, I'd
consider that a bug.


For this IFCONFIG MTU issue, I would rather have the VLAN code to ask
the underlaying driver of what MTU can be supported, than just blindly
presume that 1500 will be functional for e.g. eth0.2 (like it does now)

Things would just magically work, if the uping of eth0.2 would setup
itself to MTU 1496, unless the underlaying eth0 can handle real 1504 byte
802.1q frames.

Things would not magically work. Sending larger frames almost always
works, it is receiving the larger frames that fails. So you really
need to change the MTU of the peer device instead (and everything else
on the local VLAN).

For VLAN support you definitely want to let the user increase the size above 1500, and for that you need ->change_mtu

I agree, but my point was that adding MODULE_PARM was only a one liner and
would have done the job too. But since everyone prefers a change_mtu(), I'll
do it.

VLAN allows you to continue using the ethX interface as a regular
ethernet interface, so you do not generally want it's MTU to be set
to 1504 because then the other peer ethernet interfaces would also
have to be set to 1504. I believe it is much better to silently let
the extra 4 bytes pass but NOT advertise this extra 4 bytes to
anything that actually cares about MTU.


--
Ben Greear <greearb@xxxxxxxxxxxxxxx>
Candela Technologies Inc http://www.candelatech.com

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/