Subject: Re: HW-assisted VLAN handling
To: Jaromir Dolecek <jdolecek@NetBSD.org>
From: Jason Thorpe <email@example.com>
Date: 01/30/2005 13:07:38
On Jan 30, 2005, at 12:01 PM, Jaromir Dolecek wrote:
> If it is able to do this in HW, the driver can program the chip
> to drop the packets. Otherwise do what's doing now, i.e. pass
> VLAN-tagged messages down if_input(), which would take care to sort
> it out. I.e. it'd be totally optional and up to the driver if it
> uses the information.
So, the semantics should be:
If VLAN filtering is set on an interface, it accepts only those VLANs
(plus untagged frames) unless IFF_PROMISC is set, in which case it
receives all of them. Such frames should have the VLAN encapsulation
stripped, and the packet tagged appropriately.
This would make for roughly the same semantics as interfaces that do
not have hw VLAN filtering capability.
I would also suggest that you eliminate the whole "nvlans" thing, and
simply always add/remove the filtering list, and always thwack the
interface when a VLAN is added/removed. I.e. handle it exactly the
same way that multicast addresses are handled. For interfaces that
support HWTAGGING but not HWFILTERING, then the fact that the list is
not empty is the same as checking nvlans != 0.