Date:	Mon, 5 Oct 2015 18:30:12 +0200
From:	Jiri Pirko <jiri@...nulli.us>
To:	John Fastabend <john.fastabend@...il.com>
Cc:	netdev@...r.kernel.org, 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

Mon, Oct 05, 2015 at 05:41:38PM CEST, john.fastabend@...il.com wrote:
>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.

This is just for rocker purposes. I do not want to do something similar
for real devices. It does not make sense as real hw always have some
hard-wired topology. Rocker HW does not. I think that this is the main
part that may cause some misunderstandings.

Rocker has a notion of "worlds". When a port is set to be in a certain
world, it behaves in completely different way. Now we have just OF-DPA
world. I will be adding BPF world shortly.

This has nothing to do with profiles as you describe it, this is
something completely different!


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

I want user to be able to set the world/mode of the port on fly. No need to
re-set the hardware if possible to do it from driver.


>for convenience and only meant for the emulated device we should be
>clear in the documentation and patch set.

This is rocker-only patchset, where do you want to clear it?


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

I think you are missing something, or I am. How do you map BPF world
pipeline into tables? The idea of the worlds is to do *completely*
different HW implementation, not just rewire some pre-defined tables.
For BPF world, there will be just BPF interpreter sitting inside HW
and running arbitrary code, no tables.


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

Your patchset sounds totally unrelated to this one. Let's make that clear.

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