Hacker News Reader

Comment by wtallis | Hacker News Reader

There's also some interest in making eBPF the standard for computational storage [1]: offloading processing to the SSD controller itself. Many vendors have found that it's easy to add a few extra ARM cores or some fixed-function accelerators to a high-end enterprise SSD controller, but the software ecosystem is lacking and fragmented.

This work may be a very complementary approach. Using eBPF to move some processing into the kernel should make it easier to later move it off the CPU entirely and into the storage device itself.

[1] https://nvmexpress.org/bringing-compute-to-storage-with-nvm-...

View on HN

The draft spec is here:

https://www.snia.org/sites/default/files/technical_work/Publ...

Can I get Postgres running on a RAID controller while we’re at it?

Imagine an SSD serving up query responses! I love it.

Not too far from Netezza.

Samsung's SmartSSD comes with a Xilinx FPGA accelerator that can be used to execute code without having to move data outside the device. And their open source SDK includes domain-specific routines including databases.

See https://xilinx.github.io/Vitis_Libraries/ for details on their software stack.

It's not SQL, but Samsung made a Key Value SSD that uses short keys instead of "addresses" to index blocks of data.

It's been done.

wasn't it the other way around ? The vendors got extra cores from their suppliers and started asking themselves what to do with them?

By "vendors", I meant drive and controller vendors rather than server/appliance vendors. They're looking for ways to differentiate their products and offer more value add, but extending an SSD's functionality beyond mere block storage (potentially with transparent compression or encryption) requires a lot of buy-in from end users who need to write software to use such capabilities.

I meant the Seagates and WD's from this world. Around 2014 they also had HDDs with an extra core, where I suspect they just got that for free from they supplier with the message "look, we stopped making these single core CPUs anymore, here's a dual core for the same price".

WD and Seagate are their chip vendors. They design their own custom SoCs.

In case of Seagate's Kinetic Drives, one core was used by the controller, the other 'extra' CPU was used to manage a Key value store on the driver. These were ARM processors. I don't think they make these themselves.

You would be wrong. I work with guys who used to do SoC design for both Seagate and WD.

This is how WD was able to jump to RiscV so quickly; they didn't have any suppliers they needed to negotiate with, and the market for CortexR style in order, single issue, fully pipelined real time cores is sort of a commodity.

Well, that's why I was asking. Thx!

I'd prefer it to use spirv or wasm. eBPF is intentionally an extremely limited language.

But trivially provable termination is really nice property if you don't want to need your hypervisor to trust every guest kernel.

eBPF the bytecode is not particularly limited. You can parse complex formats like Arrow or Parquet even. The Linux kernel overlays a verifier on top which adds all sorts of draconian restrictions (for good reason). When people talk of eBPF they don't always mean to include the Linux verifier limitations as well. In particular, that nvmexpress working group link in the parent post does not say one way or the other.

Why not use a different bytecode that is already more common, in that case?

Because ebpf is designed for verification under constrained circumstances like kernels, but allowing easy JITing that's almost a 1 to 1 translation. Stuff like not doing register allocation, being 2 address, etc.

So basically back to SCSI.

I'm not seeing any new parallels to SCSI, beyond the similarities that have long existed between NVMe and SCSI. What kind of programmable functionality over SCSI are you referring to?

SCSI uses their own controllers that receive a set of commands and take it from there for the data retrieval operations.

https://en.wikipedia.org/wiki/SCSI_command

SCSI uses simple fixed command sets, the same as standard NVMe drives. As far as I'm aware, SCSI doesn't have any way to chain commands together, so you can't really do anything more complex than predefined commands like copy or compare and write. It's nothing at all analogous to an actual programmable offload engine like you'd get with eBPF, and all the semi-advanced SCSI commands that are actually applicable to SSDs already have equivalents in the base NVMe command set.

Reply on news.ycombinator.com