Re: Broadcom bge and 802.1Q vlan tags

From: Ruslan Ermilov <ru_at_freebsd.org>
Date: Wed, 13 Oct 2004 09:42:27 +0300
Hi Sam,

On Tue, Oct 12, 2004 at 01:20:07PM -0700, Sam Leffler wrote:
> >>This pessimizes normal traffic.
> >
> >m_tag_locate() doesn't look like a very expensive function.  And
> >with the "normal traffic", I don't expect to be more than one tag,
> >no?  Also, if if_nvlans > 0, this is already "pessimized".
> >
> >
> >>We should look for a solution in the 
> >>driver(s) to avoid sending packets up with tags when no vlans are 
> >>configured.
> >>
> >
> >I'd be opposed to such a change in behavior.  The VLAN consumer can
> >be not only vlan(4), it can equally be the ng_vlan(4) node, etc.
> 
> I'm not sure what you are opposed to or why.  The issue I have is that 
> m_tag_locate can be expensive if many packets have tags.  The check for 
> the existence of vlans configured on the interface short-circuits this 
> work.  That vlan-tagged packets may be generated when no vlans are 
> configured seems wrong to me and breaks the assumption used to write the 
> code.  Changing the driver to drop the frame if ifp->if_nvlans is zero 
> seems straightforward and could probably be hidden in the existing macro.
> 
Please take a moment and re-read what I've already said: vlan(4) is not
the only consumer of VLAN frames: ng_vlan(4) is another such one, and I
have a proprietary Netgraph node here that demultiplexes VLANs.  If you
start dropping VLAN frames in drivers when if_nvlans == 0, this will be
a problem for me.  Is that clear now?


Cheers,
-- 
Ruslan Ermilov
ru_at_FreeBSD.org
FreeBSD committer

Received on Wed Oct 13 2004 - 04:42:46 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:17 UTC