Re: Broadcom bge and 802.1Q vlan tags

Ruslan Ermilov wrote:
> 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,

I've read what you've written but you also haven't explained why you 
can't signal the presence of these other entities in some way.  The 
current mechanism to signal the presence of "interested parties" for 
vlan-tagged frames is ifp->if_nvlans. You are saying you have new 
(proprietary) code that is interested in vlans but will not use the 
existing mechanism. My reaction is fix your code, don't pessimize the 
code everyone else uses without netgraph.

	Sam