Re: Broadcast traffic on vlans leaks into the parent interface on NetBSD-5.1

[Dennis Ferguson <dennis.c.ferguson%gmail.com@localhost>]

On 29 Nov, 2012, at 13:52 , Manuel Bouyer <bouyer%antioche.eu.org@localhost> 
wrote:

> On Wed, Nov 28, 2012 at 07:23:13PM -0600, David Young wrote:
>> On Wed, Nov 28, 2012 at 07:27:56PM -0500, Greg Troxel wrote:
>>> 
>>> dhcpd, last I checked, used bpf and not sockets.
>>> 
>>> If dhcpd is bpf, I would suggest reading the bpf_tap calls in the
>>> driver.  It could be that if_wm.c has a spurious on.
>>> 
>>> If it's not, I don't know what's going on.
>> 
>> I'll bet this has something to do with the hardware VLAN tagging.  I
>> don't think BPF groks the VLAN mbuf tags.
>> 
>> FWIW, I think that hardware VLAN tagging is a lot of pain for no gain
>> the way that NetBSD is doing it.
> 
> The last time I looked at this (on wm(4) with not-so-fast CPUs),
> hardware vlan tagging had a small gain. Not much, but still measurable

That might not be the right comparison, though, since I think
it compares having hardware take the tag out of the packet while
leaving the rest of the ethernet header intact, with having software
take the tag out of the packet while leaving the rest of the
ethernet header intact.  Hardware is sure to be better at this.

I think, however, the best case is when the tag is left in the
packet by the hardware and only removed by software when the rest
of the ethernet header is being taken off anyway.  Unless I'm
missing something I don't think there is a reason to want to take
the tag off first and the rest of the L2 header off later when
the ethernet frame arrived from the wire with a tag, if you are
processing the packet at L3, while bridging in the presence of
VLANs would be much happier with a hardware assist to put tags
into the packet on the way in and delete them on the way out,
which is the opposite operation.

Dennis Ferguson