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] [day] [month] [year] [list]
Date:	Tue, 06 Oct 2015 00:34:52 -0700
From:	John Fastabend <john.fastabend@...il.com>
To:	Scott Feldman <sfeldma@...il.com>
CC:	Jiri Pirko <jiri@...nulli.us>, Netdev <netdev@...r.kernel.org>,
	"David S. Miller" <davem@...emloft.net>,
	Ido Schimmel <idosch@...lanox.com>, eladr@...lanox.com,
	Thomas Graf <tgraf@...g.ch>,
	Alexei Starovoitov <ast@...mgrid.com>
Subject: Re: [patch net-next 00/14] rocker: add support for multiple worlds

[...]

>>
>> Its related in that if you expose your device model you do not need
>> opaque strings to do wholesale reconfiguration of the device. Instead
>> if the parts of the device that are configurable are exposed to the
>> user they can build the "world" they want.
> 
> The disconnect here, I believe, is offloading to hw the Linux
> forwarding plane vs. offloading an arbitrary application's forwarding
> plane.  Switchdev (and rocker) are about offloading the Linux
> dataplane.  That means Linux _is_ the application (the NOS); hw
> offloads what it can from the kernel to accelerate pkt forwarding.
> But the user's experience is standard Linux tools (iproute2, netlink)
> and building blocks (bridge, bond, etc) are used to construct a switch
> (or router), and the fact that the data path is offloaded to hw is
> transparent to the user.  We could define APIs for arbitrary
> applications to program hardware, like John is suggesting. by giving
> up raw access to hw resources, like tables, etc.  This approach moves
> the "driver" to the application, and by-passes the Linux tools and
> building blocks.  We're still TBD on these APIs, probably because of
> the "by-pass" part.

Thanks Scott I think this helps some.

I don't view my approach as a by-pass though or even letting arbitrary
applications have access to the hardware. Today I load arbitrary
filters and bpf programs into the kernel to create a pipeline. Now I
want to string a couple other tables in front of my pipeline to do
some of the heavy lifting. Maybe the real difference is my _datapath_
is not offloaded (by-passing?) the kernel. Most (all?) of my packets
are meant for the host and I want to do partial offloading where some
of the initial processing is done in the hardware and the rest is
handled by software. The "driver" is not in the application it is
still in the kernel.

I almost have something ready to kick out I meant to do this today
might be another day or two though.

> 
> Jiri's patchset here is about moving things around so he can define
> another hw mode in rocker.   The upper edge for rocker driver is still
> switchdev, but with the new eBPF hw mode he's working on, he'll be
> able to push down a dynamic pipeline rather than being stuck with the
> OF-DPA pipeline we have today (in rocker).  I presume once he has this
> new eBPF support, he'll program in a "Linux kernel" pipeline, and fill
> out the corresponding swtichdev ops.  I imagine a P4 -> ePBF compiler,
> and we take a linux.p4 and program hw.  Linux.p4 should be
> generic...consumable by any hardware...it is a representation of the
> Linux pipeline.  (Similar to P4's switch.p4).
> 
> But now, with eBPF mode in hw, an arbitrary.p4 could be written for
> that arbitrary application and pushed down.  We still need APIs for
> that application.
> 

My gripe here was flipping the hardware between modes with a string
value. It seems it has been dropped from the latest version though so
I have no problem with the patches.

.John

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

Powered by Openwall GNU/*/Linux Powered by OpenVZ