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?