The next session will be by Damien about SDK with Zen, so enjoy the session.
My name is Damien.
I'm looking at practice and doing a presentation as the French university comes to guard.
I'm interested in the presentation which is a software based in Grenoble.
So VATES is the one most popular company behind this project,
and we want to do better with what we have because of some problems that we approach.
So my focus is on the storage visualization part of the supervisor,
and we currently have a very programmatic approach to the storage of the platform.
So if you can see on the left that we have a bare metal NVU storage,
and when we add the visualization stack from inside of the end,
we have 300% of the power of the NVU inside.
So what we want to do is to keep the storage of the security,
given by the ten balizer, given the stack style.
We want to have less impact as possible in the user.
So we want to minimize the impact in users,
so we want them to have to utilize things too much in the virtual machine
or too much in private.
So what I'm proposing is to use...
So first I want to introduce the problem with Xamarin.
Xamarin is a type when it arises,
and it is stored as the storage that runs first on the hardware.
And to be able to use rather a storage platform and network,
we have to release something which is no special,
not a virtual machine, a Linux.
That is running second.
Then it's initializing CPU, then running a virtual machine.
This is given, then control on the storage platform and the network.
So this VM is very important,
because it has the responsibility of sharing a network and storage for other VMs.
So what I'm proposing is...
I'm focusing on NVMe.
Well, it's in the case, for example, in NVMe.
And we want to focus on the NVMe part.
So NVMe is a new storage protocol for you.
It's been around for a few years. It's everywhere now.
So that is giving us a lot of better preferences inside of it.
So I have to introduce some things of concern.
So we have all done zero virtual machines,
but this can share the storage for other virtual machines.
And to do that, we have what we call a speed driver.
So we have a specialized protocol from VLJ for the same case.
That is used to transmit block storage requests from the VM to our back end, running on zero.
So most of the time, it's, for example, a new data from the driver,
that is presenting itself as a block driver in the distributed machine.
So it's already in place since a long time,
so it's obscuring the lay-downs, so it's not...
So it's been running also since 2015.
And the back end, currently in the XP engine,
back end status, that is, a new space program
that takes multiple requests,
and it's via IO to transfer them to the VM zero block area.
In that, we have a special interface to share memory between the VM,
that is used in the VLJ protocol,
where block request from the return machines to our VM zero.
This interface is mediated by the provider,
so it's then in place.
We have the return machine that we usually call the VM.
We're basically telling the parallelizers that the memory will be granted access to, by, to VM zero,
but it's in the return machine.
And the VM zero need to ask the parallelizer to map its system memory into its own memory,
to be able to access it.
So I have already replaced that disk in our limitation,
because we want to use the screen care in place of that disk,
and we want to directly take care of requests,
and transmit it to the VM.
So to talk to you about more about the screen care,
the screen care is the storage performance that we're looking at,
but in the world you may be created by install,
but it's used by your device maintenance.
It is essentially a driver for the admin using devices,
and it will be on the user space, in our case, in terms of work,
and it's used in Linux, and in RedMetal also.
So it's part of the same project as the 50k,
but it's a great feature.
Intercary on two?
Yeah, that's a problem to provide.
Okay, awesome, thank you.
So here we have the current state.
So we have two times the block layers that need to be traversed for one request.
It's one of the costs that is adding to the difference we have with RedMetal.
So our proposal is to use SPDK to directly transmit BLKV requests
from a virtual machine to a storage platform, a storage device,
and to reduce the cost by biasing the kernel in Dom0.
It's completely transparent for the virtual machine
because we reuse a lot of the infrastructure already present.
So to take a BLKV request, it's a simple structure in a shell memory,
in a ring, it's not very much different from Viertaio in this aspect.
And we have a multiple request type, so read, write, or discard everything.
I'm going to focus on read, write because it's the minimum we need to put on
to be able to take requests.
And we just have to transfer them to a SPDK interface.
So SPDK needs to use a special memory to be able to transmit it to the device.
So we need to use the SPDK allocator, memory allocator,
to be able to have a buffer that will be used to go from the device.
So we need to have the data copied from the virtual machine to our Dom0.
Then we can transfer it to the disk.
So it's pretty simple. We allocate memory.
We copy the data using the Grants table interface into our memory.
Then we just write it on the disk.
SPDK will call a callback that we've given it when it is finished
and then we can do the same for the read requests.
So it's working great for now.
So as you can see, the read request, the first and the second column are not very great,
is because the implementation is not finished.
And in this case, I'm doing more grant calls to the supervisors than on the write request.
So it's a big cost of our implementation.
But for now, it's done and we'll look into improving it.
But we are doing better than that.
This is on the right.
The blue column is that this is the grant status.
And our implementation is the red on the left.
So same for block size and throughput.
So we are able to improve the performance of our storage stack in a transparent manner for VM
because they can use normal VMs at boot today on the tab disk in the current infrastructure of the stage
and still make it work.
The problem, we have to use NVMe dedicated to the SPDK platform.
But NVMe is pretty much everywhere nowadays, even in data centers, especially in data centers.
We are still capable of using the security of the grant table because we keep the state of where the VM only shares
data that want to be written on the disk with the backend in SPDK.
And then still doing the mediator for this.
What we want to do is, of course, having the read request being better than the tab disk,
which since we are in some case, for example here, at the same level, without this optimization,
I'm not very worried about that.
But we want to be able to not have to copy data from VM into DOM0 then,
having it being handled by the NVMe and use directly the guest memory as source and destination
for the DMR request from the NVMe drive.
And we want to take a look at the grantable interface to see if it can be improved for modern days computing.
So I'm finished.
Thank you so much.
Question?
Yes.
I know from operating OpenStack Cloud that DPDK is very hard to install and implement.
How hard is it to implement SPDK?
The first question is, very quickly, is your work somehow can be applied to KVM visualization tool?
So the question is if SPDK is hard to use like DPDK and if it can be used in the KVM infrastructure.
So it has always been used in the KVM infrastructure to be as a storage platform for Vietaio guests.
It's just that our case is special because of the different architecture between KVM and them.
So it's already done by the SPDK community in this way.
I would say that this SPDK is not very hard to install.
In our case, it would be given with the app advisor and the install of XPNG,
but it's not very hard to install.
We just have to have a special configuration for our DOM0
because the SPDK is relying on a super page of 2Mhp to be able to do DMR requests.
And so we have to have this support and it's not available in the basic configuration of DOM0.
Yes?
Does your implementation survive the crash of the SPDK process on those?
Well, yes.
The question is if the application is surviving the crash of the SPDK process.
So the virtual machine would be able to survive the SPDK not being available.
We would lose the disk in the virtual machine.
Well, it would be, it would hang in the virtual machine for the disk,
but the virtual machine would still be able to run with the problem.
Any other questions?
Thank you.
Thank you again.