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?
> 
> i'm not suggesting to change vlan-aware drivers.
> i'm suggesting to change the vlan(4) driver.
> how to offload vlan tagging is not relevant at all, afaik.

for the case if it's still unclear to you...

if_output of vlan(4) is ether_output.  it does never prepend vlan tag,
regardless of hardware capabilities.
if_start of it does, in the case of "dumb".

agr(4) needs to transmit pre-built frames and it currently assumes if_output
prepends if_hdrlen length header.  see agr_xmit_frame().

YAMAMOTO Takashi