[...] >> >> 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. > > The disconnect here, I believe, is offloading to hw the Linux > forwarding plane vs. offloading an arbitrary application's forwarding > plane. Switchdev (and rocker) are about offloading the Linux > dataplane. That means Linux _is_ the application (the NOS); hw > offloads what it can from the kernel to accelerate pkt forwarding. > But the user's experience is standard Linux tools (iproute2, netlink) > and building blocks (bridge, bond, etc) are used to construct a switch > (or router), and the fact that the data path is offloaded to hw is > transparent to the user. We could define APIs for arbitrary > applications to program hardware, like John is suggesting. by giving > up raw access to hw resources, like tables, etc. This approach moves > the "driver" to the application, and by-passes the Linux tools and > building blocks. We're still TBD on these APIs, probably because of > the "by-pass" part.
Thanks Scott I think this helps some. I don't view my approach as a by-pass though or even letting arbitrary applications have access to the hardware. Today I load arbitrary filters and bpf programs into the kernel to create a pipeline. Now I want to string a couple other tables in front of my pipeline to do some of the heavy lifting. Maybe the real difference is my _datapath_ is not offloaded (by-passing?) the kernel. Most (all?) of my packets are meant for the host and I want to do partial offloading where some of the initial processing is done in the hardware and the rest is handled by software. The "driver" is not in the application it is still in the kernel. I almost have something ready to kick out I meant to do this today might be another day or two though. > > Jiri's patchset here is about moving things around so he can define > another hw mode in rocker. The upper edge for rocker driver is still > switchdev, but with the new eBPF hw mode he's working on, he'll be > able to push down a dynamic pipeline rather than being stuck with the > OF-DPA pipeline we have today (in rocker). I presume once he has this > new eBPF support, he'll program in a "Linux kernel" pipeline, and fill > out the corresponding swtichdev ops. I imagine a P4 -> ePBF compiler, > and we take a linux.p4 and program hw. Linux.p4 should be > generic...consumable by any hardware...it is a representation of the > Linux pipeline. (Similar to P4's switch.p4). > > But now, with eBPF mode in hw, an arbitrary.p4 could be written for > that arbitrary application and pushed down. We still need APIs for > that application. > My gripe here was flipping the hardware between modes with a string value. It seems it has been dropped from the latest version though so I have no problem with the patches. .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
