netdev - RE: [RFC PATCH 1/4] net: Add support to netdev ops for changing hardware queue MAC and VLAN filters

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <EA929A9653AAE14F841771FB1DE5A1365FA6A1FF82@rrsmsx501.amr.corp.intel.com>
Date:	Thu, 19 Nov 2009 11:43:54 -0700
From:	"Williams, Mitch A" <mitch.a.williams@...el.com>
To:	Ben Hutchings <bhutchings@...arflare.com>
CC:	"Kirsher, Jeffrey T" <jeffrey.t.kirsher@...el.com>,
	"davem@...emloft.net" <davem@...emloft.net>,
	"shemminger@...tta.com" <shemminger@...tta.com>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"gospo@...hat.com" <gospo@...hat.com>
Subject: RE: [RFC PATCH 1/4] net: Add support to netdev ops for changing
	hardware queue MAC and VLAN filters

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


>[...]
>> 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

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html