Subject: Re: if_hdrlen
To: YAMAMOTO Takashi <yamt@mwd.biglobe.ne.jp>
From: Jonathan Stone <jonathan@dsg.stanford.edu>
List: tech-net
Date: 03/21/2005 12:34:52
In message <1111400063.424391.23578.nullmailer@yamt.dyndns.org>,
YAMAMOTO Takashi writes:
>hi,
>
>can anyone explain how if_hdrlen is supposed to be?
>
> 1. on-wire header length
> 2. in-core header length (ie. what if_output prepends)
> 3. something else
>
>IMO, 2. is reasonable. (and it's what agr(4) assumes.)
>does anyone object if i change vlan(4) to use ETHER_HDR_LEN as if_hdrlen
>instead of ETHER_HDR_LEN + sizeof(tag)?
I vaguely recall seeing two broad kinds of hardware that supports VLANs:
1. hardware which handles VLAN-tag insertion/deletion and filtering in
hardware, and can auto-insert VLAN tags;
2. hardware that handles "baby-giant" packets, where software
has to handle VLAN tag insertion, removal, filtering of packets with
unwanted tags, etc.
It's not clear to me which "case" you mean by #2 above, or what it'd buy us.
If the change is small, why not send a diff, with changes for a "dumb"
and a "smart" vlan-aware driver, for discussion?
It's hard to give good feedback when you don't explain *why* you want
to make a change. Do you want to make life easier for agr(4)? Or to
make the code more internally consistent? If the latter, maybe
changing agr(4) to follow prior art is a better path?