netdev - Re: [patch net-next 00/14] rocker: add support for multiple worlds

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: <56129A32.1010201@gmail.com>
Date:	Mon, 05 Oct 2015 08:41:38 -0700
From:	John Fastabend <john.fastabend@...il.com>
To:	Jiri Pirko <jiri@...nulli.us>, netdev@...r.kernel.org
CC:	davem@...emloft.net, sfeldma@...il.com, idosch@...lanox.com,
	eladr@...lanox.com, tgraf@...g.ch, ast@...mgrid.com
Subject: Re: [patch net-next 00/14] rocker: add support for multiple worlds

On 15-10-04 02:25 PM, Jiri Pirko wrote:
> From: Jiri Pirko <jiri@...lanox.com>
> 
> This patchset allows new rocker worlds to be easily added in future (like eBPF
> based one I have been working on). The main part of the patchset is the OF-DPA
> carve-out. It resuts in OF-DPA specific file. Clean cut.
> The user is able to change rocker port world/mode using rtnl.
> 

Hi Jiri,

I'm not sure I understand the motivation here. Are you thinking the
"real" drivers will start to load worlds or what I've been calling
profiles on the devices I have here. If this is the case using
opaque strings without any other infrastructure around it to expose
what the profile is doing is not sufficient in my opinion. What I
would rather have is for drivers to expose the actual configuration
parameters they are using, preferable these would be both readable
and writable so we don't end up with what the firmware/device driver
writers think is best. I think we can get there by exposing a model
of the device and configuring "tables". I'll post my latest patch
set today to give you a better idea what I'm thinking here. Without
this I guess you will end up with drivers creating many profiles and
in no consistent way so you end up with here is my "vxlan" profile,
here is my "geneve" profile, here is my "magic-foo" profile, etc. I
wanted to avoid this.

But if this is only meant to be a rocker thing then why expose it on
the driver side vs just compiling it on the qemu side? If its just
for convenience and only meant for the emulated device we should be
clear in the documentation and patch set.

Final, comment can we abstract the interfaces better? An L2 and L3
table could be mapped generically onto a table pipeline model if the
driver gave some small hints like this is my l2 table and this is my l3
table. Then you don't need all the world specific callbacks and the
OF-DPA model just looks like an instance of a pipeline with some
specific hints where to put l2/l3 rules.

Like I said I'll send some patches, they will be a bit rough and
against fm10k driver. I'll just send out what I have end of day here.

.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