netdev - Re: [patch net-next RFC 0/4] introduce infrastructure for support of switch chip datapath

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: <20140327134307.GB31168@tuxdriver.com>
Date:	Thu, 27 Mar 2014 09:43:07 -0400
From:	"John W. Linville" <linville@...driver.com>
To:	Neil Horman <nhorman@...driver.com>
Cc:	Thomas Graf <tgraf@...g.ch>, Jamal Hadi Salim <jhs@...atatu.com>,
	Jiri Pirko <jiri@...nulli.us>,
	Florian Fainelli <f.fainelli@...il.com>,
	netdev <netdev@...r.kernel.org>,
	David Miller <davem@...emloft.net>, andy@...yhouse.net,
	dborkman@...hat.com, ogerlitz@...lanox.com, jesse@...ira.com,
	pshelar@...ira.com, azhou@...ira.com,
	Ben Hutchings <ben@...adent.org.uk>,
	Stephen Hemminger <stephen@...workplumber.org>,
	jeffrey.t.kirsher@...el.com, vyasevic <vyasevic@...hat.com>,
	Cong Wang <xiyou.wangcong@...il.com>,
	John Fastabend <john.r.fastabend@...el.com>,
	Eric Dumazet <edumazet@...gle.com>,
	Scott Feldman <sfeldma@...ulusnetworks.com>,
	Lennert Buytenhek <buytenh@...tstofly.org>
Subject: Re: [patch net-next RFC 0/4] introduce infrastructure for support of
 switch chip datapath

On Wed, Mar 26, 2014 at 02:21:22PM -0400, Neil Horman wrote:
> On Wed, Mar 26, 2014 at 11:29:03AM +0000, Thomas Graf wrote:

> > What I don't understand at this point is how hiding the ports behind
> > a master device would buy us anything. We would still need to abstract
> > the filtering capabilities of the ports at some level and hiding that
> > behind existing tools seems to most convenient way.
> > 
> 
> If we agree that inconsistent frame reception / stack bypass is acceptable, then
> hiding the ports buys us nothing.  My only goal with that suggestion was to
> differentiate ports on a switch device so that the ports were differentiated in
> such a way as to make it clear that they didn't behave like typical NIC ports
> that were meant to receive host terminated traffic only.  If the consensus is
> to allows sparse reception of forwarded traffic at the cpu, then no, its not
> worthwhile and can be ignored.

I don't like the master device idea.  It just seems likely to cause
confusion.  But, we may want something to expose some topology
information to the user.  There could be situations where it is
releavant to know that two netdevs are part of the same hardware
device.

In the past I've also seen boxes with multiple switch chips tied
together either through dedicated "stacking" ports or even just with
ethernet ports directly wired together inside the box.  A variety
of combinations are possible, each with performance considerations
that might be relevant to an admin.  It would be good if we could
help them map-out such relationships.

Maybe the existing bus infrastructure (or something like it) could
be leveraged?

John
-- 
John W. Linville		Someday the world will need a hero, and you
linville@...driver.com			might be all we have.  Be ready.
--
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