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
| ||
|
Date: Thu, 27 Nov 2014 12:13:18 +0900 From: Simon Horman <simon.horman@...ronome.com> To: Jamal Hadi Salim <jhs@...atatu.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 Tue, Nov 25, 2014 at 10:33:36PM -0500, Jamal Hadi Salim wrote: > On 11/25/14 16:54, Thomas Graf wrote: > >On 11/25/14 at 12:08pm, Jamal Hadi Salim wrote: > > >It would definitely help if you could expose some more details on the > >"some network processor" you have. We're all very eager ;-) > > > > Well, this thing doesnt run ovs ;-> (/me runs). If you come > to netdev i may let you play with it ;-> Its a humongous device > (think multi 100G ports). > > On a serious note: Even if you took what Simon/Netronome has > (yes, I know they use ovs;->) FWIW, we are also interested in non-OVS use cases. > - there is really no need for a switch > abstraction *at all* if all you want to is hang a packet > processing graph that ingresses at a port and egress at another port. > As you know, Linux supports it just fine with tc. 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. > >I'm with Jiri but I agree it's not a perfect fit. I doubt there is but > >if you can come up with something that fits better I'm open to it. > > > >I considered "dataplane" or "dp" for a bit but it's quite generic as > >well. > > > > The purpose is to offload. I think any name would be better than > mapping it to a specific abstraction called "switch". Especially > if it is hanging off a port and there is no switch in the pipeline. > > 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
Powered by blists - more mailing lists