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: <20150227084141.GA17240@casper.infradead.org>
Date:	Fri, 27 Feb 2015 08:41:41 +0000
From:	Thomas Graf <tgraf@...g.ch>
To:	Neil Horman <nhorman@...driver.com>
Cc:	Simon Horman <simon.horman@...ronome.com>,
	John Fastabend <john.r.fastabend@...el.com>,
	Jiri Pirko <jiri@...nulli.us>, netdev@...r.kernel.org,
	davem@...emloft.net, andy@...yhouse.net, dborkman@...hat.com,
	ogerlitz@...lanox.com, jesse@...ira.com, jpettit@...ira.com,
	joestringer@...ira.com, jhs@...atatu.com, sfeldma@...il.com,
	f.fainelli@...il.com, roopa@...ulusnetworks.com,
	linville@...driver.com, shrijeet@...il.com,
	gospo@...ulusnetworks.com, bcrl@...ck.org
Subject: Re: Flows! Offload them.

On 02/26/15 at 08:22pm, Neil Horman wrote:
> Yes, exactly that, for the general traditional networking use case, that is
> exactly what we want, to opportunistically move traffic faster with less load on
> the cpu.  We don't nominally care what traffic is offloaded, as long as the
> hardware does a better job than just software alone.  If we get an occasional
> miss and have to do stuff in software, so be it.

Blind random offload of some packets is better than nothing but knowing
and having control over which packets are offloaded is essential. You
typically don't want to randomly give one flow priority over another ;-)
Some software CPUs might not be able to handle the load. I know what
you mean though and as long as we allow to disable and overwrite this
behaviour we are good.

> So, this is a case in which I think John F.'s low level flow API is more well
> suited.  OVS has implemented a user space dataplane that circumvents alot of the
> kernel mechanisms for traffic forwarding.  For that sort of application, the
> traditional kernel offload "objects" aren't really appropriate.  Instead, OVS
> can use the low level flow API to construct its own custom offload pipeline
> using whatever rules and policies that it wants.

Maybe I'm misunderstanding your statement here but I think it's essential
that the kernel is able to handle whatever we program in hardware even
if the hardware tables look differrent than the software tables, no matter
whether the configuration occurs through OVS or not. A punt to software
should always work even if it does not happen. So while I believe that
OVS needs more control over the hardware than available through the
datapath cache it must program both the hardware and software in parallel
even though the building blocks for doing so might look different.

> Of course, using the low level flow API is incompatible with the in-kernel
> object offload idea that I'm proposing, but I see the two as able to co-exist,
> much like firewalld co-exists with iptables.  You can use both, but you have to
> be aware that using the lower layer interface might break the others higher
> level oeprations.  And if that happens, its on you to manage it.

I think this does not have to be mutually exclusive. An example would
be a well defined egress qdisc which is offloaded into it's own table.
If OVS is aware of the table it can make use of it while configuring
that table through the regular qdisc software API.
--
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