[...] >> I think your underestimating the flexibility of hardware. And >> completely missing the hardware that is based on FPGAs and/or cell >> architectures. This hardware is available today and could support >> topology changes like this. But even less exotic hardware can/will >> support parser updates which makes the device behave differently. > > Sure, I'm just trying to explain that woulds and your "profiles" are > something completely different. I feel like we are running in circles. >
Must be going in circles because I don't see the difference. > >> >> Other hardware can reconfigure the topology within some constraints, >> the fm10k device supports this model. An extreme example would put >> an ebpf interpreter in a fpga on the nic and expose it via a driver. >> >> If its just for rocker purposes I'm not really excited about adding >> it to the kernel to support a qemu device. If we allow it for one > > What exactly are you against? Multi-world support as it is of the > userspace iface to change worlds? If the second, I understand, kind of. > Just the userspace interface. I have hardware that can support multiple worlds (although I'm fuzzy what you mean by worlds) today and want to expose that as well. I guess my main objection is I wanted to get away from out of band firmware/microcode updates and this doesn't really look much better to me as I currently understand it. I'll have a bank of microcode images and depending on the string load one of them. I agree we need some way to support configurable hardware. > >> driver I don't see how/why we should block it for "real" devices. >>From the kernels point of view these are all real drivers. I could >> build a qemu model that maps 1:1 with real hardware and do a drop >> in replacement. >> >>> >>> 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! >>> >>> >> >> I'm missing why its different. >> >> Would you object to me adding multiple worlds to fm10k >> using opaque strings? I'll create a world with a topology that maps >> well to ipv4 networks, a world for ipv6 networks, a world for l2 flat >> networks, etc. Each world in this example will have a specific table > > Not worlds in rocker terminology. This is what you call profiles. > > >> topology and parser to support it. In this sense the ports will behave >> in completely different ways i.e. packets will be processed by >> different pipelines. Are you suggesting we do this? > > No, I definitelly do not suggest this. Again, this is what you call "profile". > I don't care about those, not in the scope of this patchset. > hmm maybe you can explain to me what makes a change large enough to be called a "world" and where it is a "profile"? [...] skipped a few comments because I think they were interesting but not the point I was trying to ask. >> 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. > > No, this is not about building. This is about choosing from fixed-sized > pre-defined list of choices. Again, no "profiles". > But I can just expose a list of pre-defined choices that map to what I call "profiles". Must be missing the point help me understand what a world is vs profile? Maybe our goals are not actually conflicting. Do you have any objection to pushing configuration code to create tables, insert a new parser, and change the table topology, and then bind the tables to software subsystems like fdb, l3, tc, nft, bpf, etc. .John -- 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
