From: John Fastabend <john.fastabend@gmail.com>
To: Jiri Pirko <jiri@resnulli.us>, netdev@vger.kernel.org
Cc: davem@davemloft.net, sfeldma@gmail.com, idosch@mellanox.com,
eladr@mellanox.com, tgraf@suug.ch, ast@plumgrid.com
Subject: Re: [patch net-next 00/14] rocker: add support for multiple worlds
Date: Mon, 05 Oct 2015 08:41:38 -0700 [thread overview]
Message-ID: <56129A32.1010201@gmail.com> (raw)
In-Reply-To: <1443993949-3915-1-git-send-email-jiri@resnulli.us>
On 15-10-04 02:25 PM, Jiri Pirko wrote:
> From: Jiri Pirko <jiri@mellanox.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
next prev parent reply other threads:[~2015-10-05 15:41 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-04 21:25 [patch net-next 00/14] rocker: add support for multiple worlds Jiri Pirko
2015-10-04 21:25 ` [patch net-next 01/14] rocker: remove unused rocker_port param from alloc funcs and shorten their names Jiri Pirko
2015-10-04 21:25 ` [patch net-next 02/14] rocker: rename rocker.h to rocker_hw.h Jiri Pirko
2015-10-04 21:25 ` [patch net-next 03/14] rocker: rename rocker.c to rocker_main.c Jiri Pirko
2015-10-04 21:25 ` [patch net-next 04/14] rocker: push tlv processing into separate files Jiri Pirko
2015-10-04 21:25 ` [patch net-next 05/14] rocker: implement set settings mode command Jiri Pirko
2015-10-06 4:51 ` Scott Feldman
2015-10-04 21:25 ` [patch net-next 06/14] rocker: introduce worlds infrastructure Jiri Pirko
2015-10-04 21:25 ` [patch net-next 07/14] rocker: introduce OF-DPA world skeleton Jiri Pirko
2015-10-04 21:25 ` [patch net-next 08/14] rocker: set default world on port probe and clean world on remove Jiri Pirko
2015-10-04 21:25 ` [patch net-next 09/14] rocker: add rtnl ops for port mode [gs]etting Jiri Pirko
2015-10-05 15:41 ` Scott Feldman
2015-10-05 15:52 ` John Fastabend
2015-10-05 16:37 ` Jiri Pirko
2015-10-05 17:07 ` John Fastabend
2015-10-05 17:24 ` Jiri Pirko
2015-10-05 17:43 ` John Fastabend
2015-10-05 17:50 ` Jiri Pirko
2015-10-05 15:53 ` Jiri Pirko
2015-10-05 16:37 ` Scott Feldman
2015-10-05 16:50 ` Jiri Pirko
2015-10-05 17:00 ` Scott Feldman
2015-10-05 17:12 ` Jiri Pirko
2015-10-04 21:25 ` [patch net-next 10/14] rocker: pass "learning" value as a parameter to rocker_port_set_learning Jiri Pirko
2015-10-05 15:16 ` David Laight
2015-10-05 15:24 ` Jiri Pirko
2015-10-04 21:25 ` [patch net-next 11/14] rocker: pre-allocate wait structures during cmd ring init Jiri Pirko
2015-10-04 21:25 ` [patch net-next 12/14] rocker: remove trans parameter to rocker_cmd_exec function Jiri Pirko
2015-10-04 21:25 ` [patch net-next 13/14] rocker: call rocker_cmd_exec function with "nowait" boolean instead of flags Jiri Pirko
2015-10-04 21:25 ` [patch net-next 14/14] rocker: move OF-DPA stuff into separate file Jiri Pirko
2015-10-05 15:41 ` John Fastabend [this message]
2015-10-05 16:30 ` [patch net-next 00/14] rocker: add support for multiple worlds Jiri Pirko
2015-10-05 16:58 ` John Fastabend
2015-10-05 17:39 ` Jiri Pirko
2015-10-05 17:56 ` John Fastabend
2015-10-05 17:49 ` Scott Feldman
2015-10-06 7:34 ` John Fastabend
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=56129A32.1010201@gmail.com \
--to=john.fastabend@gmail.com \
--cc=ast@plumgrid.com \
--cc=davem@davemloft.net \
--cc=eladr@mellanox.com \
--cc=idosch@mellanox.com \
--cc=jiri@resnulli.us \
--cc=netdev@vger.kernel.org \
--cc=sfeldma@gmail.com \
--cc=tgraf@suug.ch \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).