Subject: Re: 802.1Q & ETHER_MAX_LEN
To: None <firstname.lastname@example.org>
From: Manuel Bouyer <email@example.com>
Date: 10/03/2000 15:12:10
On Mon, Oct 02, 2000 at 06:18:10PM +0900, firstname.lastname@example.org wrote:
> >I don't understant this. All interface have an MTU, rigth ?
> >I can't see what a IFF_ flag would give us. To enable/disable the "long frame"
> >feature ?
> >Anyway we have 2 things: the MTU we want to advertize to protocol layers,
> >and the MTU the interface can really do. We need a way to advertize both and
> >this, independantly from a IFF_ flag.
> ifp->if_mtu: MTU for L3 protocols
> ifp->if_hdrlen: header size for L2
> ifp->if_mtu + ifp->if_hdrlen: L2 frame size
> if we have single layer, it would be like this:
> mtu hdrlen total
> --- --- ---
> 1500 14 1514 normal ethernet frame
> 1496 18 1514 VLAN with normal ethernet frame
> 1500 18 1518 VLAN with larger frame
This can be seen in another way: 802.1Q is an encapusulation; the fisrt 14
bytes looks like a normal ethernet frame with a special ether_type.
802.1Q add a second header before the layer 3 frame (BTW, shouldn't
the bpfattach() call in if_vlan.c use sizeof(struct ether_vlan_header)
rather than sizeof(ether_header) ? ). So I don't think we should change
the hdrlen at the ethernet level; this is still an ethernet frame.
In fact, it's the MTU that changes, depending on the ether frame type.
However, switching to a variable MTU based on frame type has a lot of
consequences, maybe much more than we want.
Is there other case where we need something like this (different MTU at
the hardware level depending on the frame type) ? If not maybe we could just
hack something simpler: change ifnet (or maybe, really if_data) to include
the max frame length the HW can do; which may be bigger than
if_mtu + if_hdrlen. Then extra encap layers such as 802.1Q can use it to
recompute a MTU. Anyway we won't be able to have a completely clean separation
between 802.1Q and ethernet.
Manuel Bouyer, LIP6, Universite Paris VI. Manuel.Bouyer@lip6.fr