netdev - Re: Flows! Offload them.

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: <20150226131750.GE1973@nanopsycho.lan>
Date:	Thu, 26 Feb 2015 14:17:50 +0100
From:	Jiri Pirko <jiri@...nulli.us>
To:	Thomas Graf <tgraf@...g.ch>
Cc:	netdev@...r.kernel.org, davem@...emloft.net, nhorman@...driver.com,
	andy@...yhouse.net, dborkman@...hat.com, ogerlitz@...lanox.com,
	jesse@...ira.com, jpettit@...ira.com, joestringer@...ira.com,
	john.r.fastabend@...el.com, jhs@...atatu.com, sfeldma@...il.com,
	f.fainelli@...il.com, roopa@...ulusnetworks.com,
	linville@...driver.com, simon.horman@...ronome.com,
	shrijeet@...il.com, gospo@...ulusnetworks.com, bcrl@...ck.org
Subject: Re: Flows! Offload them.

Thu, Feb 26, 2015 at 01:51:43PM CET, tgraf@...g.ch wrote:
>On 02/26/15 at 08:42am, Jiri Pirko wrote:
>> Hello everyone.
>> 
>> I would like to discuss big next step for switch offloading. Probably
>> the most complicated one we have so far. That is to be able to offload flows.
>> Leaving nftables aside for a moment, I see 2 big usecases:
>> - TC filters and actions offload.
>> - OVS key match and actions offload.
>> 
>> I think it might sense to ignore OVS for now. The reason is ongoing efford
>> to replace OVS kernel datapath with TC subsystem. After that, OVS offload
>> will not longer be needed and we'll get it for free with TC offload
>> implementation. So we can focus on TC now.
>>
>> Here is my list of actions to achieve some results in near future:
>> 1) finish cls_openflow classifier and iproute part of it
>
>I still think that you should consider renaming this or merging
>it with cls_flow. I don't see any relation to OpenFlow in what
>you proposed in the last RFC.

cls_flow does something different. I believe that it is not a good idea
to merge it with cls_openflow.

Relation to OpenFlow is that the cls follows the specification in what
fields of pks should be used for matching.

But I get your point. cls_openflow is the working name. I have no
problem in changing it so something different.


>
>> 2) extend switchdev API for TC cls and acts offloading (using John's flow api?)
>> 3) use rocker to provide offload for cls_openflow and couple of selected actions
>> 4) improve cls_openflow performance (hashtables etc)
>> 5) improve TC subsystem performance in both slow and fast path
>>     -RTNL mutex and qdisc lock removal/reduction, lockless stats update.
>> 6) implement "named sockets" (working name) and implement TC support for that
>>     -ingress qdisc attach, act_mirred target
>> 7) allow tunnels (VXLAN, Geneve, GRE) to be created as named sockets
>> 8) implement TC act_mpls
>> 9) suggest to switch OVS userspace from OVS genl to TC API
>
>I think everybody agrees to unifying code paths and getting rid
>of parallism assuming that it does not introduce a performance
>regression for flow setup rate, throughput, and scale.

Great. I sure plan to focus on performance (on both fast and slow path).

>
>I would also include Linux bridge in this effort as it's also
>based on programmable flows and would thus also benefit from
>the implemented offload functionality.

Well I would leave the bridge alone for now. We are able to offload fdbs
there now easily. But I'm open to the discussion for the future.

Thanks!

Jiri

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