On Wed, Dec 02, 2015 at 03:35:53PM -0800, John Fastabend wrote: > [...] > > BPF. Implementing protocol generic offloads are not just a HW concern > > either, adding kernel GRO code for every possible protocol that comes > > along doesn't scale well. This becomes especially obvious when we > > consider how to provide offloads for applications protocols. If the > > kernel provides a programmable framework for the offloads then > > application protocols, such as QUIC, could use use that without > > needing to hack the kernel to support the specific protocol (which no > > one wants!). Application protocol parsing in KCM and some other use > > cases of BPF have already foreshadowed this, and we are working on a > > prototype for a BPF programmable engine in the kernel. Presumably, > > this same model could eventually be applied as the HW API to > > programmable offload. > > Just keying off the last statement there... > > I think BPF programs are going to be hard to translate into hardware > for most devices. The problem is the BPF programs in general lack > structure. A parse graph would be much more friendly for hardware or > at minimum the BPF program would need to be a some sort of > well-structured program so a driver could turn that into a parse graph.
I'm looking at bpf as a way to describe the intent of what HW or SW has to do and in case of SW it's easy to JIT and execute, but nic/switch doesn't have to 'execute' bpf instructions. If it's fpga based it can compile bpf program into parallel gates. Less flexible HW would not be able to off-load all programs. That's fine. Long term flexible SW will push HW to be flexible. -- 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
