[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1258657155.2837.10.camel@achroite.uk.solarflarecom.com>
Date: Thu, 19 Nov 2009 18:59:15 +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 Thu, 2009-11-19 at 11:43 -0700, Williams, Mitch A wrote:
[...]
> 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?
I think you need to state clearly what semantics you are now proposing
before I can make any judgement on them.
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