[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150226125143.GB23050@casper.infradead.org>
Date: Thu, 26 Feb 2015 12:51:43 +0000
From: Thomas Graf <tgraf@...g.ch>
To: Jiri Pirko <jiri@...nulli.us>
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.
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.
> 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.
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.
--
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