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.

Make sense?

-- thorpej