3 ms·

Based on the blog posts & diagrams linked here, the main innovation seems to be the use of virtio as a transport mechanism for the high-level "accelerated" func

Based on the blog posts & diagrams linked here, the main innovation seems to be the use of virtio as a transport mechanism for the high-level "accelerated" functions. The portable API is a good idea, but could just as easily connect to a well-known gRPC service address (which could be always on-host, or not). In that case, the transport would be good ol' virtio-net (or whatever), but is otherwise the same to the user. I suppose that with virtio, you can perhaps eliminate one copy (but not necessarily, since you'll probably need to copy from the guest memory into some device-mapped buffer). Other than it being fun to write virtio backends for various hypervisors, I'm not sure what the compelling advantage is over the more naive transport? Perhaps I'm missing something.

_ananos_ 6y ago
indeed! virtio helps us tailor the transport layer to an acceleration use-case, rather than just frames to be transmitted or blocks to be completed. The interesting turn on vAccelRT (of the runtime system that is) is that apart from the simplicity for running on a VM that the virtio backend gives, it seems that people are eager to use the vAccelRT mechanism, to map a complicated piece of code to a simple function call that is hardware agnostic. We'll see how this will turn out... After all, API remoting is out there for quite some time (see rCUDA); some people are using it, but we think that a more general, semantic abstraction needs to be introduced... especially for the Serverless use-case.