netdev - Re: [patch net-next v3 04/17] net: introduce generic switch devices support

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: <54771A8B.2030305@mojatatu.com>
Date:	Thu, 27 Nov 2014 07:35:23 -0500
From:	Jamal Hadi Salim <jhs@...atatu.com>
To:	Simon Horman <simon.horman@...ronome.com>
CC:	Thomas Graf <tgraf@...g.ch>, Jiri Pirko <jiri@...nulli.us>,
	netdev@...r.kernel.org, davem@...emloft.net, nhorman@...driver.com,
	andy@...yhouse.net, dborkman@...hat.com, ogerlitz@...lanox.com,
	jesse@...ira.com, pshelar@...ira.com, azhou@...ira.com,
	ben@...adent.org.uk, stephen@...workplumber.org,
	jeffrey.t.kirsher@...el.com, vyasevic@...hat.com,
	xiyou.wangcong@...il.com, john.r.fastabend@...el.com,
	edumazet@...gle.com, sfeldma@...il.com, f.fainelli@...il.com,
	roopa@...ulusnetworks.com, linville@...driver.com,
	jasowang@...hat.com, ebiederm@...ssion.com,
	nicolas.dichtel@...nd.com, ryazanov.s.a@...il.com,
	buytenh@...tstofly.org, aviadr@...lanox.com, nbd@...nwrt.org,
	alexei.starovoitov@...il.com, Neil.Jerram@...aswitch.com,
	ronye@...lanox.com, alexander.h.duyck@...hat.com,
	john.ronciak@...el.com, mleitner@...hat.com, shrijeet@...il.com,
	gospo@...ulusnetworks.com, bcrl@...ck.org
Subject: Re: [patch net-next v3 04/17] net: introduce generic switch devices
 support

On 11/26/14 22:13, Simon Horman wrote:
> On Tue, Nov 25, 2014 at 10:33:36PM -0500, Jamal Hadi Salim wrote:

[..]
> I may be missing the point but I see two problems that are solved by
> the switch abstraction.
>
> - Cases where no ports are configured.
>
>    Perhaps no such use cases exist for the API in question.
>    But it does seem plausible to me that non-physical ports could
>    be added at run-time and that thus a "switch" could initially
>    exist with no configured port. Something like how bridges
>    initially have no ports (IIRC).
>
> - Discovering the association between ports and "switches".
>
> My recollection from the double round table discussion on the last day of
> the Düsseldorf sessions was that these were reasons that simply accessing
> any port belonging to the "switch" were not entirely satisfactory.
>

So in Du I illustrated in a slide the internals of the Realtek that
Ben had patches on. Ben first exposes the realtek ports and when
you wish you can build a bridge and attach the exposed ports
and then hardware switching functionality is used. What is interesting
about it is infact you didnt need to use the switching on it. You
could attach a filter to any of the exposed ports, then specify an
action to do a redirect to another port for example.
(Scott i know you were not there, but i cant find where those slides
are posted; will send them when i do - or ask Thomas).
This is very easy to map to port/ingress classifier/actions in Linux.
I was hoping i could produce a patch to do this - but waiting on Ben
to complete the reverse engineering.
In any case the realtek is a toy example but there's millions deployed
and producing a patch for tc (if Jiri doesnt beat me to it) is a useful
exercise.
My devices (as would a netronome) would apply the same concept.
Essentially, you take an ingress packet arriving on a port,
you apply a classifier to it, apply actions to i and eventually
ingress it to a port. i.e

Ingress packet-->port->classifier-->...actions..->egress port

I can model the above with tc.

cheers,
jamal

--
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