netdev - Re: [patch net-next RFC 10/12] openvswitch: add support for datapath hardware offload

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]

Date:	Tue, 26 Aug 2014 13:13:30 -0700
From:	Alexei Starovoitov <alexei.starovoitov@...il.com>
To:	Thomas Graf <tgraf@...g.ch>
Cc:	Andy Gospodarek <gospo@...ulusnetworks.com>,
	Jiri Pirko <jiri@...nulli.us>,
	Jamal Hadi Salim <jhs@...atatu.com>,
	Roopa Prabhu <roopa@...ulusnetworks.com>,
	John Fastabend <john.fastabend@...il.com>,
	Scott Feldman <sfeldma@...ulusnetworks.com>,
	netdev <netdev@...r.kernel.org>,
	David Miller <davem@...emloft.net>,
	Neil Horman <nhorman@...driver.com>,
	Andy Gospodarek <andy@...yhouse.net>,
	dborkman <dborkman@...hat.com>, ogerlitz <ogerlitz@...lanox.com>,
	Jesse Gross <jesse@...ira.com>,
	Pravin Shelar <pshelar@...ira.com>,
	Andy Zhou <azhou@...ira.com>, ben@...adent.org.uk,
	Stephen Hemminger <stephen@...workplumber.org>,
	jeffrey.t.kirsher@...el.com, vyasevic@...hat.com,
	Cong Wang <xiyou.wangcong@...il.com>,
	john.r.fastabend@...el.com, Eric Dumazet <edumazet@...gle.com>,
	Florian Fainelli <f.fainelli@...il.com>,
	John Linville <linville@...driver.com>,
	"dev@...nvswitch.org" <dev@...nvswitch.org>, jasowang@...hat.com,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	Nicolas Dichtel <nicolas.dichtel@...nd.com>,
	ryazanov.s.a@...il.com, buytenh@...tstofly.org,
	aviadr@...lanox.com, nbd@...nwrt.org, Neil.Jerram@...aswitch.com,
	ronye@...lanox.com, Shrijeet Mukherjee <shm@...ulusnetworks.com>
Subject: Re: [patch net-next RFC 10/12] openvswitch: add support for datapath
 hardware offload

On Tue, Aug 26, 2014 at 9:19 AM, Thomas Graf <tgraf@...g.ch> wrote:
>
> Wait... I don't want to use OpenFlow to configure my laptop ;-)

+1

> We should leave the controller out of this discussion though. A
> controller is not required to run OVS at all. OpenStack Neutron
> is a very good example for that. There are even applications which
> use the OVS kernel datapath but not the OVS user space portion.
> We have a wide set of APIs serving different purposes and need to
> account for all of them. I'm as much interested in an offloaded
> nftables and tc command as you.

I think it's important distinction. In-kernel OVS is not OF.
It's a networking function that has hard-coded packet parser,
N-tuple match and programmable actions.
There were times when HW vendors were using OF check-box
to sell more chips, but at the end there is not a single HW
that is fully OF compliant. OF brand is still around, but
OF 2.0 is not tcam+action anymore.
Imo trying to standardize HW offload interface based on OF 1.x
principles is strange. Does anyone has performance data
that shows that hard-parser+N-tuple-match offload actually speeds
up real life applications ?
Why are we designing kernel offload based on 'rocker' emulator?
Enterprise silicon I've seen doesn't look like it...
I'm not saying that kernel should not have a driver for rocker.
It should, but it shouldn't be a golden model for HW offload.

"straw-man proposal for OF 2.0" paper have very
interesting ideas:
http://arxiv.org/pdf/1312.1719.pdf
sooner or later off the shelf NICs will have similar functionality.

In Linux we already have bridge that is perfect abstraction of
L2 network functions. OF 1.x has to use 'tcam' to do bridge and
in-kernel OVS has to fall back to 'mega-flows', but HW has proper
exact match tables and HW mac learning,
so OF 1.x principles just don't fit to L2 offloading.
--
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