Re: [EXPERIMENTAL PATCH] 2.4 tulip jumbo frames

["Rask Ingemann Lambertsen" <rask@sygehus.dk>]

On Tue, 09 Dec 2003 14:38:01 -0800, Ben Greear wrote
> Rask Ingemann Lambertsen wrote:
> 
> > What do you propose? Do we need something like
> > 
> > int vlan_adjust_mtu (int mtu)
> > {
> > #ifdef CONFIG_VLANN_8021Q
> > 	return (mtu - VLAN_HLEN);
> > #else
> > 	return (mtu);
> > #endif
> > }
> I was thinking the check could be made run-time, but in reality, 
> this is a very minor detail.

You could use something like

        if (dev->priv_flags & IFF_802_1Q_VLAN)
                return (mtu - VLAN_HLEN);
        else
                return (mtu);

but then you have a problem if the MTU is set to the maximum with VLAN 
disabled and someone decides to enable VLAN on the device afterwards. A 
possible solution would be to set NETIF_F_VLAN_CHALLENGED when VLAN_HLEN
extra bytes are not available.

That said, even checking CONFIG_VLAN_8021Q is probably flawed too, because 
ideally, even when building a kernel without VLAN support, you should be able 
to use the bridging support in a VLAN environment. IMHO. I mean, if this is 
not the case, please remind me why we need VLAN patches in the first place 
since setting an MTU of 1496 bytes works with every Ethernet board and driver.

> I don't like the patch above, I'd rather see the
> #ifdef when checking for the maximum hardware limit, if anywhere.

I was thinking that there could be other reasons than VLAN for reducing the 
MTU and that vlan_adjust_mtu() could take these into account as well. PPPoE 
comes to my mind, but I have no clue how that is implemented in Linux (or any 
other system).

-- 
Regards,
Rask Ingemann Lambertsen