Edit: And to be clear, from my understanding of XRP, the device itself calls back into a BPF function in the NVMe driver. That requires some notion of standardization. It's not exactly offloading directly to the storage device, but the storage device still relies on some standardized behavior in the BPF program, such as divide by zero, what instructions are supported in the ISA, etc.
XRP is unrelated to offloading eBPF to NVMe devices.
The article misstated that XRP was a framework used for offloading BPF programs to NVMe devices. That's not correct, and XRP is not one of the emerging use cases for BPF that is driving standardization.
But absolutely, once you start shipping ebpf into the kernel, people do quickly start asking, "how can we hardware accelerate that?". Having standards would be helpful.
This statement contradicts itself. A driver (a “kernel module” in Linux lingo) runs in the kernel, and sure, that driver can call out to BPF or whatever else it desires, but then that isn’t the device doing so, that’s your computer (running your Linux kernel, in turn executing the aforementioned kernel module / driver) doing so.
Restated from another perspective, drivers don’t run on devices. Something may run on devices too, but that’s different, and we’d call that something like “firmware”.
Edit: the intended takeaway being that device manufacturers/designers should have little to gain from BPF being standardized (unless that BPF is being executed on the device, as this now implies an API contract between device and host) — a driver can always declare that the semantics is whatever the Linux kernel does and call it a day.