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]

Date:	Thu, 26 Feb 2015 10:16:26 -0800
From:	Scott Feldman <sfeldma@...il.com>
To:	Tom Herbert <therbert@...gle.com>
Cc:	Jiri Pirko <jiri@...nulli.us>,
	Simon Horman <simon.horman@...ronome.com>,
	Linux Netdev List <netdev@...r.kernel.org>,
	David Miller <davem@...emloft.net>,
	Neil Horman <nhorman@...driver.com>,
	Andy Gospodarek <andy@...yhouse.net>,
	Thomas Graf <tgraf@...g.ch>,
	Daniel Borkmann <dborkman@...hat.com>,
	Or Gerlitz <ogerlitz@...lanox.com>,
	Jesse Gross <jesse@...ira.com>, jpettit@...ira.com,
	Joe Stringer <joestringer@...ira.com>,
	John Fastabend <john.r.fastabend@...el.com>,
	Jamal Hadi Salim <jhs@...atatu.com>,
	Florian Fainelli <f.fainelli@...il.com>,
	Roopa Prabhu <roopa@...ulusnetworks.com>,
	John Linville <linville@...driver.com>,
	Shrijeet Mukherjee <shrijeet@...il.com>,
	Andy Gospodarek <gospo@...ulusnetworks.com>,
	Benjamin LaHaise <bcrl@...ck.org>
Subject: Re: Flows! Offload them.

On Thu, Feb 26, 2015 at 8:04 AM, Tom Herbert <therbert@...gle.com> wrote:

> Sorry if I'm asking dumb questions, but this is about where I usually
> start to get lost in these discussions ;-). Is the aim of switch
> offload to offload OVS or kernel functions of routing, iptables, tc,
> etc.?

Both, which is why it's hard to follow, and there are active efforts
on both fronts.  What has stuck so far with switchdev is offloading
kernel functions, such as L2 bridging to existing switch chips (real
(DSA) or fake (rocker)).  WIP on extended that to L3 and maybe a
subset of nftables.  So far, the kernel is the "application", and
we're offloading (sorry, overloaded term, but I can't think of an
alternative) the kernel fwd data paths to capable hardware.  But there
are "impedance" mismatches between what we can do today in the kernel
and fixed hardware.  On the other front we have offloading OVS, or
more in more general terms, programming the switch from some other
"application", local or remote using the proposed flow api or tc or
some combination.  Maybe these two fronts merge down the road where
the kernel is just another application using the flow api.  Grand
unification theory?

> These are very different I believe. As far as I can tell OVS
> model of "flows" (like Openflow) is currently incompatible with the
> rest of the kernel.
> So if the plan is convert OVS datapath to TC does
> that mean introducing that model into core kernel?
--
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