[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1258642493.2837.8.camel@achroite.uk.solarflarecom.com>
Date: Thu, 19 Nov 2009 14:54:53 +0000
From: Ben Hutchings <bhutchings@...arflare.com>
To: "Williams, Mitch A" <mitch.a.williams@...el.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
On Wed, 2009-11-18 at 16:33 -0700, Williams, Mitch A wrote:
[...]
> 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.
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
--
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
Powered by blists - more mailing lists