From: Ben Hutchings [mailto:bhutchings@solarflare.com]
Sent: Thursday, November 19, 2009 6:55 AM

[...]

quoted

In the case of SR-IOV on our hardware, these filters are perfect - no
hash tables are required. (We do use hash tables when we have a bunch
of multicast addresses, but that's not what this is about.)

MAC filters deny packets by default, so you won't get anything without
a valid MAC filter on the queue.

A queue with no VLAN filters will receive packets from all VLANs,
albeit with the tags passed up intact.  So in that sense, the VLAN
filters are default-allow.

However, once you enable any VLAN filter, the hardware starts
stripping tags and begins to deny packets by default.

Based on these semantics, the filtering operation that I've described
above makes perfect sense.

[...]

But they are not the semantics we would want in supposedly generic
netdev operations.

OK, point taken.  Specific hardware features/limitations shouldn't affect kernel policy.

However, I'm still back to code complexity, and general usage models.

Please explain specifically what you perceive to be the difference between:

$ ip link set eth1 queue 1 mac <blah>
$ ip link set eth1 queue 1 vlan <foo>

and

$ ip link set eth1 queue 1 mac <blah> vlan <foo>

The two filter types are, in my mind, completely orthogonal.  You can have one, or the other, or both, or neither. What do we gain by glomming both options on one command line?  And is this worth the tradeoff of more complex code?

-Mitch