PLAN DE MANTENIMIENTO

While designing the internal packet exchange mechanisms between the fvSwitch and the PEX, we had to consider two opposite requirements: performance, which suggests to use a single buffer shared among all the components in order to exploit a zero-copy algorithm, and isolation, which requires each PEX to have its own dedicated buffer in order to guarantee that a VNF can only have access to packets that belong to its tile. The resulting mechanism is a mixture of those requirements: each PEX has its own buffer shared with the fvSwitch, hence a packet traversing

N PEX has to be copied by the fvSwitch N times. However, each packet is copied

only once in each buffer, for both the up and down trips. In fact, even if this communication channel can be modeled with two FIFO queues, one bringing packets from the fvSwitch to the PEX and the other for the opposite direction, we exploit an

algorithm (extensively detailed in Chapter5) that moves a packet from the fvSwitch

to the PEX, and then back to the fvSwitch without any copy of the packet within the PEX itself.

As shown in Figure1.6, each PEX shares two circular buffers with the fvSwitch:

the primary buffer is used by the fvSwitch to send packets to the PEX and to receive them back once their processing has been completed, while the secondary buffer is used only for the traffic that is generated by VNFs, as the primary buffer does not accept insertions of new packets from the PEX.

The algorithm that manages the primary buffer, shown in Figure 1.7, uses four

indexes, which are respectively a pointer to the last packet written by the fvSwitch in the buffer (fvSwitch.write()), a pointer to the last data that has actually been read (and processed) by the PEX (PEX.read()), the oldest packet that has been processed by all the VNFs in the PEX (PEX.write()) and hence is ready to be

1.5 – Implementation fvSwitch.write() PEX.read() PEX.write() fvSwitch.read() Packet Metadata Eth IP Packet slot

Packet to be processed by the PEX

Packet processed by the PEX and to be sent to the fvSwitch Packet ready to be processed by the fvSwitch

PEX 1 _{Shared primary} PEX 2 buffer

Virtual switch

Figure 1.7: Packet exchange between the fvSwitch and PEX.

delivered to the next PEX in the chain, and finally the next packet that will be drained by the fvSwitch (fvSwitch.read()) and sent to the next PEX. Note that this buffer is lock-free, hence very efficient; moreover, in the implementation we took care not to access too often to the shared indexes (we use shadow copies instead) in order to minimize the cache synchronization cost among processes running in different CPU cores.

In addition, the primary buffer is operated through a batching mechanism; in fact, the fvSwitch writes several packets before signaling the PEX over a shared

semaphore, waking it up7_{. This allows the PEX to be scheduled (hence starting}

its processing) only when a reasonable amount of packets is present in the buffer, hence limiting the number of context switches in the system and exploiting at best memory locality as in the fvSwitch. Obviously, a timeout has been implemented as well in order to avoid packets starving in the buffer in case the PEX receives limited amount of traffic over time. The PEX will suspend itself only when no packets waiting to be processed are present in the buffer. To facilitate batch processing in the fvSwitch, the PEX.write() pointer is updated only when the amount of packets processed in the PEX exceeds a threshold, or when there are no more packets to be processed.

The primary buffer is well suited for packets that enter in the PEX, traverse all the local VNFs, and return back to the fvSwitch. However, it may happen that: (i) a packet is dropped by a VNF, and then it cannot continue its journey; (ii) a VNF modifies a packet so that it exceeds the MTU, hence requiring to be split in multiple fragments; (iii) a VNF generates new packets.

The first point is addressed by setting a special flag in the packet metadata

(Section1.5.4) that informs the fvSwitch to drop that packet as soon as it is received

7_{The fvSwitch is aware of the status of the PEX, i.e., running or waiting for packets, thanks to}

1 – A scalable and massively multi-tenant platform for user-oriented network services

back in the buffer. Instead, points (ii) and (iii) require the secondary buffer, which is used by the PEX to send its own generated packets to the fvSwitch. This buffer is a traditional (circular) FIFO queue: a special flag in the packet metadata of the primary buffer informs the fvSwitch that, after that packet, the following N packets have to be read from the secondary buffer, before returning to drain the traffic from the primary buffer.

Currently, both buffers have slots with a fixed length, whose size is equal to

the maximum packet size of the network8. Moreover, they are allocated in memory

using huge pages, in order to reduce the pressure over the Translation Lookaside Buffer (TLB).