Associating the desire of NVMe vendors to allow users to ship down eBPF programs to run on the device and XRP is a major mistake in the article. XRP has nothing to do with what the NVMe vendors want to do, and XRP is a pure kernel solution that doesn't need any participation from NVMe vendors. I think it's unclear whether XRP even has real value - it certainly may, but I believe the benchmarking in the paper was deeply flawed[1].
I'm not closely tied to what the NVMe vendors want, so you could be right, but I very much doubt you are given that Christoph didn't flag this when he reviewed the article.
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.
I am very closely tied to what the NVMe vendors want, having written the first internal draft of the proposal to the standards body (since that draft many smart people have taken the pen and done a lot of great work).
XRP is unrelated to offloading eBPF to NVMe devices.
Sure, whatever. "Offloading" was perhaps a poor choice of wording, but it is related to the standardization efforts. The NVMe vendors don't want to be calling out to BPF programs in the driver if the runtime semantics are not standardized.
XRP is a regular BPF hook in Linux and requires no additional standardization. The device never "calls out to BPF programs in the driver" - it generates a normal completion interrupt and Linux runs a BPF hook in the completion path. This is no different than other kernel BPF hooks elsewhere and doesn't provide any additional reason or need to standardize BPF.
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.
XRP initially looks to be focused on moving work upstream into the kernel not devices.
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.
> the device itself calls back into a BPF function in the NVMe driver
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.
1. https://github.com/xrp-project/BPF-KV/issues/3