1

An accurate and efficient modeling frameworkfor the performance evaluation of

DPDK-based virtual switchesThomas Begin∗, Bruno Baynat†, Guillaume Artero Gallardo‡ and Vincent Jardin§

∗Univ Lyon, Universite Claude Bernard Lyon 1, ENS de Lyon, Inria, CNRS, LIP, France†Sorbonne Universites, UPMC Univ Paris 06, CNRS, LIP6, France

‡ Sysoco Group, Research and Development, France§ 6WIND, Research and Development, France

Abstract—DPDK works as a specialized library that enablesvirtual switches to accelerate the processing of incoming packetsby, among other things, balancing the incoming flow of packetsover all the CPU cores and processing packets by batches to makea better use of the CPU cache. Although DPDK has become ade facto standard, the performance modeling of a DPDK-basedvSwitch remains a challenging problem.

In this paper, we present an analytical queueing model toevaluate the performance of a DPDK-based vSwitch. Such avirtual equipment is represented by a complex polling systemin which packets are processed by batches, i.e., a given CPUcore processes several packets of one of its attached input queuesbefore switching to the next one. To reduce the complexity of theassociated model, we develop a general framework that consists indecoupling the polling system into several queueing subsystems,each one corresponding to a given CPU core. We resort to serverswith vacation to capture the interactions between subsystems.Our proposed solution is conceptually simple, easy to implementand computationally efficient.

Tens of comparisons against a discrete-event simulator showthat our models typically deliver accurate estimates of theperformance parameters of interest (e.g., attained throughput,packet latency or loss rate). We illustrate how our modelscan help in determining an adequate setting of the vSwitchparameters using several real-life case studies.

Index Terms—NFV; virtual switch; DPDK; modeling; perfor-mance evaluation; polling system; batch.

I. INTRODUCTION

Server virtualization has become ubiquitous in the modernIT environment. Decoupling virtual servers from physicalservers helps to leverage the computing resources, and bringsimportant gains in scalability and agility. More recently, thevirtualization of networks has attracted much attention. Scala-bility, agility, and multi-tenancy (with the concept of networkslicing) are the envisioned improvements that virtualizationwill bring to traditional computer networks.

This trend towards more flexible networks, often known as“softwarization”, is driven by two main paradigms: Software-Defined Networking (SDN) and Network Function Virtualiza-tion (NFV). The former aims at removing all the decision-making networking functions from network nodes and re-grouping them into a (set of) controller(s). Thus, networknodes, such as routers, switches, load-balancers, firewalls, etc.are replaced by appliances receiving their instructions directly

from the controller(s) (using a standard interface like Open-Flow [1]). On the other hand, NFV refers to the gradual moveof network functions from dedicated hardware to commodityhardware running specialized software. For example, functionssuch as routing, switching, load-balancing, firewalling, etc.will be run as software on standard x86 servers, and are thusreferred to as Virtualized Network Functions (VNFs). Notethat VNFs may be executed directly by the hypervisor orwithin a Virtual Machine (VM) (or a container). In any case, toallow communications between the VMs (of a same physicalserver) and the rest of the physical network, the hypervisor cancreate a virtual switch (aka vSwitch) that logically connectsthe VMs to the outside world.

While software-based solutions are generally viewed asmore flexible than their hardware counterparts, the networksoftwarization raises concerns about its expected performance.To address this issue, a consortium including companies likeIntel and 6WIND has devised Data Plane Development Kit(DPDK) [2]. DPDK is an open-source project and works as aspecialized library for x86, ARM and PowerPC processors. Inparticular, it enables vSwitches to accelerate the processingof incoming packets by (i) balancing the incoming flowof packets over all the vSwitch CPU cores, (ii) avoidingunnecessary re-copy of the packets, (iii) keeping all operationsout of the OS kernel and, instead, within the user space and(iv) processing packets by batches, thereby having a betteruse of the CPU cache. While other libraries exist, DPDK hasbecome a de facto standard for vSwitches. Nonetheless, due tothe relative novelty and complexity of virtual switches, theirperformance modeling (e.g., to analytically derive estimates ofthroughput, loss rate, latency) remains a challenging problem.We believe that an analytical model can provide some helpfulguidelines by suggesting adequate values for the large numberof parameters that can be adjusted in a virtual switch.

In this paper, we investigate the performance of a virtualswitch, i.e., a software relaying packets (possibly after mod-ifying their content) between the ports of VMs or containershosted on a same physical machine and the rest of the physicalnetwork. We assume that the vSwitch is equipped with DPDK.We propose a conceptually simple and easy-to-implementmodeling approach for evaluating customary performance pa-rameters of a vSwitch such as its mean throughput, its mean

2

latency, its loss rate as well as the level of utilization of itsCPU cores. We consider several examples inspired by realscenarios and we assess our model accuracy by comparingits predictions with the actual values delivered by a discrete-event simulator. To illustrate the application of our model,we explore the effects of changing a vSwitch configuration(e.g., batch sizes) as well as adjusting the vSwitch resources(number of allocated CPU cores) to satisfy a given ServiceLevel Agreement (SLA) policy (e.g., zero-loss).

The remainder of this paper is organized as follows. Sec-tion II describes the internal behavior of a DPDK-basedvSwitch as well as the real-world inspired scenarios that mo-tivate our study. In Section III, we present the main principlesunderlying our modeling framework for a vSwitch. Section IVdetails our approach in the case where a vSwitch processesincoming packets individually while Section V handles thecase of packets being served by batches. We study the accu-racy of our models in Section VI and we provide potentialapplications of theirs in Section VII. We discuss the relatedwork in Section VIII. Section IX concludes this paper.

II. DESCRIPTION OF A VSWITCH

A. Context and definition

Like traditional switches, a vSwitch commutes packetsbetween its ports but, unlike them, it operates as a softwaretypically run by the hypervisor of the physical server. Ingeneral, a vSwitch has access to a set of logical CPU coresand to a set of physical and logical ports. Logical portsconnect to ports of VMs hosted on the same physical machinewhile physical ports are associated with existing ports onthe physical server. An example is given in Figure 1. Forexample, in a cloud computing context, a physical server mayhost several VMs that are interconnected using a vSwitch,which itself is executed by the hypervisor. In an SDN/NFV-based network, vSwitches (software running on commodityhardware) are replacing specialized hardware devices such asswitches, firewalls, load-balancers, routers, and other middle-boxes. In addition to commuting packets between their ports,vSwitches may also perform other operations like filtering,header editing, content encrypting and deep packet inspection.In fact, vSwitches may use all the headers from layer 2 upto layer 5 (and not just 2 as it is commonly the case for atraditional switch) so that they are also referred to as virtualmulti-layer switches. Note that the physical machine runningthe vSwitch typically hosts VMs or containers so that thevSwitch has to share the physical resources with them.

The two prominent solutions to create a vSwitch in ahypervisor are OVS [3] and FD.io VPP [4]. Note that bothare open-source projects and that VPP is the open-sourceversion of Cisco’s Vector Packet Processing. Aside from open-source implementations, a couple of proprietary virtual switchsolutions have been released; e.g., by Cisco (Nexus 1000V)and VMware (vSphere Distributed Switch).

A vSwitch mainly comprises three types of components: (i)network interface cards (NICs) that altogether provide a totalof N input/output (I/O) ports, (ii) a set of (logical) CPU coresthat are in charge of processing the packets coming from the

Host machine

1

VM 2 Server2

VM 3 vSwitch

VM 1 Server1

Logical ports

Physical ports

VM Virtual Machine

VM-vSwitch.pdf

VM 2 VM 3VM 1Logical Ports

Physical PortsPhysical M

achinevSwitch

{

Rest of the Network

Inspiré par slide 3 de https://

www.slideshare.net/teyenliu/the-basic-

introduction-of-open-vswitch

Fig. 1: vSwitch connecting three VMs with two physical ports.

different I/O ports, and (iii) memory to store packets waitingfor their processing, be it from the CPU cores or from theNICs. As a side note, note that packets are moved across thesecomponents through PCI buses.

B. DPDK library

To let vSwitches deal with high rates of packets, differ-ent techniques, e.g., Netmap [5], OpenOnload [6], Packet-Shader [7] and DPDK [2], have been developed to provide afaster packet processing. DPDK is an open-source project andworks as a specialized library for x86, ARM and PowerPCprocessors. It is developed by a consortium comprising com-panies like Intel and 6WIND. Note that DPDK is integratedto the most prominent vSwitch solutions, namely OVS andVPP, making it a de facto standard for vSwitches. Hence,we focus our study on a vSwitch equipped with the DPDKlibrary [2]. DPDK makes use of several means for acceleratingthe processing of packets.

1) No packets recopy: DPDK avoids the recopy of packets.Thanks to the use of a shared memory, CPU cores are ableto process packets without recopying them in their associatememory. For a deeper understanding of these mechanisms, thereader can refer to the work of Scholz [8].

2) Operations performed in the user space: Another meansof DPDK for accelerating the packet processing is to run theassociated operations in the user space and not within thekernel as is done by default. By doing so, DPDK avoids theoverhead of CPU interrupts that result in additional delays inprocessing packets.

3) Balancing the load across all the CPU cores: AlthoughDPDK allows various configurations in the polling of theseveral vSwitch ports by the multiple CPU cores, we considerhere its standard configuration, using the so-called “Poll ModeDriver”, which is known as the most versatile and efficient(unless in specific scenarios). First, one CPU core, aka the“master” core, is entirely dedicated to the control and man-agement of the vSwitch while the other CPU cores are devotedto the packet processing. Let C denote the number of CPUcores devoted to the packet processing, i.e., not including themaster core. Second, DPDK aims at uniformly distributingthe load originating from each port across the C CPU cores.Said differently, each CPU core contributes to processingpackets coming from each port. More precisely, modern NICsperform load balancing by letting each of their ports dispatchincoming packets into C separate logical queues, called RXqueues. This dispatching step is typically carried out throughthe application of a hash function on the packet headers (such

3

as the Receive Side Scaling (RSS) used in DPDK) and aimsat ensuring an even balance of the incoming packets amongthe RX queues as well as at accelerating packet processingby directing packets belonging to the same flow to the sameRX queue. As a result, each RX queue is assigned to a singleCPU core while each CPU core handles as many RX queuesas the total number of ports in the vSwitch. We denote byK the RX queue size, i.e., the maximum number of packetsthat can be queued simultaneously in it. Then, once a CPUcore ends up processing a packet, the packet is (logically)forwarded from its RX queue to a TX queue associated to theappropriate output port. At this stage, the packet is pendingfor transmission on the next link and does not need anyfurther CPU core processing resource. Figure 2 illustrates thismapping between CPU cores, ports and RX queues.

RX queues TX queuesCPU cores

1

2

port 1

port 2

port N

port 1

port 2

port N

Fig. 2: Internal architecture of a vSwitch with N I/O portsand C CPU cores.

4) Processing packets by batches: CPU cores poll theirassociated RX queues in a cyclic order (i.e., in a round-robinfashion). However, for the sake of performance, DPDK enablesCPU cores to serve a batch of packets on the same RX queuebefore switching to the next RX queue. We denote by TSthe mean switch-over time taken by a core to switch from itscurrent RX queue to the next one, and by M the maximumsize of the batch. When the batch size is set to M , a CPUcore can prefetch up to M packets on one RX queue andthen it processes them in a run-to-completion manner. Notethat packets that enter the RX queue while the CPU core hasalready started its service are not served in this round, and theyhave to wait until the core revisits this queue. In the queueingtheory literature, this discipline is known as a gated M -limitedpolicy [9].

Batching packets by groups of M packets tends to increasethe overall efficiency of a vSwitch. Indeed, when a CPU corehandles packets belonging to the same batch, chances are thatthe needed instructions are found in the CPU cache, whichlowers the average processing time of a packet. We denoteby TH and TM the average time needed by a CPU core to

process a packet when the set of instructions is found (cacheHit), respectively not found (cache Miss), in the cache. Notethat TH is typically significantly smaller than TM , say aroundan order of magnitude or so. Let TR indicate the average timeneeded by the CPU core to forward a packet from an RX queueto a TX queue over a PCI bus (once the CPU core processinghas ended). As a result, the total time needed by a core toserve a given packet is either TM + TR (in case of a cachemiss) or TH + TR (in case of a cache hit). In general, theformer case is more likely to occur if the considered packetis among the first packets of a batch (the cache is likely tobe “cold”) whereas the latter has more chances to happenfor the subsequent packets of a batch as they will benefitfrom the cache information. In addition, processing packets bybatches also increases efficiency by reducing the total numberof switch-over times (as a CPU core does not switch to adifferent RX queue upon the completion of a single packetprocessing).

Despite the enhancements brought by DPDK, vSwitches aresubject to performance issues, in particular if the incomingload is too large. Given the transmission speed of lines andthe current transfer rates of PCI buses and memory (SDRAM),the bottleneck of a vSwitch, if any, is likely to occur during theprocessing of packets in RX queues due to the limited CPUresources. Therefore, we concentrate our modeling efforts onthe interactions between the CPU cores, the RX queues andthe ports.

Note that, despite the “Poll Mode Driver” of DPDK whereina master core is made available for the management taskswhile the others are entirely devoted to the packet processing(see Section II-B3), a vSwitch may be affected by a momen-tary external load applied to the hypervisor or to co-hostedVMs. One way to take into account this effect is to scale upthe average times to process a packet, TH and TM .

C. Scenarios

Throughout the paper, we consider three scenarios inspiredby features of real vSwitches to demonstrate the accuracy andthe abilities of our modeling approach. For the sake of sim-plicity and without loss of generality, we assume throughoutthis paper that the considered vSwitches comprise CPU coresrunning each at 3GHz, that RX queues are set to store up toK = 128 packets, that the mean packet size is 1000 bytes,and that the switch-over times TS are equal to 1ns. We alsoassume that the dispatching function performed on incomingpackets at the ports is well-behaved (see Section II-B3) so thatevery CPU core undergoes the same performance allowing usto restrict our analysis to only one of them. Note that this lastassumption does not mean that ports are equally loaded. Notealso that all the numerical values used to specify our threescenarios are derived from real-life experiments conducted in6WIND lab.

1) Scenario 1 - Simple forwarding: In our first scenario, weconsider a case where a vSwitch is simply forwarding incom-ing packets between its ports based on their link layer headersand does not provide any further services. Said differently,the vSwitch behaves similarly to a regular switch. We assume

4

that the vSwitch operates on a small-scale network so that itsflow table is relatively small. More precisely, we assume thatthere is a total of N = 4 ports and that 80 CPU cycles areenough for processing packets (i.e., looking up entries in theflow table) while 10 additional CPU cycles (resp. 200) areneeded to access the information if the vSwitch experiencesa cache hit (resp. cache miss). Overall, given the speed ofthe CPU cores (3GHz), we have: TH = (80 + 10)/3 = 30nsand TM = (80 + 200)/3 = 93.3ns. We also assume that thebatch size M is set to 4 packets and that PCI buses sustain16 GBps so that TR = 1000/16 = 62.5ns. Finally, we assumethat ports are unevenly loaded as follows: Port 1 receives 15%of the whole traffic, Port 2 receives 20%, Port 3 receives 25%and Port 4 receives 40%.

2) Scenario 2 - Complex routing: Our second scenariopertains to a vSwitch whose flow table is large featuringnumerous rules to handle different types of traffic with variousdestinations. Such a situation can occur for routers locatedin the core (backbone) network of a network operator. Here,we assume that, because of the size of the flow table, 800CPU cycles are needed for the lookup operation while 10additional CPU cycles (resp. 200) are needed to access theinformation if the vSwitch experiences a cache hit (resp. cachemiss). Therefore, we obtain: TH = (800+10)/3 = 270ns andTM = (800 + 200)/3 ' 333ns. We choose a larger size ofpacket batch with M = 8 and we assume that PCI buses workat 32 GBps so that TR = 31.25ns. Finally, we assume a totalof N = 5 ports that are irregularly loaded as follows: Port 1receives 10% of the whole traffic, Port 2 receives 15%, Port 3receives 20%, Port 4 receives 25% and Port 5 receives 30%.

3) Scenario 3 - IPsec: In our last scenario, we considera vSwitch applying IPsec encryption operations on incomingpackets. Network architects typically deploy IPsec tunnels toprovide security for data communication between pairs ofdistant nodes. The packets are encrypted at the ingress of thetunnel and decrypted at its egress using computationally inten-sive encryption algorithms implemented in IPsec. We assumethat 8,000 CPU cycles are spent to perform the encryptionprocess and that 10 additional CPU cycles (resp. 200) areneeded to access the information if the vSwitch experiencesa cache hit (resp. cache miss). Given the speed of CPU cores(3GHz), this leads to TH = (8000 + 10)/3 = 2670ns andTM = (8000 + 200)/3 = 2733.3ns. The size of batches is setto M = 16 packets. The speed of PCI bus is fixed to 8 GBpsso that TR = 125ns. The total number of ports is set to N = 8ports that are unevenly loaded as follows: Port 1 receives 5%of the whole traffic, Port 2 receives 10%, Port 3 receives 15%,Port 4 receives 18%, Port 5 receives 22% and Port 6 receives30%.

III. GENERAL MODELING FRAMEWORK

A. System notation

We start this section by reminding the notation introducedso far. As stated in Section II, C denotes the total number ofCPU cores devoted to the packet processing and N representsthe number of ports attached to the vSwitch. As a results, thetotal number of RX queues of the vSwitch is equal to N ×C.

TABLE I: Principal notation.

Symbol DescriptionC Number of CPU cores devoted to the packet processingN Number of portsK Capacity of the RX queuesM Size of packet batchesTH Average time needed by a CPU core to process a packet

in case of a hit in the cacheTM Average time needed by a CPU core to process a packet

in case of a miss in the cacheTR Average time needed by a CPU core to forward a packet

to a TX queueTS Average time needed by a CPU core to switch to the

next RX queueβ Switch-over rateΛi Packet arrival rate on port i, i = 1, . . . , N

λji Packet arrival rate dispatched to the j-th RX queue of

port i, j = 1, . . . , C and i = 1, . . . , N

Λj Packet rate bound to the j-th CPU core, regardless oftheir incoming port (j = 1, . . . , C)

µji Service rate of the j-th CPU core when it is serving

the i-th RX queue, j = 1, . . . , C and i = 1, . . . , N

U j Utilization rate of the j-th CPU core, j = 1, . . . , C

Bi Blocking probability at port i, i = 1, . . . , N

bi Loss rate at the entrance of queue i, i = 1, . . . , N

qi Average number of packets in queue i, i = 1, . . . , N

ri Average sojourn time in queue i, i = 1, . . . , N

Each RX queue has a finite capacity expressed as a maximumof K packets. Each CPU core cyclically polls its associatedRX queues and processes at most M packets from each RXqueue before switching to the next one. M is referred to asthe batch size. Let us also recall that the average time neededby a CPU core to process a packet is denoted by TH in caseof a hit in the cache, and by TM in case of a miss. We use TRto refer to the average time needed by a CPU core to forwarda packet to a TX queue while we use TS to denote the averagetime taken by a CPU core to switch from its current RX queueto the next one.

We use Λi to denote the packet arrival rate on port i (i =1, . . . , N) while λji refers to the rate of packets dispatchedto the j-th RX queue of port i, and hence handled by the j-th core (j = 1, . . . , C). It follows that Λi =

∑Cj=1 λ

ji and,

assuming the hash function dispatches equally across the RXqueues, we have: λji = Λi

C . Finally, we denote by Λj the totalrate of packets bound to the j-th core CPU core, regardless oftheir incoming port (j = 1, . . . , C) so that Λj =

∑Ni=1 λ

ji .

For the sake of our modeling framework we let µji denotethe service rate of the j-th core when it is serving the i-thRX queue, while β denotes the switch-over rate. Note that bydefinition, we have, β = 1/TS . We detail later how µji can bederived from TH , TM and TR.

Table I summarizes the principal notation used in this paper.

B. Performance parametersThe objective of this paper is to develop an accurate

and scalable modeling framework to derive performance pa-rameters of the vSwitch. These metrics may pertain to the

5

Fig. 3: Illustration of a subsystem involving a single CPU corethat polls N RX queues with a size of batch of M = 2. Bluepackets are being processed while red packets are waiting fortheir turn.

RX queues or to the whole system itself. As for the i-thRX queue (i = 1, . . . , N ) attached to the j-th CPU core(j = 1, . . . , C), performance parameters of interest includethe blocking probability (i.e., the loss rate) denoted by bji , themean sojourn time of a packet denoted by rji , as well as thebuffer occupancy denoted by qji . Besides, for each CPU corej, we use U j to indicate its utilization rate. Finally, the globalperformance of a vSwitch often derive from the former innerparameters. Thus, the global CPU core utilization rate, denotedby U , can simply be expressed as:

U =

∑Cj=1 U

j

C(1)

Similarly, the packet blocking probability at port i, referred toas Bi, can be computed as:

Bi =

∑Cj=1 b

jiλji∑C

j=1 λji

=

∑Cj=1 b

jiλji

Λi(2)

Note that the global CPU utilization and blocking proba-bility are performance parameters that capture and summarizethe overall level of congestion in a vSwitch, and thereforerepresent metrics of direct interest for network operators.

C. Decomposition principle

The first step of the modeling framework is to break downthe general switch architecture into C independent subsystems,each of them consisting of one CPU core that polls Nindependent RX queues. Recall that, as stated at the end ofSection II-B, we focus on the interactions between the CPUcores, the RX queues and the ports, and as a result we excludefrom the model the transmission part of packets in TX queues.Every subsystem is identified with a distinct color in Figure 2and is simply referred to as a polling system. In the rest of thepaper we only consider the model associated with a given CPUcore j and its N related RX queues. Therefore, for the sake ofclarity, we drop superscript j in all subsequent notations andequations. Figure 3 represents the polling system associatedwith the considered CPU core having a service rate µi whenserving its i-th RX queue, and a switch-over rate β.

The second step of the general modeling framework consistsin replacing each polling system with a set of N decoupledqueues with server vacations. This decomposition step isillustrated in Figure 4. The buffer of queue i in the decomposed

Fig. 4: Decomposition of a subsystem into N separate queueswith a size of batch of M = 2. Blue vacations are active whilethe red vacation is inactive.

model represents the i-th RX queue associated with theconsidered CPU core. The server of the i-th queue in thedecomposed model aims at reproducing the way packets ofthe i-th RX queue are processed by the CPU core. Becausethe core polls all its RX queues in-between the processingof two successive batches of (at most M ) packets at a givenqueue i, there is an in-between time that corresponds to theprocessing of one batch of packets for all the other non-emptyqueues and N switch-over times. In the model, this total timewill be referred to as a vacation time. As an illustration, inFigure 4, the server of queue i is in process, meaning thatthe CPU core is currently processing a packet of the currentbatch in RX queue i, and all other queues are in vacation. Inthis particular example, when queue i ends its processing, itgoes in vacation, the remaining packets of queue i are put ona hold, and, at the same time, the switch-over time betweenRX queue i and RX queue i + 1 starts. It is only after thecompletion of this switch-over time that queue i+ 1 ends itsvacation and starts the processing of its first M in-line packets

D. Modeling assumptions

In order to derive tractable models, we make in the wholepaper the following Markovian assumptions. First, we assumethat the arrival of packets at the entrance of queue i followsa Poisson process of rate λi. Then, we assume that theprocessing time of one packet from queue i is exponentiallydistributed with rate µi. We also assume that the switchingtime is exponentially distributed with rate β. Finally, asdeveloped in the following sections, the subsequent modelswill represent the vacation times by a succession of differentphases with exponential distributions.

IV. MODELS WITH NO BATCH SERVICES

To start our analysis, we do not take into account theprocessing of packets by batches and we restrict our studyto the case of M = 1, i.e., a CPU core processes only onepacket of its associated (non empty) RX queues at each round.We relax this assumption in the next section.

6

P

S

P

S

P

S

β

β

β

μi

μi+1

μi+2

μi-1

…

Fig. 5: Representing the vacation times in Sohail model [10].

With a batch size of M = 1, CPU cores are very unlikelyto process consecutive packets belonging to the same flow,thereby essentially precluding any benefit from the cache. Asa result the mean processing time of the considered CPUcore when serving a packet from its i-th RX queue can beconsidered as a constant given by:

1

µi= TM + TR. (3)

The switch-over rate β is simply defined, as stated in previoussection, as the inverse of the mean switch-over time:

β =1

TS. (4)

A. Sohail model

The model developed by Sohail in [10] falls into thescope of our general modeling framework. In their paper, thevacation time is developed as a sequence of switch-overs andpossible processing times. As illustrated in Figure 5 in thecase of queue i, its vacation time always comprises a firstswitch-over stage (first green “S” labeled circle) between RXqueue i and RX queue i+ 1, and when this first switch-overstage ends, two things can happen: (i) if RX queue i + 1is not empty, the vacation time of queue i goes through theprocessing of a packet of RX queue i+1 (first blue “P” labeledcircle), after which it continues with the second switch-overtime between RX queue i + 1 and RX queue i + 2; (ii) ifRX queue i + 1 is empty, the vacation time of queue i goesdirectly to the second switch-over time. The same happens forall other RX queues so that the modeling of the vacation timebecomes a complex phase-type distribution. As a result, themodel associated with a given queue i is a pretty complicatedMarkov chain having 2N(K + 1) states, that must be solvedusing a numerical technique [10]. Note that the parameters ofthe i-th Markov chain depend on the performance extractedfrom all other Markov chains, and thus an overall fixed-pointiterative technique must be used to solve the model.

B. Proposed model

1) Vacation representation: Unlike Sohail model [10], inwhich the vacation time is represented as a sequence of switch-over and processing times, we keep in the vacation time thefirst switch-over time and aggregate all the remaining phases.

V

S β

μi

αi

Fig. 6: Representing the vacation times in our model.

As shown in [11], by doing this we drastically reduce thecomplexity of the model without significantly deteriorating itsaccuracy. This idea is illustrated in Figure 6. Following theprocessing stage of the server, the vacation starts by a switch-over time between RX queue i and RX queue i + 1. Theremaining of the vacation time is then aggregated into a singleexponential phase with a given rate αi (i.e., with a given meanduration 1/αi), that has to be accurately estimated.

2) Markov chain model associated with each RX queue:Under the markovian assumptions given in Section III-D, wecan associate with each queue i of the decomposed model,the continuous-time Markov chain depicted in Figure 7. Thechosen state description has two dimensions and thus is madeof two parts (k,CPU state). The left-hand side correspondsto the current number of packets in the queue, k = 1, . . . ,K,while the right-hand side specifies if the CPU core is currentlyprocessing this queue (P), switching from this queue to thenext one (S), or otherwise processing another RX queue orswitching between the other RX queues (V).

In order to solve this chain corresponding to a particularqueue i, only one parameter remains to be estimated, namelyαi (the other parameters λi, µi, β, and K are supposedto be known either from knowledge on the system or frommeasurements). However, assuming that αi is known, we showin Appendix A how to quickly and easily obtain the stationaryprobabilities of this Markov chain without resorting to anynumerical technique.

3) Estimation of the chain parameters: Instead of consid-ering αi, we estimate 1/αi, corresponding to the mean timebetween the end of switching from i-th to (i+1)-th RX queue(marking the time when the core is leaving queue i) and theend of switching from (i − 1)-th to i-th RX queue (markingthe time when the core is returning to queue i). Therefore,this time includes N − 1 switch-over times, but also includesthe processing of one packet for all non-empty RX queue jdifferent from i. It follows that:

1

αi= (N − 1)× 1

β+∑j 6=i

(1− Ej)×1

µj. (5)

In this expression, Ej represents the probability that RX queuej is empty when the core is returning to it, i.e., at the particularinstant when the switch-over time from (j − 1)-th to j-thRX queue ends. This parameters can be extracted from theMarkov chain associated with RX queue j (equivalent to theone represented in Figure 7 but where i is replaced by j).Indeed, Ej can be expressed as the ratio between the numberof transitions from state (0, V ) to state (0, S) by unit of time,and the total number of transitions from red states by unit oftime, each of them correspondonding to the end of a vacation

7

1,P 2,P 3,P

0,S 1,S 2,S

0,V 1,V 2,V

K-1,P K,P

K-1,S

K-1,V

K,S

K,V

λi

λi

λi

λi

λi

λi

λi

λi

λi

μi μi μi μi

αi αi αi αiαi ββ β β β

...

...Fig. 7: Continuous-Time Markov Chain associated with queue i.

for RX queue j. Therefore, we have:

Ej =πj(0, V )αj∑Kk=0 πj(k, V )αj

=πj(0, V )∑Kk=0 πj(k, V )

, (6)

where the πj are the stationary probabilities of the j-th Markovchain.

4) Fixed-point solution: As expected, the parameters of aMarkov chain associated with a given queue i depend onthe stationary solution of the other Markov chains (throughEq. 5 and 6). As a result, the resolution of the model relieson a fixed-point iterative technique that is summarized byAlgorithm 1. The main loop of the algorithm is repeated untila given convergence criterion is reached, e.g., the maximumrelative difference of varying parameters between two succes-sive iterations is very small (say less that 10−7).

Algorithm 1: Fixed-point iterative techniqueInput : System parameters K, µi, λi, β for each queue iOutput : Stationary probabilities πi and performance metrics

for each queue iInitialize πi, Ei for each queue i;while convergence criterion not satisfied do

foreach queue i ∈ [[1, N ]] doCompute αi using Eq. 5;Solve the Markov chain associated with queue i and

compute the stationary probabilities πi;Compute Ei using Eq. 6;

endendCompute all performance metrics of interest from Eq. 7 to 9;

5) Performance parameters: After convergence of our algo-rithm, we can derive the system performance parameters fromthe stationary probabilities of the Markov chains as follows.The average number of packets in queue i is given by:

qi =

K∑k=1

k × (πi(k, P ) + πi(k, S) + πi(k, V )). (7)

We can compute the loss rate at the entrance of queue i as:

bi = πi(K,P ) + πi(K,S) + πi(K,V ). (8)

The average sojourn time of an accepted packet in queue i isthen obtained using Little’s law:

ri =qi

λi(1− bi). (9)

V. MODEL TAKING INTO ACCOUNT BATCH SERVICES

We now turn to the more general case where packetsare processed in batches by the CPU cores. As discussedin Section II-B, the use of batches accelerates the packetprocessing by reducing the number of CPU cores switch-over times, and more importantly, by making a better use ofthe CPU caches. Our rationale is to make use of the modelpresented in Section IV while carefully adjusting some of itsparameters to account for the presence of batches.

A. Rethinking µi and β in the context of batch processing

In order to understand the influence of the cache on themean processing times, let us take an example of a vSwitchhaving N = 4 ports and processing packets by batch of sizeM = 16. Let us consider that the CPU core at a particularround has to process a batch of 16 packets from RX queue 1that is made of 4 packets destined to port 2, 7 packets destinedto port 3, and 5 packets destined to port 4. We can reasonablyassume that for the first packet destined to a given port, theinformation necessary for its processing (typically containedin the forwarding table) has to be fetched from the RAM,whereas for the subsequent packets destined to the same port,the information is present in the cache. If we make thisassumption, the total time necessary to process all packetsof the considered batch is thus 3TM + 13TH + 16TR, and theaverage processing time by packet is 3TM+13TH+16TR

16 .By generalizing this result, we first proposed in [12] to

estimate the average processing time by the following simpleequation:

1

µi=

{N−1M TM + M−(N−1)

M TH + TR if M ≥ N − 1

TM + TR if M < N − 1(10)

This estimation is realistic when M >> N and when thesystem is heavily loaded. Indeed in this case there is a highchance that the CPU core processes full batches, i.e., batchesmade of M packets, and that in each batch there is at leastone packet destined to each of the possible N − 1 outputports. In this case, the processing time of the whole batch is(N − 1)TM + (M − (N − 1))TH + MTR and the formulabecomes exact.

Finally, when considering a vSwitch with non negligiblevalues of the switch-over time TS , the value of β has tobe adapted since the model does not structurally take batchservices into account. The easiest way is to reduce the mean

8

switch-over time by a factor M , leading to replace Eq. 4by [12]:

β =M

TS. (11)

B. Refining the calculation of µiWhen M is small or when the load is low, Eq. 10 is not

accurate anymore. Let us first see how we can improve theestimation of the mean processing time in the case where Mcan take any value (small or large). We first assume that abatch is always made of M packets (which will obviously bethe case when the load is high). We propose to replace Eq. 10by:

1

µi=P (M,N − 1)

MTM +

M − P (M,N − 1)

MTH+TR (12)

where P (M,N − 1) is the average number of ports amongthe N − 1 possible output ports that receive packets from thecurrent batch (supposed of M packets):

P (M,N − 1) =

min(N−1,M)∑k=1

kPk(M,N − 1) (13)

with Pk(M,N − 1) being the probability that a batch of Mpackets is sent over exactly k ports among the N −1 possibleoutput ports, k = 1, ...,min(N − 1,M).

If packets are assumed to be equally dispatched to all outgo-ing ports, Pk(M,N−1) can be obtained through enumerationas:

Pk(M,N − 1) =Dk(M,N − 1)

(N − 1)M(14)

where Dk(m,n) is the number of ways to put m objects(the packets) in exactly k boxes (the output ports) among npossibles boxes. Theses quantities can be obtained from thefollowing recursive formula:D1(m,n) = n k = 1

Dk(m,n) = Cknkm −

k−1∑i=1

Dk−i(m,n)Cin−(k−i) k = 2, ..., n

(15)Let us now see how we can improve the value of the mean

processing time 1µi

in the case of a low load, i.e., when a batchis not anymore of M packets. If we first assume that we knowthe average size mi of a batch on input port i. We propose toreplace Eq. 12 by:

1

µi= αTM + (1− α)TH + TR (16)

where

α =

P (mi,N−1)mi

if mi is integer

(dmie − mi)P (bmic,N−1)

bmic

+(mi − bmic) P (dmie,N−1)dmie if mi is not integer

and mi > 1

miP (1, N − 1) if mi is not integerand 0 < mi < 1

(17)

Now we have to face the problem of estimating the averagesize mi of a batch.

This quantity can be easily obtained from the Markov chainas follows:

mi =

M−1∑k=1

k × πevi (k) +M ×K∑

k=M

πevi (k) (18)

where πevi (k) is the probability that queue i contains k packetsat the instants of end of vacation of the queue (“ev”), i.e., whenthe precise size of a batch is decided. These probabilities canbe derived from the stationary probabilities of the i-th Markovchain as:

πevi (k) =πi(k, V )αi∑Kj=0 πi(j, V )αi

=πi(k, V )∑Kj=0 πi(j, V )

(19)

VI. ACCURACY OF THE PROPOSED APPROACH

To study the accuracy of our modeling approach, we explorethe three scenarios described in Section II-C. We comparethe results of our model to those of a home-made discrete-event simulator written in Java, whose code is made available[13]. Unlike our model, the simulator precisely implements thebehavior of a vSwitch as described in Section II: i) Packetsqueued on an RX queue are processed by batches; ii) Thetime to process a packet is closely related to the presence orabsence of the corresponding instructions in the cache, andnot only averaged as this is the case in the model; iii) Afterprocessing a batch of packets on a given RX queue, the CPUcore is assigned to the next RX queue. As such, the simulatordoes not proceed, as the model does, with a decomposition ofthe vSwitch architecture into decoupled queueing subsystemswith vacation. We provide a validation of our simulator againstreal-life measurements in Appendix B.

We run seven independent replications of 50,000,000 pack-ets completions each. The obtained estimated confidence in-tervals at 95 percent confidence level are so small that weuse only the mid-point in our validation. In each scenario, weconsider a wide range of values for the packet arrival rate,varying from a very low level of load up to a high levelcorresponding to a full saturation of the vSwitch.

Numerical results for Scenario 1, in which we consider thecase of a simple forwarding with N = 4 ports and batchesof M = 4 packets, are presented in Figure 8. Refer toSection II-C for a complete list of the parameters. Figure 8arepresents the average queue size (number of packets beingbuffered in RX queues) as a function of the load. We firstnotice that possible values of the average queue size varyfrom 0 for a low level of load up to 128 (corresponding tothe capacity K of RX queues) when the load is high. Asexpected, we observe that the most loaded port, namely port 4(receiving 40% of the total load), is the first to saturate whenthe load increases. For example, at a level of load of 8 Mpp, thequeue associated with port 4 is almost full (i.e., close to 128packets) while the queues associated with the three other portsare almost empty. Note also that the curves are significantlysteep denoting a high sensibility to the actual level of load. InFigure 8b, we consider the loss rate (i.e., blocking probability)experienced by each port as a function of the load. We note

9

4 6 8 10 12 14 16 18 20

Load (Mpps)

0

20

40

60

80

100

120

140A

vera

geQ

ueu

eS

ize

Port 1

Port 2

Port 3

Port 4

Model

Simu

(a) Average queue size.

4 6 8 10 12 14 16 18 20

Load (Mpps)

0.0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

Los

sR

ate

Port 1

Port 2

Port 3

Port 4

Model

Simu

(b) Loss rate.

4 6 8 10 12 14 16 18 20

Load (Mpps)

0

10

20

30

40

50

60

70

Ave

rage

So

jou

rnT

ime

(µs)

Port 1

Port 2

Port 3

Port 4

Model

Simu

(c) Average sojourn time.

Fig. 8: Accuracy of our approach on Scenario 1 - Simple forwarding.

that the most loaded port is again the first to undergo lossesas soon as the load exceeds 7 Mpps. Finally, we study theevolution of the average sojourn time spent by a packet in anRX queue in Figure 8c. At heavy levels of load, the valuefound for each port converges to a common asymptotic value(corresponding to the average time necessary to process 128packets of a given RX queue). Overall, Figure 8 shows theclose agreement between the proposed model and simulation.

Scenario 2 deals with the case of a vSwitch whose flow tableis much larger and complex. Let us recall that, in this scenario,the number of ports is set to N = 5 while the size of batchesequals M = 8 packets. Figure 9 presents the associated results.Figure 9c shows that, in the case of the average sojourn time,the asymptotic value for large levels of load differs from thatfound on Figure 8c. This gap results from the fact the meantime to process a packet is significantly larger in our secondscenario. Here too, the performance parameters returned byour model closely match those delivered by the simulator.

Finally, Scenario 3, which addresses the case of a vSwtichperforming IPsec functions and featuring N = 6 ports with asize of batches set to M = 16 packets, is handled in Figure 10.We again observe that the performance obtained from ourmodel are close to those delivered from the simulator at anylevel of load.

VII. EXAMPLES OF APPLICATION

A. Influence of switch-over time

We begin by studying the impact of the switch-over timeon the average size of RX queues. We use parameters closeto those of Scenario 2 and let TS vary so that it ranges froma very low overhead (i.e., representing 0.1% of the averagepacket processing time), all the way to a massive overhead(i.e., 100%). Then, based on our model, we compute theaverage number of packets buffered in the RX queue of themost loaded port for different levels of load. The associatedresults are reported in Figure 11. First, we notice that therelationship between TS and the average queue size is farfrom being linear. Indeed, the deviation between an overheadof 100% and 50% is approximately twice smaller than thatbetween 50% and 0.1%. Second, starting from a switch-overtime representing approximately 2% of the packet processingtime, all curves for subsequent smaller values tend to coincide.

From a practical point of view, this suggests that, wheneverthe switch-over time represents an overhead less than, say 1%or 2%, they can be neglected in the performance analysis ofa vSwitch.

We continue this study by examining simultaneously theinfluence of the switch-over time and of the load, on theloss rate of an RX queue. Figure 12 shows the correspondingresults with a varying switch-over time on the X-axis and avarying load on the Y-axis. As shown by the figure, when theload is low (under 0.5-0.6 Mpps), the value of the switch-over time overhead has virtually no influence on the loss ratethat remains totally negligible, whereas when the load is high(close to 1 Mpps), the switch-over time overhead has a largeimpact on the loss rate.

B. Influence of batch size

In our second example, we investigate the influence of thesize of packet batches M on the performance of a vSwitch.We begin our study by considering Scenario 1. We let Mvary from a value of 1, in which at most one packet of eachRX queue is processed before the CPU core moves to thenext RX queue, up to a value of 32. We restrict our analysison the loss rate experienced by the most loaded port, namelyport 4. Figure 13 shows the corresponding results. We observethat there is a substantial gain in increasing the size of packetbatches as the onset of packet losses is postponed from a loadof 6.5 Mpps for M = 1 to a load of almost 10 Mpps forM = 32, which represents an improvement of more than 50%.In the same way, while a load of 9 Mpps results into a severecongestion for a vSwitch parameterized with M = 1 (witha loss probability approaching 0.55), setting M to 32 leadsto virtually no packets being lost. It is worth noting that themarginal gain of incrementing the size of batches decreasesquite rapidly with growing values of M .

To develop a better understanding of the effect of M onthe behavior of a vSwitch, we switch to Scenario 2 and were-run our experiment. Let us recall that in this scenario thetime for processing a packet varies much less between a cachehit and a cache miss. We represent the obtained results inFigure 14. As is shown, the size of the packet batches doesnot affect much the values obtained for the loss rates. Indeed,the gain obtained by increasing M from 1 to 32 barely reaches

10

2 4 6 8 10 12

Load (Mpps)

0

20

40

60

80

100

120

140A

vera

geQ

ueu

eS

ize

Port 1

Port 2

Port 3

Port 4

Port 5

Model

Simu

(a) Average queue size.

2 4 6 8 10 12

Load (Mpps)

0.0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

Los

sR

ate

Port 1

Port 2

Port 3

Port 4

Port 5

Model

Simu

(b) Loss rate.

2 4 6 8 10 12

Load (Mpps)

0

50

100

150

200

250

Ave

rage

So

jou

rnT

ime

(µs)

Port 1

Port 2

Port 3

Port 4

Port 5

Model

Simu

(c) Average sojourn time.

Fig. 9: Accuracy of our approach on Scenario 2 - Complex routing.

0.0 0.5 1.0 1.5 2.0

Load (Mpps)

0

20

40

60

80

100

120

140

Ave

rage

Qu

eue

Siz

e

Port 1

Port 2

Port 3

Port 4

Port 5

Port 6

Model

Simu

(a) Average queue size.

0.0 0.5 1.0 1.5 2.0

Load (Mpps)

0.0

0.2

0.4

0.6

0.8

1.0L

oss

Rat

ePort 1

Port 2

Port 3

Port 4

Port 5

Port 6

Model

Simu

(b) Loss rate.

0.0 0.5 1.0 1.5 2.0

Load (Mpps)

0

500

1000

1500

2000

2500

Ave

rage

So

jou

rnT

ime

(µs)

Port 1

Port 2

Port 3

Port 4

Port 5

Port 6

Model

Simu

(c) Average sojourn time.

Fig. 10: Accuracy of our approach on Scenario 3 - IPsec.

Load

Fig. 11: Influence of the switch-over time on the average sizeof an RX queue for Scenario 2.

10%. This is in stark contrast with Scenario 1. This differencestems from the nature of the load. Indeed, unlike Scenario 1,here incoming packets belonging to the same batch are quiteunlikely to access the same information in the CPU cache, andhence there is little benefit in batching their services.

Based on these two examples, it appears that increasingthe size of packet batches may significantly improve theperformance of a vSwitch. However, the magnitude of thegain may vary widely depending on the characteristics of the

20 40 60 80 100Switch-over Time (% of packet processing time)

0.5

0.6

0.7

0.8

0.9

1.0

Loa

d(M

pp

s)

0.00

0.06

0.12

0.18

0.24

0.30

0.36

0.42

0.48

Fig. 12: Influence of the switch-over time and of the load onthe loss rate experienced at an RX queue for Scenario 2.

packet processing times. Significant gains are expected whenthe average time needed to process a packet in case of a cachehit is significantly less than in the case of a cache miss.

C. Ensuring zero-loss policy

To illustrate the potential application of our model, weconsider the problem of determining the proper number ofCPU cores to meet a given QoS criterion. Operators often aimto size their networking devices so that packets exchanged over

11

4 6 8 10 12 14 16 18 20

Load (Mpps)

0.0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8L

oss

Rat

e

M=1

M=2

M=4

M=8

M=16

M=32

Fig. 13: Influence of the size of batches on the loss rateexperienced at an RX queue for Scenario 1.

2 4 6 8 10 12

Load (Mpps)

0.0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

Los

sR

ate

M=1

M=2

M=4

M=8

M=16

M=32

Fig. 14: Influence of the size of batches on the loss rateexperienced at an RX queue for Scenario 2.

these devices are (almost) never dropped. We now describehow our model can help achieve this so-called “zero-loss”policy on a vSwitch.

We consider a vSwitch parameterized closely to that de-scribed in Scenario 3 but with M = 1. However, we let thenumber of allocated CPU cores, C, unspecified as it variesfrom 1 to 20. Then, for increasing values of the load submittedto the vSwitch, we compute the total loss rate experienced overall RX queues. Figure 15 shows the corresponding results. Weobserve that for a load of 8 Mpps, a minimum of C = 10 coresis required to ensure the zero-loss policy. This number growsto C = 17 cores if the load gets to 14 Mpps.

Dimensioning curves, analogous to those depicted in Fig-ure 15, are easily and quickly delivered by our model. Webelieve that the knowledge conveyed by these curves canprovide useful information in order to avoid the under- orover-provisioning of networking devices.

Load

Fig. 15: Ensuring zero-loss policy by adequately determiningthe number of allocated CPU cores.

VIII. RELATED WORK

Many works have concentrated their efforts on evaluatingthe performance of DPDK-based vSwitch, either by conduct-ing measurements or by using modeling techniques. In thefollowing, we first present the approach adopted by DPDK’scontributors to address this topic from an experimental point ofview. We then review modeling attempts of vSwitch systemsand, because polling is a key feature of DPDK systems,we study the related work of polling models. Finally, weconclude this section by reviewing our previous works on theperformance evaluation of DPDK-based vSwitch.

A. Experimental approach

With the objective of achieving the best software switchingperformance, engineers contributing to the DPDK librarydeveloped internal performance measurement tools similar tomonitoring probes. This approach has the advantage of givinga localized and precise analysis of low-level performance ofa DPDK system, thus allowing developers to benchmark andvalidate any novel implementation or algorithmic optimization.

Nonetheless, the fact of reading and updating values inthe system, typically when handling a counter, blocks theCPU cores for a while and so, reduces the overall systemperformance. About this, Vyatta/Brocade principal softwarearchitect stated during the 2015 Dublin DPDK Userspaceforum that the act of “observing performance slows it down”[14] To overcome this issue the performances of DPDKbased switching solutions are mainly assessed experimentallyusing dedicated test software such as the TestPMD applicationprovided by Intel [15]. Such applications are for instance usedby Intel to publish bi-annual DPDK performance reports [16].Several works also attempted to experimentally characterizethe open vSwitch performance. Most of them conductedmeasurements on an experimental testbed to demonstrate theenhancement provided by DPDK [17]. They also measuredthe impact of the number of NIC, the offered load, and thepacket size [18]. Other works investigated the impact of active

12

flow monitoring [19], that might simply consist in samplingpackets being forwarded across the vSwitch. Again, increasingthe sampling rate to gain accuracy keeps consuming CPUresources, and in turn degrades the overall performance.

B. Modeling approach

By being non-intrusive in nature, modeling approaches canbe used to overcome these measurement constraints and helpin the performance evaluation of a DPDK system.

1) Non-DPDK-specific vSwitch modeling: Modeling theperformance of vSwitch systems has been addressed for non-DPDK-specific systems. For instance, a model for estimatingthe packet loss probability and the average sojourn timeof OpenFlow architectures is provided in [20]. This modelassumes that all the packets arrive at the same queue beforebeing forwarded to the switch. Suksomboon et al. presentedan optimal configuration selection algorithm for Linux-basedsoftware routers relying on an Erlang-k-based packet latencyprediction model [21]. Such prediction model uses measure-ments performed on two different router configurations toaccurately predict the performance of all the configurations.It considers the case of systems with only a single CPU core.

These works cannot capture the effect of more sophisticatedprocessing strategies such as polling used in the DPDK PollMode Driver or packet batch processing, that both highlycontributes to a vSwitch performance enhancement [22].

2) Polling system modeling: As polling is a key featureof DPDK systems, we review the works done in modelingits performance. Strategies of polling have been extensivelyused in computer networks and telecommunication systems.For instance, the IEEE 802.5 Token Ring introduced inthe early 1980s, used this scheme in its medium accessmethod. Nonetheless, the analysis of polling systems startedeven before in the late 1950s with the patrolling repairmanmodel for the British cotton industry. Reference surveys onpolling models were published in the early 1990s by Takagito provide a classification of polling systems and relatedresearch advances [23], [24]. These studies underscore thatthe performance of a polling system depends, in general, onmany factors including the number and the capacity of queues,the arrival and service rates, as well as the switch-over time.Polling systems can be classified according to service policies,that might be exhaustive or gated, and unlimited or M-limited.Exhaustive: Once the server polls a given queue, it serves thequeue until its complete exhaustion, and then it switches tothe next queue. This implies that any request arriving in aqueue while the server is currently processing another requestof the same queue will be served before the server moves tothe next queue. Gated: Unlike the exhaustive policy, the serverdoes not process (in the current round) requests that may enterthe queue while the server is already serving this same queue.Additionally, for both aforementioned policies, one can set anupper limit on the number of requests that the server can pro-cess for the same queue before switching to the next one. M-Limited: On each turn, the server can serve at most M requestsfor each queue. This corresponds to the case studied in thispaper. Unfortunately, the general solution to polling systems

is not known. However, their analysis is no less important,and therefore, several approximations have been developed.Tran-Gia proposed an analytical framework for computing theperformance of a gated 1-limited polling system with non-zero switch-over time [25]. The modeling approach consists ofsolving a fixed-point problem to evaluate the state probabilitiesof an embedded Markov chain. In particular, the analysis ofeach involved queue is carried out at polling instants, i.e., endsof vacation. It requires the computation of Laplace-Stieltjestransforms as well as the use of Laplace inversion proceduresor two-moment approximation techniques. As stated by theauthors, such model is accurate only for large switch-overtimes and small values of the queue capacities (less than10 requests). The fixed-point approach developed by Tran-Gia has then been extended to the case of exhaustive M-limited systems in [26]. In this work, the authors leveragethe techniques provided by Lee to study M/G/1/K queueswith server vacation [27], [28]. It consists in decomposingthe polling system in individual M/G/1/K queues with servervacation. Each queue is then studied at polling instants. Toreduce the number of modeling assumptions introduced in theprevious works, a more general framework is presented in [29].When conducting the analysis of each queue, it eliminates thehypothesis that the busy period, i.e., the time the server isnot on vacation and that the vacation times are independent.This approach relies on solving a system of several numericalequations. However, as stated by the author, the complexityof the involved expressions may require using a symboliccomputation software.

In conclusion, most of these approaches address a differentpolicy than that implemented in vSwitches, and/or they involvecomplex arithmetic operations that may not scale with thenumber of queues or with their capacity. Although they ac-curately solve specific polling modeling problems, they seemto be of little help when evaluating the performance of generalDPDK-based vSwitch systems.

3) Our previous contributions on DPDK-based vSwitch: Ina 2016 paper, Artero et al. [30] described an analytical modelfor vSwitches based on the decomposition of the switch intoseveral polling systems, each one being in turn decomposedinto simple Markov chain models. Presented as a first steptowards a more general model, this work did not take intoaccount batch services and assumed a negligible switch-overtime. Su et al. developed an extension of this work [11] thatkept the simplicity and the accuracy of the initial model whiletaking into account switch-over times. Including batch serviceswas all the more challenging as it structurally changes thenature of the models and drastically increases their complexity.A first attempt has been made in [12]. By simply adjustingthe average processing times to reflect the cache effects, Suet al. have developed an extension of their previous worksthat provides an accurate approximation in the specific caseof a heavily loaded system with large values of the batch size.The main challenge of developing a more general modelingframework including all the key features of DPDK-basedvSwitches while adapting to a widest range of scenarios,remains an open issue and is the purpose of the present paper.

13

IX. CONCLUSIONS

In this paper, we present an analytical queueing model toevaluate the performance of a DPDK-based virtual switchwith several CPU cores and network interface cards. Pollingsystems, in which a set of servers sequentially poll packetsfrom a set of queues, with batch services, in which severalpackets are processed simultaneously, arises as an appropriaterepresentation for modeling the behavior of a vSwitch. To cir-cumvent the combinatorial growth of the state space associatedwith these models and their inherent complexity, we decouplethe polling system associated with each CPU into severalqueues and we resort to servers with vacation to capturethe interactions between queues. Our proposed solution isconceptually simple, easy to implement and computationallyefficient.

We conduct tens of examples to assess the accuracy ofour proposed model for various performance parameters suchas the attained throughput, the packet latency, the bufferoccupancy and the packet loss rate under various levels ofloads. Comparisons against a discrete-event simulator showthat our models typically deliver accurate estimates of the per-formance parameters. We illustrate how our models can helpin determining an adequate setting of the vSwitch parametersusing three real-life case studies, and derive some qualitativeconclusions. For example, we find that increasing the size ofpacket batches may significantly improve the performance of avSwitch, but only if a cache miss implies a much larger accesstime than a cache hit. Future works could aim at extending thevalidation of our model against real-life measurements.

APPENDIX

A. Efficient solution to the Markov Chain

The continuous-time Markov chain associated with a singlequeue i of the model of Section IV-B is illustrated in Figure 16with some cuts that will be useful in the resolution.

Fist, let us assume that πi(0, V ) is known. From thesteady-state equation corresponding to cut C0, we can expressπi(0, S) as a function of πi(0, V ):

πi(0, S) =(αi + λi)

βπi(0, V ).

Then, from cut C′

0, we derive πi(1, P ):

πi(1, P ) =λiµi

(πi(0, V ) + πi(0, S)).

The three cuts C1, C′

1 and C′′

1 , directly provide the threestationary probabilities πi(1, V ), πi(1, S) and πi(2, P ):

πi(1, V ) =λiαi

(πi(0, V ) + πi(0, S) + πi(1, P )),

πi(1, S) =λiβ

(πi(1, V ) + πi(0, S) + πi(1, P )),

πi(2, P ) =λiµi

(πi(1, V ) + πi(1, S) + πi(1, P )).

Similarly, we can obtain the following stationary probabilitiesfor any k = 1, ...,K − 1:

πi(k, V ) =λiαi

(πi(k − 1, V ) + πi(k − 1, S) + πi(k, P )),

πi(k, S) =λiβ

(πi(k, V ) + πi(k − 1, S) + πi(k, P )),

πi(k + 1, P ) =λiµi

(πi(k, V ) + πi(k, S) + πi(k, P )).

We use cuts CK and C′

K to express πi(K,V ) and πi(K,S):

πi(K,V ) =λiαi

(πi(K − 1, V ) + πi(K − 1, S)),

πi(K,S) =λiβπi(K − 1, S).

Finally, the last unknown probability, πi(0, V ), is obtainedusing the normalization constraint:

K∑k=0

(πi(k, V ) + πi(k, S)) +

K∑k=1

πi(k, P ) = 1.

B. Validating our simulator against real-life measurements

For a given scenario, we compare the results provided by ourdiscrete-event simulator [13] that implements the behavior ofa vSwitch as described in Section II with those collected on areal-life vSwitch implementing DPDK. The scenario is definedas follows. We consider a vSwitch with a total of N = 32 ports(equally loaded), RX queues of capacity K = 128 packets,CPU cores running at 2.3 GHz, a switch-over times TS of 1ns,packet batch of size M = 8 and an average packet processingtime of 178 CPU cycles corresponding to 77.43ns. The real-life vSwitch implements OVS with 6WINDGate and DPDKrunning on Ubuntu Linux with Intel Core i7 CPUs and Intelixgbe NICs. Packets of 64 bytes were generated using IXIA.Figure 17 represents the corresponding results for the loss rateand the average queue size for a wide range of values of load.We observe that the results delivered by our simulator are infair agreement with the experimental measurements.

ACKNOWLEDGMENTS

This work was partly funded by the French ANR REFLEX-ION under the “ANR-14-CE28-0019” project. The authorsthank Zidong Su for his help in implementing the simulatorand Amine Kherbouche for his assistance in the definition ofthe scenarios. The authors also sincerely thank the anonymousreferees for their thorough and constructive review that wereof great help to improve this paper.

REFERENCES

[1] N. McKeown, T. Anderson, H. Balakrishnan, G. M. Parulkar, L. L.Peterson, J. Rexford, S. Shenker, and J. S. Turner, “OpenFlow: enablinginnovation in campus networks,” Computer Communication Review,vol. 38, no. 2, 2008.

[2] Data Plane Development Kit (DPDK). http://dpdk.org, 2017. Intel,6WIND, etc.

[3] Open vSwitch - An Open Virtual Switch. http://www.openvswitch.org,2017.

14

Fig. 16: Continuous-Time Markov Chain associated with queue i.

10 11 12 13 14 15Load (Mpps)

0

20

40

60

80

100

120

140

Avera

ge Q

ueue S

ize

Exp.

Simu.

(a) Average queue size.

10 11 12 13 14 15Load (Mpps)

0.00

0.05

0.10

0.15

0.20

Loss

Rate

Exp.

Simu.

(b) Loss rate.

Fig. 17: Simulator results against real-life measurements.

[4] Fast data – Input/Output - Vector Packet Processing. https://wiki.fd.io/,2017.

[5] L. Rizzo, “netmap: A novel framework for fast packet I/O,” in 2012USENIX Annual Technical Conference, June 13-15, 2012, 2012.

[6] OpenOnload. http://www.openload.org, 2017. Solarflare.[7] PacketShader. http://shader.kaist.edu/packetshader/, 2011.[8] D. Scholz, “A look at intel’s dataplane development kit,” Network,

vol. 115, 2014.[9] H. Levy and M. Sidi, “Polling systems: applications, modeling, and

optimization,” IEEE Transactions on communications, vol. 38, no. 10,1990.

[10] A. Sohail, “Performance evaluation of a non-exhaustive polling systemwith asymmetrical finite queues,” in 14th International Conference onComputer Modelling and Simulation, UKSim, 2012.

[11] Z. Su, B. Baynat, and T. Begin, “A new model for dpdk-based virtualswitches,” in IEEE Conference on Network Softwarization (IEEE NetSoft2017), 2017.

[12] Z. Su, T. Begin, and B. Baynat, “Towards including batch services inmodels for dpdk-based virtual switches,” in IEEE Global InformationInfrastructure and Networking Symposium (IEEE GIIS 2017), 2017.

[13] DPDKSim - A simulator for DPDK-based Virtual Switches.https://github.com/garterog/DPDKSim, 2018.

[14] S. Hemminger, “DPDK performance, Lessons learnedin vRouter,” in DPDK Summit, Userspace 2015,https://dpdksummit.com/Archive/pdf/2015Userspace/DPDK-Userspace2015-StephenHemminger-Performance.pdf, 2015.

[15] Intel DPDK, “The TestPMD Application,” inhttp://dpdk.org/doc/guides/testpmd app ug/index.html.

[16] Intel DPDK Validation team, “DPDK Intel NIC Per-formance Report Release 18.02, March 2018,” inhttp://fast.dpdk.org/doc/perf/DPDK 18 02 Intel NIC performance report.pdf.

[17] P. Emmerich, D. Raumer, F. Wohlfart, and G. Carle, “Performancecharacteristics of virtual switching,” in 2014 IEEE 3rd InternationalConference on Cloud Networking (CloudNet), 2014.

[18] D. Zhou, B. Fan, H. Lim, M. Kaminsky, and D. G. Andersen, “Scalable,high performance ethernet forwarding with cuckooswitch,” in ACMConference on Emerging Networking Experiments and Technologies,CoNEXT ’13, ACM, 2013.

[19] V. Mann, A. Vishnoi, and S. Bidkar, “Living on the edge: Monitoringnetwork flows at the edge in cloud data centers,” in InternationalConference on Communication Systems and Networks (COMSNETS),2013.

[20] M. Jarschel, S. Oechsner, D. Schlosser, R. Pries, S. Goll, and P. Tran-Gia,“Modeling and performance evaluation of an openflow architecture,” in2011 23rd International Teletraffic Congress (ITC), 2011.

[21] K. Suksomboon, N. Matsumoto, S. Okamoto, M. Hayashi, and Y. Ji,“Erlang-k-based packet latency prediction model for optimal config-uration of software routers,” in 2017 IEEE Conference on NetworkSoftwarization (NetSoft), 2017.

[22] S. Gallenmuller, P. Emmerich, F. Wohlfart, D. Raumer, and G. Carle,“Comparison of frameworks for high-performance packet io,” inACM/IEEE Symposium on Architectures for Networking and Commu-nications Systems, ANCS ’15, IEEE Computer Society, 2015.

[23] H. Takagi, “Queuing analysis of polling models,” ACM Comput. Surv.,vol. 20, no. 1, 1988.

[24] H. Takagi, “Analysis of finite-capacity polling systems,” Advances inApplied Probability, 1991.

[25] P. Tran-Gia and T. Raith, “Performance analysis of finite capacity pollingsystems with nonexhaustive service,” Performance Evaluation, vol. 9,no. 1, 1988.

[26] M. Lang and M. Bosch, “Performance analysis of finite capacity pollingsystems with limited-m service,” 13rd International Teletraffic Congress,ITC 1991.

[27] T. T. Lee, “M/G/1/N queue with vacation time and exhaustive servicediscipline,” Operations Research, vol. 32, no. 4, 1984.

[28] T. T. Lee, “M/G/1/N queue with vacation time and limited servicediscipline,” Performance Evaluation, vol. 9, no. 3, 1989.

[29] D. Kofman, “Block probabilities, throughput and waiting time in finitecapacity polling systems,” Queueing systems, 1993.

[30] G. A. Gallardo, B. Baynat, and T. Begin, “Performance modeling of vir-tual switching systems,” in IEEE International Conference on Modeling,Analysis, and Simulation on Computer and Telecommunication Systems,MASCOTS, 2016.