Even faster VM networking with virtual passthrough
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Number of Parts | 41 | |
| Author | ||
| License | CC Attribution - ShareAlike 3.0 Unported: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this | |
| Identifiers | 10.5446/18676 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
4
8
13
14
16
22
25
33
39
00:00
IntelProxy serverComputer networkStack (abstract data type)Meta elementRing (mathematics)Computer hardwareOverhead (computing)Process capability indexHuman migrationVirtual realityImplementationLine (geometry)Bit rateIndependence (probability theory)Read-only memoryMessage passingVirtual machineBus (computing)CuboidCartesian coordinate systemSoftwareFrequencyProcess (computing)Functional (mathematics)InformationSemiconductor memoryRight angleTelecommunicationProcess capability indexDirection (geometry)Point (geometry)Shared memoryTouch typingQuicksortBand matrixArc (geometry)Physical systemNumberOperating systemPointer (computer programming)Group actionVery-high-bit-rate digital subscriber lineMaxima and minimaBit rateWater vaporMereologyMultiplication signFerry CorstenHeegaard splittingAbstractionFunction (mathematics)Ocean currentGeneric programmingEntire functionSocket-SchnittstelleDifferent (Kate Ryan album)Execution unitWeb 2.0Single-precision floating-point formatRule of inferenceCommitment schemeLevel (video gaming)Data managementParticle systemComputer hardwareBuffer solutionCASE <Informatik>Operator (mathematics)Proxy serverVirtualization2 (number)PCI ExpressStack (abstract data type)Flow separationPhysicalismÜbertragungsfunktionComputer animation
07:19
Denial-of-service attackVirtual realityBlock (periodic table)Standard deviationMetropolitan area networkTrans-European NetworksClient (computing)Kernel (computing)Personal area networkComputer networkModul <Datentyp>Front and back endsMereologyOrbitQuery languageProcess (computing)Product (business)Form (programming)Order (biology)Point (geometry)Functional (mathematics)Semiconductor memoryAdditionSoftwareCartesian coordinate systemSound effectResultantLevel of measurementPrimitive (album)Execution unitKernel (computing)Shared memoryWater vaporVulnerability (computing)Flow separationVirtual machineArithmetic meanBuffer solutionComputer programmingAreaRevision controlSet (mathematics)Pointer (computer programming)Bounded variationSystem callSpeicheradressePhysical systemBit rateComputer architectureGame theoryAeroelasticityMultiplication signStreaming mediaStandard deviationData structureQueue (abstract data type)Overhead (computing)Adaptive behaviorGame controllerSelectivity (electronic)File formatComputer hardwareBeta functionSpacetimeData transmissionMemory managementStapeldateiBitComputer animation
14:38
Computer networkModul <Datentyp>Front and back endsDevice driverMetropolitan area networkStandard deviationOverhead (computing)Arc (geometry)Virtual realityInterrupt <Informatik>Maxima and minimaCore dumpLine (geometry)ArmFlow separationVirtual machineTrailCartesian coordinate systemInformationKernel (computing)Device driverTranslation (relic)View (database)SpacetimeRing (mathematics)Front and back endsInstance (computer science)Source codeMereologyOverhead (computing)Queue (abstract data type)Bit rateBuffer solutionPointer (computer programming)Physical systemFile formatParameter (computer programming)Point (geometry)Order (biology)Semiconductor memorySemantics (computer science)2 (number)Data managementMathematical optimizationStapeldateiImplementationInterface (computing)Content (media)Vapor barrierMultiplicationMultiplication signComputer architectureSet (mathematics)CuboidWeightOntologyMathematicsSystem callForm (programming)Software testingPerspective (visual)Process (computing)SynchronizationKinematicsComputer animation
21:57
Device driverCore dumpLine (geometry)AliasingMetropolitan area networkArmGamma functionBlock (periodic table)ImplementationWeb pageRead-only memoryMessage passingInformationMaxima and minimaSystem callPhysical systemMathematical singularityKernel (computing)Group actionProgrammschleifeOvalFreewareValue-added networkState of matterRing (mathematics)Pointer (computer programming)FlagBefehlsprozessorAsynchronous Transfer ModeSoftware testingModule (mathematics)IntelDDR SDRAMDuality (mathematics)Front and back endsEmulationMeta elementBit rateStapeldateiBus (computing)Frame problemStorage area networkUniformer RaumWechselseitige InformationHexagonPort scannerLink (knot theory)Extension (kinesiology)GoogolComputer networkModul <Datentyp>Client (computing)Trans-European NetworksVirtual realityExecutive information systemComputer hardwareIndependence (probability theory)LogicQuicksortStapeldateiCodeDrop (liquid)Thread (computing)Chemical equationNumberCartesian coordinate systemBitPhysical systemRule of inferenceBit rateWeightInteractive televisionSoftware testingLevel (video gaming)System callVirtual machineKernel (computing)MereologyThresholding (image processing)Queue (abstract data type)Descriptive statisticsInterrupt <Informatik>Decision theorySoftwareSemiconductor memoryComputer hardwareGraph (mathematics)Asynchronous Transfer ModeResultantAddress spaceData transmissionFlow separationBlock (periodic table)VirtualizationState of matterMessage passingCodeMultiplication signStudent's t-test2 (number)Pointer (computer programming)Line (geometry)Computer configurationAdditionSpacetimeCASE <Informatik>Point (geometry)Device driverSet (mathematics)MeasurementINTEGRALReal numberRing (mathematics)MappingBridging (networking)Web pageCache (computing)Touch typingInformationBuffer solutionGame controllerDifferent (Kate Ryan album)PlastikkartePatch (Unix)Band matrixStandard deviationFeedbackFerry CorstenDirection (geometry)Resource allocationComputer architectureFormal languageExecution unitCycle (graph theory)Text editorForm (programming)Reverse engineeringBefehlsprozessorSweep line algorithmGroup actionRight angleFigurate numberAdaptive behaviorWechselseitige InformationProduct (business)Suite (music)Field (computer science)Integrated development environmentUniform resource locatorWindowWhiteboardMatching (graph theory)Greatest elementEquivalence relationDisk read-and-write headLattice (order)InferenceVideo gameAreaEndliche ModelltheorieGame theorySampling (statistics)Computer clusterError messageParameter (computer programming)LinearizationWordAutomatic differentiationMusical ensembleShared memoryGoodness of fitCellular automatonElectronic mailing listEvent horizonComputer animationProgram flowchartDiagram
Transcript: English(auto-generated)
00:05
The problem we're interested in is how to achieve high packet rates, which are a problem even on bare metal, even if we are talking about virtual machines here.
00:20
To achieve high packet rates in current system, people have resorted to bypass solutions. Either to bypass the entire operating system, like in 3D PDK or PF-free in DNA, or in the net-map case to bypass only the network stack.
00:43
Why this is done? Because high packet rates are typically needed in applications with neither direct access to packets coming on the network, and typically don't need all the processing done by the network stack. At the same time, to achieve high packet rates,
01:04
they need to have a small per-packet over it, per-packet work. So bypassing is the solution that is currently used.
01:26
In virtual machines, network function virtualization tries to move middle boxes, net firewalls, and so on inside virtual machines. Virtual machines are usually connected with each other with software switches.
01:41
In our group, we developed a fast software switch which is developed, and which is based on the net-map API, which is called Valle, which achieves for short packets, a throughput of four or eight million packets per second between two virtual machines,
02:04
which is good, but is still far from what the same switch can do between applications running on the host, which is 20 million packets per second. It's a software switch, so it's limited only by the memory bandwidth.
02:23
Then there is hardware pass-through, passing a device giving a virtual machine direct access to a real device. Of course, you need real hardware to do this, and you are limited by the communication which has to go to the PCIe bus.
02:42
Then there are virtual pass-through solutions, which are different from ours. One, our solution is in competition with this. They typically rely on this way because another problem with virtual machines, and also with the IPACK trace on bare-metal is notification.
03:04
The time involved in the processing of notifications, which in virtual machines also involved typically expensive virtual machine exits and reenters.
03:25
What we propose here is a pass-through of NetMap. So it is a solution two, which is specific to NetMap. What we're doing here is to give NetMap applications, application that already use the NetMap API to access the network,
03:44
a direct access from a guest to the host. So it's not a generic solution for, for example, application based on sockets. It's only for application that already use the NetMap API,
04:04
and it can achieve high speeds. The idea is to have these applications running inside the guest, we have as much as possible like application running directly on the host. So obtain almost the same numbers that can be obtained on NetMap on the host.
04:24
So line rate for physical adapters, 20 million packets per seconds for ballot ports, and strange numbers for NetMap. NetMap pipes only exchange packets,
04:43
and never touch the buffers that are exchanged. So they can be very fast. But of course, as soon as the application starts doing real things on the packs, those numbers drops dramatically.
05:04
With Vipass2, we can obtain the same, we can try to keep the advantages of NetMap, which is hardware independent, is a software solution which talks to hardware, but in the way operating system do that by providing an abstraction which isolates
05:25
the application from the real hardware. At the same time using commodity hardware, so you don't need, for example, for hardware pass-through, it's only feasible if you have an adapter which already has,
05:43
for example, single-rooted are able to have several hardware virtual devices so that you can give one, which virtual machine, and avoid busy polling because it doesn't play well for a general purpose API,
06:05
which should run in a general purpose operating system, which is maybe is doing other things. Using the things that NetMap already does,
06:25
we can end exporting the communication paths of NetMap to virtual machines. We can achieve virtual pass-through for hardware ports by passing a NetMap port that talks to an hardware to a virtual machine.
06:45
If we export Valley ports, Valley ports works by memory copy, and so we have isolation between virtual machines. So we can have untrusted virtual machine talk to each other. If we export NetMap pipes,
07:02
NetMap pipes use a shared memory to exchange communication. They don't copy packets, they just swap pointers, and therefore we can have communication between trusted virtual machines. The important point is all of these cases all use the same API.
07:26
So the decision of whether you trust the virtual machine or not, it does not depend. You don't have to change the application running in the virtual machine.
07:41
Okay, this is the previous work. Some quick reminder of how NetMap works. There is a shared memory area which is shared between. This is NetMap running on the host. This is a shared memory area where applications can talk with the kernel.
08:03
The shared memory area contains an abstract version of the queues of the hardware adapters and the buffers which contain the packets which have received and transmitted from the adapter.
08:24
A set of pointers define the part of the queue which is owned by the applications and the part of the queue which is owned by the kernel. Add points to the first queue slot
08:44
which is owned by the application, by the user. Tail to the first slot which is owned by the kernel. In the NetMap APIs, you move freely the add pointer,
09:02
but the kernel doesn't look at the add pointer while you're moving it. It only looks at that when you issue one of the NetMap API primitives, which is either an IO control or a standard poll or select system code.
09:23
When you move the add pointer, and for example, this is a transmit queue, you are saying that some other buffers now must belong to the kernel. In a transmit queue, this means that there are new packets to send. In a receive queue,
09:41
this means that you have finished working with the set of packets, and the corresponding buffers can be used to receive more packets. At the same time, the kernel updates the tail queue.
10:01
By moving forward, the tail queue, it gives other buffers to user space. In a transmit queue, this means that those buffer had been sent. Transmission has completed. In a receive queue, it means that new packets have been received.
10:22
So this is essentially the NetMap APIs. So the advantages of the API is you can have batching because you can move the add pointer by more than one slot, by as many slots as you want. So in one system call, you can send several packets.
10:41
There is no packet copy because the memory is shared, and many of the overheads involved in packet processing are removed. For example, memory allocation is done at the beginning, at the start of the application.
11:01
So the per packet overhead is very small, and this is what enables NetMap to achieve line rate on 10 gigabits NICs, or even 56 million packets in transmission on 40 gigabits NICs.
11:26
Using this API, we can do several other things. So the standard thing is talking with the real NIC. But using the same API,
11:41
we can have the values which have several application talk between them. This works by copying packets to achieve separation between the applications. And while the shared memory area used by the hardware NICs is always the same.
12:06
There is one system-wide area for all the hardware NICs, mostly for legacy reasons and whatever. Each valley port has its own private memory area.
12:21
Pipes instead are another variation which only talk to each other. The two endpoints of a pipe use the same memory, and pipes are a bit more flexible on the memory they use, because they use the memory of another adapter that you have to specify.
12:43
So this is one other adapter or valley port. This is a way to use the global memory or a private memory for a pipe. Okay, this is NetMap.
13:05
This is what we did when we added support for the NetMap, and valleys which is all the same because the API is the same in QEMO, essentially.
13:28
The architecture in QEMO is as follows. The guest, as far as networking is concerned, the guest sees an emulated hardware adapter,
13:44
which has its own queues and buffers, which are interpreted by a part of QEMO which they call the front-end. The front-end interprets the data structures which are shared in memory with the guest.
14:06
For example, they may be the one of the E1000 adapter or maybe the completely new format or beta.io and so on.
14:24
Whenever there is a new packet, the front-end sends it using this function called to the back-end, which talks to the host typically with a tap device, and there we added another kind of back-end which is a NetMap back-end,
14:44
which talks to NetMap. With this architecture, which is the one which is currently in the upstream QEMO,
15:06
we were able to achieve maybe between two guests, three, sometimes four, and five millions packets per seconds with short packets, but with many other optimizations which are not in the upstream implementation.
15:26
So the upstream implementation maybe can do two or three million packets per seconds, or even less. There are many problems with these architecture,
15:41
mainly the fact that the batching is not possible here, even if it is possible in an interface between the guest and the front-end, and between the back-end and NetMap, and the several packet copies are generally involved.
16:01
We try to avoid some of these copies, but we had the difficulties again because of this interface. Because it's not very easy to keep track of the ownership of the buffers, if you're not copying them through that interface. Moreover, each packet, the information regarding each packet,
16:28
which is the slot which describes the packet, has to go through two translations which are essentially useless. Especially if you're using NetMap in the guest,
16:42
the situation is this. An application opens a device in the guest, talks with the kernel in the guest, which is completely unaware of the fact that in the host, there is another instance of NetMap already opened,
17:01
which is the final destination of the packets it wants to send. So you put a packet in the NetMap ring in the guest, talking for example to E1000 emulated device.
17:21
When you send the packets, the information has to be converted to the format expected by the E1000, ring descriptors interpreted by the front-end, then again in the format expected by NetMap in the back-end. In the process, the content of the packets may also need to be copied.
17:49
So this is one source of overhead which is paid for every packets, and at high packet rates even if it doesn't seem so complex,
18:01
but at high packet rates, it can become significant. So this is what we have done now. We have essentially removed the front-end and back-end from the data path,
18:25
so that the application can directly access when the application is a NetMap application which opens in NetMap hold a device in the guest, it can end the back-end is NetMap, it can talk directly to NetMap.
18:47
At the same time, we also consider the other source of inefficiency in virtual machines which is the notification path.
19:00
We want the notification path, we don't want to do busy wait because this is one of the strength of NetMap. But notification in virtual machines are very expensive and so we
19:20
adopted essentially the same solution which is already adopted by Virta.io which I'm going to it later. So this is the situation. Now, when an application opens a device in NetMap hold in the guest,
19:49
queue descriptors and the buffers are shared between the application in the guest and the host. The guest device driver is completely removed from the path,
20:01
is not used anymore. The guest device driver is only used to set up the data path, then is no longer used. The same goes for the front-end and the back-end.
20:25
A finer point however is that the ring pointers are interpreted by the NetMap which is running in the guest. The reason for this is that as I said before,
20:45
we want to preserve NetMap semantics. NetMap semantics are simple for the management of these information because they behave like any system called parameters. The kernel only look at these parameters when you call this instant call,
21:03
doesn't look at them while you're doing other things. If it looks at them while you're doing other things, you have to be careful in managing them in the order in putting memory barriers in them and which is generally very hard to do. In NetMap, you write them, the kernel doesn't look at them.
21:22
Then you issue system call, the kernel looks at them and synchronizes its view with the user space view. We want to preserve this. Now, the only part here that can reliably do this is the kernel in the guest because it is synchronous with the application.
21:40
So it is the kernel in the guest which sees these pointers and updates them. This also means that the information must be passed in some other way to the actual user or the information which is in the host.
22:07
This is a bit of detail on how we implemented it. I think I can skip this.
22:22
This is a bit more in detail how the whole architecture is organized. There are essentially two parts. The most complex part is also the one that is not important for performance
22:41
because it's so resolved during the setup. This is this part. During the setup, a fake allocator running in the guest maps directly the host memory in the guest.
23:01
A set of callbacks are established so that an adapter is created that can talk to a fake driver in the guest. During the data path, the fake driver in the guest, the adapter, and the real driver in the host play the role of
23:21
the original driver in the standard net map architecture, which is one of those port drivers in the other picture. The information of the pointers on the queue is
23:43
exchanged by the guest kernel and the host kernel using a separate piece of memory which is not accessible to the application. This is done asynchronously. This is possible because this information is only
24:06
relative to the part of ring which is owned by the kernel, by the rules of the net map APIs. It can be done efficiently by using a virtual-like interaction
24:23
between the PT port driver in the guest and the adapter running in the host. They can look at this shared memory, write them their state if they are running or not, and the other party can use this information to avoid
24:43
notifying the other one, the peer, if it is already running. This is essentially what Vitayo does.
25:00
This requires a thread in the host. The simplest thing is to have a thread, which is started in the usual way when the thread is not running,
25:23
and an update is detected on the queue. The thread is started by using the usual part, BMX it which translates in a start of the thread. But if the thread is running,
25:41
it writes in the shared memory, CSB page that it is running. As long as it has something to do, the other party doesn't need to notify it. This is very important because the greatest cost in the notification
26:01
is exciting from the virtual machine mode in the guest. The same goes in the other way because delivering interrupts inside the virtual machine may be very costly, especially if you don't have posted interrupts.
26:43
So this is how the virtual act integration works. Each party is essentially a thread, a real kernel thread in the host, and an interrupt thread or a software you're
27:01
a queue in the guest, the IRQ in the guest. They are typically sleeping when they get an application, they go in the running state. When they are in the running state, they say they don't need to be kicked again. I think as long as they have work, they remain in the running state.
27:21
When there is no work, they return to sleep. This interaction looks simple, but it's very tricky really because we are creating a feedback between how much work,
27:42
how much the working thread has to do and the polling rate. This creates several counter-intuitive behaviors. For example, if the working thread is faster,
28:07
this may cause a great drop in the performance because it goes to sleep much more often, and it has to be notified much more often,
28:21
and notification are expensive for the other thread. On the other hand, delays in waking up can be useful, because when the party wakes up,
28:42
the other descending party, for example, at the time to create larger batches, and many things like that. So it's really rather tricky.
29:01
So I think I can go to the measurement. This is what we have measured, the performance between guest and host, the host and guest, and guest to guest, and host to host as a reference. Because now, all these applications are using the same API,
29:25
and we want to have the guest applications behave like the host one, the one running directly on the host. The tool we use is a package M from the netmap suite,
29:42
which just sends packets without actually touching them. So memory considerations and cache misses are not, and TLB misses are not involved.
30:01
Then we can have a physical port and pass through to the guest, either for transmission or receive.
30:21
Okay. So for a physical port, we essentially achieve line rate even for short batches, both in transmission and on the receive part.
30:43
This is expected because essentially now, the guest application is almost indistinguishable from native netmap application which already receives line rate.
31:03
For Valley ports, we have a bit of a surprise first, because applications running in the guest are actually faster, even much faster. The corresponding application running directly on
31:21
the host are the lower part of the graph. But this is explained as follows, because we have added another thread in the system, which is the one which is actually doing the real work.
31:49
In an application running on the host using Valley port, the actual copy is done by the thread that issues the netmap call.
32:03
You issue an account, you issue a poll, the thread copies the data. In this setup, the application is running in the guest, and just notifies the other thread running in the host,
32:21
which then does the actual copy on the port. Moreover, if the virtual-like interaction is working well, notification doesn't cost anything. So that thread is very fast. It's not the bottleneck. The bottleneck is simply this thread,
32:42
which is faster than the equivalent situation in the host, because it is a kernel thread, it doesn't have to issue system calls.
33:05
Anyway, apart from this thread which you could add even to the host, the result is good because the application can reach the more than 20 million packets per seconds the Valley supports.
33:23
This is for larger frames, essentially the same thing. This is for pipes. Again, the application running in the host are faster, in the guest are faster. This time even much faster.
33:40
The green line is for a package running in the guest, while the blue line, the red line is the one on the host.
34:02
For pipes, transmission is very simple. You issue the call, and then the packets you want to send are swapped with the free slots found in the receiving end of the pipe.
34:23
So it's just a swap of pointers in the rings. The guest is faster again because there is this additional thread. That's the reason. Anyway, you can see that there
34:43
is a very big drop of performance when the batch size is the number of packets, the package end sends for each call goes beyond a certain threshold.
35:04
This is one of the things that happen because the actual interaction in notifications between two threads that work like Virtaio is actually very tricky. This is one of the situations where something tricky happens.
35:22
Here, we can also see how the system behaves when we change the queue size for different queue sizes.
35:41
For small batch sizes, package end running in the guest is the bottleneck. Essentially, for the cost of executing the system call. Essentially, for the system call.
36:01
Not for the notification because the thread that has to actually do the work is kept running by our Virtaio-like interaction. So we can achieve high packet rates.
36:24
But when the batch size increases, this adds no additional cost for package end running in the guest, because it's essentially always doing the same thing because it doesn't touch the packets. So it's just a number that it writes at the pointer,
36:40
it writes a bigger number. It doesn't have to do anything more than that. But more work is added to the thread that actually has to swap the packets. At some point, that thread becomes the bottleneck. When that thread becomes the bottleneck, package end in the guest becomes faster and eventually fills up the queue.
37:03
When the queue is filled, it has to be notified. Notification is a cost for the one that sends the notification. So the thread that is the bottleneck is slowed down by the fact that it has to wake up the package end running in the guest.
37:25
So it has to wake up more and more until in the end, it wakes up once for every batch. That's the limiting point. If you increase the size of the queue,
37:44
you obtain the same behavior limiting at higher values of throughput because for each batch you're sending more packets. Okay, so also latency is important.
38:01
Of course, latency is very different if the receiving party is already running or not. We think, however, that the numbers are reasonable. If you have to do all the notification, the other parties is sleeping and you have to wake him up. We can obtain, for example,
38:25
in the worst case between two guests, 25 microseconds. If the other party is already running, we can obtain much smaller times.
38:52
Okay, in the final test we did, we tried to connect the several virtual machines, each running a NetMap bridges always from the NetMap suite,
39:05
connected by NetMap eyes but performing copies for technical reasons. Even if they're using NetMap pipes, they are actually copying packets from one machine to another.
39:20
We compare these with, again, the same applications running directly on the host. Of course, there is a performance drop, but it is 15 percent of the original, which we think it should be acceptable.
39:42
Of course, there is a drop because there are copies. We have yet to perform the test with a full zero copy path.
40:00
This is the conclusion. What we have implemented of all these? Of course, we have to modify several things to implement this. We have to modify NetMap both as a guest and as a host. We have to modify the hypervisor and the guest kernel.
40:26
Okay. The hypervisor, we found it easy because we had already experienced, so we have modified QEMO. But there is work supported by Google Summer of Code granted to modify also BI. We have already modified as a guest both Linux and FreeBSD.
40:47
All the code is available in that GitHub address. Stefano Garzarella is the guy that actually did much of the actual coding as a student at the University of Pisa.
41:06
Okay. Thank you. I'm done. Questions? Okay. Yes. So, I actually have one question regarding the wake-up logic that you had in there.
41:21
I think it's really interesting because back in 2008, I was working on the FreeBSD's T2I layer, and it's also sort of a pipe in a certain way, right? The data comes in, they pick up. What I noticed is that the old T2I code had as well. There's sort of this funny logic in it that if the buffer is full,
41:41
and the other side gets first data out of it, you don't already wake up the sending side. Because the problem is that if it only gets one byte out, you just wake up the other process, writes one byte back in, and it's really annoying. So, what happens is there's this logic in there that it only sends the wake-up to the other side if actually say half of the buffer.
42:02
Yeah. That's one of the several tricks that can be done to improve the situation, but there are many more others. We're actually studying this for a long time. We're trying to create more complete control of the situation,
42:21
and there are many possibilities. This is one, for example, is implemented already in Virta.io. But it's only possible in one direction, not in the other. Because in this one direction, when you know that there are already packets.
42:41
There is the other direction where you know if the other packets are coming. So, you cannot delay the notification as much as you want, unless you try to create a balance between latency and throughput. But this is a political decision.
43:01
Okay. Which one are you referring to? Sorry.
43:25
There is a description. This kind of control is not implemented yet. The only control that is here is that keeping the running thread the wake-up, keeping it alive for a bit longer, even if it observes that there is no traffic.
43:44
It doesn't immediately go to sleep. It waits for a bit, which is a parameter, which has to be tuned and so on. Now, the fact that the rx is lower here, I think it's simply because the receiving path is more inefficient.
44:05
Receiving an interrupt is more inefficient than actually writing in a register, which is what figures the VM exit and so on. So, there is no control implemented here.
44:21
This is all future work.
44:41
Well, as long as Ese Dayavu gives me what looks like an hardware adapter, I can use netmap on it. The point is if I have a native adapter of it or not.
45:01
We have a generic adapter for any kind of NIC, but which is, of course, it's not as fast, it cannot achieve line rate. But for any hardware adapter, we can patch the driver, we'll have a native adapter, and see what we can do with that. The rest is independent for this. As long as we have a netmap port adapter for NIC,
45:24
we can pass through the device. What? Ese Dayavu? I don't know. It depends on the network card.
45:46
Yeah? Just receive on the other VMs, and that can be a lot more limited than-
46:02
That's what we mentioned here. Okay. We mentioned it in the beginning, yes. Yeah. Yeah, yeah. With a software switch like Valley, we are just limited by the memory bandwidth.
46:31
It's on the works. It's on the works because on BI, there is no E-1000, so we are moving to virtual.
46:42
It's not very important because again, the device, it's only used to set the things up. Then in the data path, nothing is used of the device. So, it's rather- just what is a Bible,
47:04
we can patch it to support the pass-through. Okay. As I said, this is only for netmap applications. Netmap applications running in a gas.
47:21
If you want TCP, you have the other options that already have if you want to use netmap in the host. Use a space TCP, for example, or nothing else.
47:50
Well.
48:04
It's not a ready toolkit, if you just want a little performance like that, but that's the place we're running in now. I think as the API evolves, you should be building blocks, like I just wanted to end-cap or end-cap off of a netmap path and then it'll be building blocks like you said,
48:27
or maybe re-acsembling and that's the idea. So, they are- We should probably wrap up for the next speaker.
48:41
Yeah, yeah, they sent me two things. We can talk.