Mon, Oct 05, 2015 at 05:41:38PM CEST, john.fastab...@gmail.com wrote: >On 15-10-04 02:25 PM, Jiri Pirko wrote: >> From: Jiri Pirko <j...@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.
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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
