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

[Ben Greear <greearb@candelatech.com>]

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@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com