Flexible Virtual Machine Networking Using
Netmap PassthroughVincenzo Maffione, Luigi Rizzo, Giuseppe Lettieri
Dipartimento di Ingegneria dell’Informazione
Università di Pisa, Italy
Email: v.maffione@gmail.com, {rizzo,g.lettieri}@iet.unipi.it

Abstract—The rising interest in Network Function Virtualization (NFV) requires Virtual Machines (VMs) to operate withdiversified networking workloads, from traditional, bulk TCP
transfers to novel ones featuring extremely high packet rates. In
response, researchers have explored and proposed new solutions
for high performance VM networking, including optimizations
to virtual network adapters (such as VirtIO) to support highspeed bulk traffic, and alternative frameworks for userspace
networking and physical or virtual passthrough.
To date, we are still missing a comprehensive solution that
supports such extreme workloads across multiple operating
systems and hypervisors, while at the same time addressing otherrequirements such as ease of configuration, operating system
independence, scalability and isolation.
In this paper we present ptnet, an approach to network I/Ovirtualization that provides high performance for both traditional
TCP/IP and high packet rate applications. ptnet leverages thefeatures of the netmap framework (including virtualizationand passthrough support), and defines a simple yet performant
network device model that can be easily supported in different
operating systems and hypervisors. We prove the effectiveness of
our approach by comparing ptnet’s performance with one of thestate of the art I/O virtualization solutions, namely VirtIO on
Linux and QEMU/KVM. ptnet is available under a BSD license
as part of the netmap distributions on github.

I. I NTRODUCTION
The strong industry interest for Data Center solutions,
together with recent developments of Network Function Virtualization (NFV) architectures, has led to explore different
approaches for network I/O virtualization.
Platforms must simultaneously support high performance,
multi threaded, bulk TCP communication, and high rate packet
processors. At the same time, they must provide isolation
between VMs belonging to different tenants, scalability, compatibility with different operating systems and virtualization
platforms, and ease of configuration.
Current solutions address only a subset of these requirements, as we discuss next.
Specialized virtual network devices (e.g. virtio-net, vmxnet)
address bulk TCP communication, but often deliver highperformance only on specific OSes and hypervisors. As an
example, one of the most successful open-source solutions
for network I/O virtualization, VirtIO [15], is available fordifferent hypervisors (QEMU, bhyve, Xen, VirtualBox) andoperating systems (Linux, FreeBSD, Windows), but the most978-1-4673-9882-4/16/$31.00 c 2016 IEEE

performant and feature-rich implementation is for QEMU
running on Linux with KVM enabled.
Applications that require extremely high packet rates normally rely on hardware support in the NIC (exporting multiple
NIC instances to virtual machines) and in the hypervisor (PCI
passthrough). These features give the guest OS direct accessto hardware resources, and let it use “kernel bypass” solutions
such as DPDK [9]. At the same time, this approach introduces
a scalability problem (as the number of virtual NICs that canbe exposed is limited, and they all go through the PCI bus
which is a significant bottleneck), and dependencies on specifichardware.
In the past we have worked extensively in this space,addressing high packet rates, device independence andisolation. Our netmap framework [10], high performance
VALE switch [12], hypervisor enhancements for high packet
rates [13] and virtual passthrough solutions [5] led to excellent
performance in terms of packet rates, complete device independence and extreme simplicity in terms of configuration.
However, our hypervisor optimizations [13] do not match
the performance of state of the art solutions (such as VirtIO on
QEMU-KVM) in terms of latency and bulk TCP/IP throughput, and our virtual passthrough device [5] cannot be used by
the guest network stack - and so by legacy applications - as aregular network interface.
In this work we present ptnet, a virtual device for VM
network I/O that uses the netmap data format as the underlying device model. ptnet extends our previous passthroughwork [5] to add those features that were missing in order tobe a comprehensive solution. As a result we are able to build
very simple guest device drivers that deliver state of the art
performance for both traditional TCP/IP applications and novel
high packet rate applications, and natively support multi queue
operation.
The contributions of this work, compared to [5], are (i)a new multi-queue paravirtualized device model to exporta passed-through host netmap port (ptnet), (ii) efficient
access to the port even for legacy guest applications, (iii) a
performance comparison between our solution and VirtIO, andfinally (iv) an actual implementation of both guest OS andhypervisor support for ptnet.
We show that ptnet can reach or beat VirtIO networking
in terms of performance and flexibility, with the additional
capability of supporting fast netmap applications, which can

process up to 10-100 Mpps. Finally, considering that netmap
is currently available under Linux, FreeBSD and Windows, we
argue that the effort of supporting ptnet on other platforms
than Linux/QEMU - with the same performance – will belower compared to VirtIO.
A ptnet prototype for Linux and QEMU-KVM is alreadyavailable as opensource, included in the netmap distribution
on github.com/luigirizzo/netmap.
Other works [6], [8] sought for performant VM networking,also addressing control plane functionality to manage NFVchains and QoS. ptnet does not address control plane issues,
since those can be provided by orthogonal hypervisor solutions [7] or third party software.
In the rest of this paper, Section II provides some background about netmap and its passthrough virtualization technology, as well as VirtIO; Section III describes ptnet architecture and implementation, and a comparison with VirtIO
networking; Section IV provides experimental evaluation ofptnet, continuing the comparison with VirtIO.
II. BACKGROUND
We briefly describe two representative mechanisms used in
VM networking, namely VirtIO and the netmap framework.
A. VirtIO and I/O paravirtualization
VirtIO [15] is a widely deployed standard for I/O paravirtualization, similar to other paravirtualized devices, where theguest device driver is aware of running inside a VM. Packets
are exchanged with the hypervisor through shared memory
Virtqueues (VQs), and the device is just a wrapper around the
VQs.
A Virtqueue contains: (i) a ring to exchange I/O buffers
for read/write operations; (ii) ring indices for synchronization;(iii) control flags. The VirtIO networking device (virtio-net)
can have one or more pairs of VQs, each pair representing a
TX and RX ring.
In the datapath, packets and the state of the queues canbe read through shared memory. Emulated I/O registers,
whose access causes a trap into the hypervisor, are only usedas guest-to-host notifications. Host-to-guest notifications use
hypervisor-specific interrupt injection mechanisms (usually
MSI-X interrupts, as they have less overhead than traditional
PCI interrupts).
Since notifications are expensive, VirtIO has mechanisms
to amortize their cost over multiple I/O operations. Both theguest device driver and the hypervisor suppress notifications
while they are actively polling the VQ, and enable them only
before going to sleep because no more work is pending. This
strategy is usually very effective at reducing notifications underheavy load. An analisys of these kinds of producer-consumer
synchronization mechanisms is available in [11].
B. Netmap
netmap [10] is a framework for high performance network
I/O. It exposes a hardware-independent API that lets userspace
application to interact in an efficient but protected way withnetmapapplication [B]netmapapplication [A]netmapapplication [C]netmap API
nm TX ring #1
nm RX ring #1

nm TX ring #1
nm RX ring #1

VALE switch
instance

nm TX ring #1
nm RX ring #1

nm TX ring #1
nm TX ring #2
nm RX ring #1
nm RX ring #2

netmap driver API

HW TX ring #1
HW RX ring #1
netmap-enabled NIC
driverHW TX ring #1
HW TX ring #2
HW RX ring #1
HW RX ring #2

netmap-enabled
NIC driver

Figure 1: The netmap framework. In the example, application
A works on two hardware NICs, while applications B and C
communicate through a VALE switch (packet buffers are notshown).

NIC rings to send and receive Ethernet frames. Applications
are in charge of performing packet processing (e.g. playing
with TCP/IP headers) in user-space, bypassing the in-kernel
network stack.
When applications start using a NIC through the netmap
API (figure 1), the NIC is said to switch to netmap mode: theNIC datapath is intercepted by netmap and cannot be useddirectly by the network stack. When no more applications areusing the NIC through the netmap API, the NIC is said toswitch back to normal mode.
C. Netmap passthroughnetmap has been widely extended to support virtualization.
We have built a fast netmap-based software switch (VALE[12]), supporting communication and isolation between ports
at rates of up to 20 Mpps; netmap pipes for point topoint communication at over 100 Mpps; netmap adapters
for paravirtualized devices; and support in hypervisors suchas QEMU and bhyve, to allow netmap applications to run
in a VM at up to 5 Mpps.
The large speed gap between netmap applications running
directly on host netmap ports (e.g. VALE, pipes), and applications running in the guest is due the differences in packet
format between the netmap ports and the devices (either
emulated or paravirtualized) made available to the VMs. These
differences require format conversions, and especially data
copies, that at the speeds of interest introduce significant
slowdowns.
To overcome these limitations, netmap passthrough [5](ptnetmap) has been introduced as a technique to completely
avoid hypervisor device emulation in the packet datapath,unblocking the full potential of netmap also for VM environments.
With ptnetmap, a netmap port on the host – a VALE port,
an hardware NIC, etc. – is exposed to the guest in a protected
way, so that netmap applications running in the guest candirectly access the rings and packet buffers of the host port,avoiding all the extra overhead involved in the emulation of
network devices.
The passthrough is transparent to guest netmap applications: they don’t need modifications to run on ptnetmap ports.
System calls issued on a ptnetmap port (txsync/rxsync)
don’t operate directly on the corresponding host port. Instead,these requests are forwarded to a pool of kernel threads
running in the host – one per ring in the current architecture.
To forward requests, ptnetmap guest driver exchanges information with the host kernel threads, so that they cansynchronize guest rings’ state (as seen by the guest netmap
application) with the rings’ state of the host port. To all intents
and purposes, guest driver and kernel threads form a producerconsumer system – one per ring.
Similarly to VirtIO paravirtualization (section II-A):• A shared memory data structure called Communication
Status Block (CSB) is used to exchange ring state andnotification suppression flags.
• I/O registers and MSI-X interrupts are used to let guest
and host netmap wake up each other on CSB updates.
• Notifications are suppressed when not needed, i.e. while
the producer or the consumer is actively polling the CSB
to check for more work. From an high-level perspective,
the system tries to dynamically switch between polling
operation under high load, and interrupt-based operation
under lower loads, which is the same idea introduced by
Linux NAPI [16].
III. PTNET
The original ptnetmap implementation uses a slightly modified version of e1000 or virtio-net guest drivers and hypervisor
device emulators, where only the notification part of thosedevices is used, while the datapath (e.g. e1000 rings or virtionet VQs) is completely bypassed. This approach requires
minimal modifications to the drivers and hypervisors, but also
prevents the use of such devices as regular network interfaces
for legacy applications running on the guest. This limitation
is inconvenient and would prevent adoption by upstream
communities (FreeBSD, Linux, QEMU, bhyve, etc.).
The key contribution of this paper is the design of a newparavirtualized device model, ptnet, which tries to be both efficient and compatible with the legacy network stack. In order topreserve the efficiency of ptnetmap even in legacy mode, ptnet
uses the netmap API as the native communication format withthe hypervisor, thus replacing Virtqueues or specific device
models.
A ptnet device uses the netmap rings of the passedthrough host netmap port, and therefore it directly exposes
the netmap API as an hardware model. This is the key ideathat allows ptnet to reach or beat the performance of state of
the art solutions, because additional queueing (e.g. VQs) andconversions (between VirtIO descriptors and sk_buff) arecompletely avoided.
A guest application can use a ptnet interface through either
the netmap API or the traditional socket API, as shown infigure 2. If a passed-through host netmap port has multiple

socketapplication

netmapapplication

guest network
stack

guest netmap

ptnet device
model
...

ptnet driver

CSB

guest

hypervisor

HW TX ring #1
HW RX ring #1

RX kthread #1

netmap-enabled
NIC driver

TX kthread #1

nm TX ring #1
nm RX ring #1

host netmap

Figure 2: The ptnet driver used by a VM to passthrough an
hardware interface of the host. Both guest netmap applications and the ptnet driver (when used by the network stack)access the mapped netmap rings.

TX/RX queues, the corresponding ptnet interface will have thesame configuration.
The introduction of a new device model does not limit the
adoption of this solution, since ptnet drivers are distributed together with netmap, and hypervisor modifications are neededin any case to map netmap host memory in the guest.
A CSB – cleaned up and extended to support an arbitrary
number of rings – is used for producer-consumer synchronization and notification suppression, as explained in section II-C.
When used by guest network stack, the ptnet device driveracts as any other guest netmap application, accessing thenetmap rings and buffers. Note that the passed-through hostnetmap port is always open in netmap mode, while theguest ptnet interface is not in netmap mode when used by
the network stack.
We have developed a version of ptnet driver for Linuxand the associated device model emulation for QEMU. The
ptnetmap support for the host (i.e. the kernel threads) has
been modified to support multiple rings and the new CSB,
but otherwise still works and performs as described in [5].
A. The ptnet device model
ptnet uses the netmap API as the underlying device
model, replacing hardware-oriented models (such as e1000)
or Virtqueues. The ptnet CSB is laid out as an array ofstructures, one per ring. Each structure contains the following
information:head/cur pointers, reflecting the status of the ring as seenby the guest. These are written by the guest and read by
the host.
• hwcur/hwtail pointers, reflecting the status of the ring as
seen by the host. These are written by the host and readby the guest.
••Two flags to suppress guest-to-host and host-to-guest
notifications, respectively.

A small number of device registers are used to read configuration (number of rings and descriptors per ring, device MAC
address, acknowledged features), or to write configuration(CSB physical address, wanted features). A command register
is available to start or stop kernel threads. A full descriptionof the register layout is not reported here for space reasons.
For each ring, a dedicated kick register is used for guestto-host notifications. Using different registers is important for
performance since each register is associated to a different
kernel thread. Using a single register would cause unnecessary
wake-ups.
A similar approach is used for host-to-guest notifications: a
different MSI-X interrupt vector is allocated for each ring, sothat different guest applications listening on different rings do
not suffer from spurious wake-ups.
B. Paravirtualized offloadings
Hardware NICs commonly support TCP/IP offloadings, themost useful ones being TCP Segementation Offloading (TSO)
and TCP checksumming offloading. When used together, thenetwork stack can pass to the NIC driver a TCP segment muchbigger than the interface MTU, usually 64KB long, with the
TCP checksum not computed. The driver will then program
the NIC to perform TCP segementation and checksum computation in hardware.
Performance improvements are twofold: (i) segementationand checksum processing is done faster in the hardware andthe CPU can be used for other purposes; (ii) the network stackis traversed less times, since packets are bigger, and so fixed
overheads are amortized over more bytes.
When coming to I/O paravirtualization, offloadings canbe exploited rather than being emulated. When the device
emulator receives a large unchecksummed TCP segment, nosegmentation or checksum computation is performed. Instead,the packet is directly pushed into the host network stack(or into a VALE switch), where it pops up again as a big
unchecksummed TCP segment.
If the packet is directed to a paravirtualized network deviceof another guest on the same host, similarly, it is received
by the guest driver and injected into the guest stack as is,without further processing. Checksum is unnecessary because
the journey of the packet from one guest to another only goes
through memory copies.
From an high level perspective, this strategy allows TCP
segmentation and checksumming to be performed lazily, andonly if necessary - i.e. when the packet needs to go on aphysical link.
VirtIO network devices use this technique, which is the key
to achieve huge throughputs in terms of TCP (or UDP) bulk
transmission. Skipping checksum computation also improves
latency.
In order to implement paravirtualized offloadings, however,guest and hypervisor needs to exchange some metadata foreach packet, including: (i) checksum offset and length to possibly perform checksum; (ii) Maximum Segment Size (MSS)
to possibly perform segmentation. The VirtIO standard [14]defines an header to contain such information, to be prepended
to each Ethernet frame.
The ptnet device supports paravirtualized offloadings using
this standard header, which is already supported by the VALE
switch and QEMU. This opens the doors for high performance
TCP/IP networking and ensures full interoperability between
ptnet and virtio-net devices.
C. Comparison with VirtIO networking
As VirtIO is the most successful and commonly deployedsolution for network I/O virtualization, we use it as a reference
to compare with our solution, taking into account features,
flexibility, performance and code reuse. Performance comparison is reported in section IV.
The two solutions are equivalent in terms of features andflexibility when used to build an intra-host virtual LAN
between VMs, also considering that they both use virtionet headers. On most hypervisors (QEMU/bhyve/Xen), VirtIO
uses standard in-kernel bridge and TAP interfaces to connect
VMs together (VirtualBox uses an equivalent custom bridge
implementation). With ptnet, the VALE switch is used toprovide inter-VM connectivity.
When a guest wants eclusive access to an host physicalinterface, with ptnet we can directly passthrough that interface,which can then be used without the need of a software switch.
VirtIO does not support this kind of passthrough and exclusive access: the interface can be attached to an in-kernel
bridge, and the guest can connect to the same bridge using a
TAP interface.
Differently from PCI passthrough techniques [4], ptnet
does not require hardware support and consistent hypervisor
modification to passthrough an host physical interface: thenetmap software is reused to provide most aspects of thisfeature.
VirtIO networking has recently been extended (onLinux/QEMU) to support multi-queue, which required modifications to the hypervisor and the TAP driver (in addition to
the extension of the virtio-net guest driver). These modification, however, are not currently available on other platforms(FreeBSD, bhyve, Windows, etc.). With ptnet, instead, there
is no need to modify hypervisor or backend drivers: netmap
already supports multi-queue ports from its inception, and theptnet guest driver is able to use all the queues exposed by the
pass-through interface. Multi-queue support, as a consequence,
comes for free together with netmap.
Mixing together the concepts of device passthrough andparavirtualization, ptnet is an hybrid solution that allows formore flexibility than VirtIO with small hypervisor modifications (~1000 code locs for QEMU).
IV. E XPERIMENTAL E VALUATION
We now complete the comparison started in section III-C
with performance measurements in terms of throughput andlatency. Our tests machine has an Intel Core i7-3770K CPU
at 3.50GHz (4 core / 8 threads), 8GB RAM DDR3 at 1.33GHz,
We run Linux 4.4.5 with a recent QEMU (git master 888ea9,Feb 2016) as hypervisor, extended with ptnetmap support.
Each guest VM has 1 vCPU and runs Linux 4.4.5.
For VirtIO tests, we always enable the vhost-net [3] optimization, which accelerates VirtIO networking by performing
device emulation directly within the kernel.

Thousand R/R transactions per second

A. TCP/IP tests

1 In the netmap architecture, buffers are provided by netmap, not by applications, and so an additional copy is needed between OS packet representation(i.e. sk_buffs for Linux) and netmap buffers. We are currently investigating
the use of netmap indirect buffers to avoid these copies.

40
35
30
25
20
15
10

0

10000

20000 30000 40000 50000
Length of Request/Response message

60000

70000

Figure 3: Guest-to-guest latency tests, with ptnet performing
better than VirtIO because no device emulation is involved,
even with the (four) additional packet copies per transaction.

Guest-to-guest UDP throughput tests

60000
50000
40000
Mbps

For TCP/IP tests, we use the popular netperf tool, run
between two VMs connected through a software switch: a
VALE switch for ptnet, and an in-kernel Linux bridge forvhost-net. These tests document the latency and throughput
of communications going through standard sockets and theregular network stack. Each single experiment lasts 10 seconds
and is repeated 10 times. Unless stated differently the worst
standard deviation is under 2%, so we only report the averages.
Latency tests: These experiments measure the Request/Response transaction rates at different message sizes,
for both UDP and TCP, which give a measure of the roundtrip time. The results, presented in Figure 3, show that ptnet
performs better than vhost-net at smaller message sizes, while
the two mechanisms are equivalent for very large messages.
ptnet gains over vhost-net because the passthrough mechanism
does not require device emulation. On the other hand, ptnet
requires one copy for each transmitted/received packet1 (sofour more copies than vhost-net for each transaction), and thisreduces the gap at larger message sizes.
Streaming tests: With these experiments we measure thethroughput of the communication path, which is expected to
grow with the message size as the size-independent cost of
system calls and protocol processing is amortized more. For
the TCP_STREAM tests we focused on the common caseof large messages, with the transmitter sending maximum
sized TSO packets (64 KiB each). In this configuration ptnet
achieves about 20 Gbps, while vhost-net is able to reach
26 Gbps. The performance gap is due to the additional packet
copies made by ptnet, that increase the CPU load, eat memory
bandwidth and also increase the latency in the communication.
Results for UDP_STREAM are shown in Fig. 4. We only
report the transmit throughput because at high rates the lackof flow control causes the receiver to enter a livelock regime,
where 50-80% of the received UDP packets are dropped at thereceive socket buffer, before netperf can read them.
Throughput for both VirtIO and ptnet stops growing beyond
20-30 KiB, when the size-independent cost stops dominating
the cost of copies. In spite of the additional copies, however,ptnet performs better at all sizes. The drop for messages
larger than 30 KiB coincides with an increase in the standard
deviation of the results (about 15%), and is related to the speed
mismatch between sender and receiver as discussed in [11].

Guest-to-guest TCP/UDP latency tests
ptnet-TCP_RR
ptnet-UDP_RR
vhost-TCP_RR
vhost-UDP_RR

45

30000
20000
10000
0

ptnet-UDP_STREAM
vhost-UDP_STREAM
0

10000

20000

30000 40000
Message length

50000

60000

70000

Figure 4: Guest-to-guest UDP throughput measured at thetransmitter. Despite doing more copies, ptnet transmits faster.

In particular, we are in a “Fast Consumer” regime, describedin section IV-B.
B. Linux in-kernel pktgen tests
Recent improvements in the Linux kernel [1], [2] try toleverage on batching to improve throughput, without artificially introducing latency. Since [1], the kernel can give the
NIC driver a batch of packets ready for transmission, so thatthe driver can notify the whole batch to the NIC, if possible.
To measure the effectiveness of this approach, which canbe used with traditional socket applications, we run the Linuxin-kernel packet generator in a guest, sending batches ofminimum-sized packets (60 bytes) at maximum speed througha ptnet (over VALE) or virtio-net device (over TAP), with10

the current state of the art - VirtIO networking. We haveseen that ptnet and VirtIO performance are comparable withtraditional socket applications, whereas ptnet also supports
guest applications which are able to benefit from the Netmap
API.
Finally, we explained how ptnet can be easy ported toother platforms with similar performance, since most of its
implementation is already shipped within netmap. We are
currently developing a ptnet driver for FreeBSD and a device
emulation model for the bhyve hypervisor. This is particularlyinteresting for the FreeBSD project, since it does not currently
have an high performance network I/O virtualization solution
such as vhost-net.

Linux in-kernel pktgen tests
ptnet-over-VALE
vhost-over-TAP

Mpps

8
6
4
2
10 0

10 1

Burst size

10 2

10 3

Figure 5: Transmission tests using Linux pktgen with variablebatch size. VirtIO is not able to exploit the batching, whileptnet makes good use of netmap batching API.

variable burst size, and measuring the packets received on thehost. Results are shown in figure 5.
The VirtIO API has limited support for batching, andtherefore using batch transmission with virtio-net is not reallyeffective at improving throughput - only guest-to-host notifications are delayed.
On the contrary, ptnet does a good job when driven withbatches, since the batches are preserved when going throughthe passed-through netmap port. The throughput nicely increases with the batch sizes, reaching its optimium at about
50. After that, throughput decreases. As explained in [11],the decrease happens because for larger batches the producerconsumer systems enters a Fast Consumer (FC) regime. The
consumer (ptnetmap TX kernel thread) becomes more efficientw.r.t. the producer (pktgen guest thread), and so the producer
slows down because it spends more time notifying the consumer.
C. Tests with netmap applications
In the same scenario of section IV-A, we used the Netmap
pkt-gen tool over ptnet to measure guest-to-guest throughput
at minimum packet size (60 bytes). We measured ~19.5 Mpps
when using virtio-net headers and ~21 Mpps when not using
them. Note that disabling virtio-net headers is a reasonablechoice for VMs implementing middlebox functionalities (e.g.
NFV nodes), since virtio-net headers are mostly useful if the
VM is the endpoint of TCP or UDP streams.
Other tests with ptnet on different network configurations(e.g. with hardware ports, pipes, etc.) are not reported here forspace reasons, but the performance numbers are the same asreported in [5].
V. C ONCLUSION
This work presents ptnet, an approach to network I/Ovirtualization built on top of netmap, comparing it with

ACKNOWLEDGMENT
This paper has received funding from the European Union’s
Horizon 2020 research and innovation programme 2014-2018
under grant agreement No. 644866. This paper reflects only
the authors’ views and the European Commission is not
responsible for any use that may be made of the information
it contains.
R EFERENCES[1] Bulk network packet transmission. https://lwn.net/Articles/615238/.
[2] Qdisc bulk dequeueing. https://lwn.net/Articles/615240/.
[3] Vhost architecture.
http://blog.vmsplice.net/2011/09/qemu-internalsvhost-architecture.html.
[4] B.-Y. et al. Utilizing iommus for virtualization in linux and xen. In
Proceedings of the Linux Symposium, 2006.
[5] S. Garzarella, G. Lettieri, and L. Rizzo. Virtual device passthrough forhigh speed vm networking. In Proceedings of ACM/IEEE ANCS 2015,
pages 99–110, 2015.
[6] S. Han, K. Jang, A. Panda, S. Palkar, D. Han, and S. Ratnasamy. Softnic:
A software nic to augment hardware. Technical report, 2015.
[7] M. Honda, F. Huici, G. Lettieri, and L. Rizzo. mswitch: A highlyscalable, modular software switch. In Proceedings of the 1st ACM
SIGCOMM Symposium on Software Defined Networking Research.
ACM, 2015.
[8] J. Hwang, K. K. Ramakrishnan, and T. Wood. Netvm: High performanceand flexible networking using virtualization on commodity platforms. In
11th USENIX Symposium on Networked Systems Design and Implementation (NSDI 14), pages 445–458, 2014.
[9] Intel.
Intel
data
plane
developmentkit.
http://edc.intel.com/Link.aspx?id=5378, 2012.
[10] L. Rizzo. netmap: A Novel Framework for Fast Packet I/O. In USENIX
ATC’12, Boston, MA. USENIX Association, 2012.
[11] L. Rizzo, S. Garzarella, G. Lettieri, and V. Maffione. A Study of Speed
Mismatches Between Communicating Virtual Machines. IEEE/ACM
ANCS, 2016.
[12] L. Rizzo and G. Lettieri. VALE, a Switched Ethernet for Virtual
Machines. ACM CoNEXT, 2012.
[13] L. Rizzo, G. Lettieri, and V. Maffione. Speeding up packet I/O in
virtual machines. In Proceedings of the Ninth ACM/IEEE Symposium
on Architectures for Networking and Communications Systems, ANCS
’13, pages 47–58, Piscataway, NJ, USA, 2013. IEEE Press.
[14] R. Russel, M. Tsirkin, and C. Huck.
http://docs.oasisopen.org/virtio/virtio/v1.0/virtio-v1.0.html.
[15] R. Russell. virtio: towards a de-facto standard for virtual I/O devices.
ACM SIGOPS Operating Systems Review, 42(5):95–103, 2008.
[16] J. H. Salim, R. Olsson, and A. Kuznetsov. Beyond softnet. In
Proceedings of the 5th annual Linux Showcase & Conference, volume 5,
pages 18–18, 2001.