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]

Message-ID: <20140826205419.GH15316@casper.infradead.org>
Date:	Tue, 26 Aug 2014 21:54:19 +0100
From:	Thomas Graf <tgraf@...g.ch>
To:	Alexei Starovoitov <alexei.starovoitov@...il.com>
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 08/26/14 at 01:13pm, Alexei Starovoitov wrote:
> 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 ?

That really depends on your definition of application. A pure
switch application will obviously benefit. The host case is more
complicated, offloading packet switching doesn't buy you anything
obviously but it does allow to use SR-IOV in a broader context. If
I have to chose between a DPDK host stack bypass and a well
abstracted and flexible SR-IOV bypass I would favour the VF approach.
Especially once things like P4 make its way into hardware and
the flexibility of hardware becomes less of an issue. My interest
is mainly driven from this perspective.

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

I agree that it shouldn't be the golden model. Is that even
happening? Given the earlier discussions, the only reason rocker
seems to exist is because of lack of public hardware specs. I doubt
that Jiri and Scott are doing this excercise if they wouldn't have
to.
 
> "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.

Agreed but I don't think we should restrict this to L2. As you say,
that problem is solved and we have fdb_add() to take care of the
offload.

What we're facing as minimal requirements are L2-L3 forwarding needs
combined with encap and encryption. Does it have to be implemented
with OF1.x flows? No. In fact I would love to use eBPF in the
software path and will support you all the way ;-) P4 hardware will
make that even sweeter. But using a flow model does seem kind of
straight forward to allow for offload with today's available HW n-tuple
filters.
--
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