On Mon, Oct 02, 2000 at 06:18:10PM +0900, itojun@iijlab.net 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
--