VAccel: Hardware Acceleration for Lightweight Hypervisors(vaccel.org)
vaccel.org
VAccel: Hardware Acceleration for Lightweight Hypervisors
https://vaccel.org
10 comments
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.
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.
More info on how we use it on AWS Firecracker is available on our blog post: https://blog.cloudkernels.net/posts/vaccel_v2/ and our github pages: https://github.com/cloudkernels/vaccelRT, https://github.com/nubificus/docker-jetson-inference
The block diagram here: https://blog.cloudkernels.net/static/vaccel_v2/vaccelrt.png#... should probably have some close variant on your home page, I've been around for 20 years and couldn't tell /at all/ what vAccel is.
My best guess was something to do with making VMs run faster
My best guess was something to do with making VMs run faster
thanks for your feedback! we will try to clarify things on our next posts!
in short vAccel is a framework that translates function calls from users (upper side of this diagram) to the relevant functions of the respective acceleration framework (lower side of the diagram). For instance, calling a function like image_classify (user function) would result in the respective image_classify of jetson-inference, which would, in turn, execute the image classification function on the GPU and return the result to the user.
hope that makes more sense!
in short vAccel is a framework that translates function calls from users (upper side of this diagram) to the relevant functions of the respective acceleration framework (lower side of the diagram). For instance, calling a function like image_classify (user function) would result in the respective image_classify of jetson-inference, which would, in turn, execute the image classification function on the GPU and return the result to the user.
hope that makes more sense!
So rather than new hardware, this seems to be an application level API to abstract away hardware and provide portability between the supported targets.
yeap, the initial idea was to cover VMs (and one of the use cases is indeed Serverless, for instance AWS Firecracker), but as it turns out, there are users that might benefit from this simplified abstraction in general.
This seems pretty neat as I've just started working a project using firecracker. Are the virtio-accel frontend/backends both kernel modules?
the virtio-accel frontend is a kernel module. The backend is VMM specific, so there is one for QEMU and one for AWS Firecracker. Check out https://blog.cloudkernels.net/posts/vaccel_v2/ to give it a try and let us know your thoughts!
Ahh, that makes sense. Thanks!
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.