#NETMAP DRIVER CHANGES DRIVERS#
#NETMAP DRIVER CHANGES SOFTWARE#

Per-packet cost depends on how the data stream is split into packets: the larger the packet, the smaller the component. The per-packet cost comes from the manipulation of descriptors (allocation and destruction, metadata management) and the execution of system calls, interrupts, and device-driver functions. The per-byte cost comes from data manipulation (copying, checksum computation, encryption) and is proportional to the amount of traffic processed. Network I/O has two main cost components. The NIC ring is statically allocated, and its slots point to the buffers that are part of the mbuf chains.

NICs use their own descriptors, much simpler than those used by the operating system, and typically arranged into a circular array, called a NIC ring (see figure 1). They can send or receive packets split into multiple memory buffers, as implemented by the operating system. The design of modern NICs is based on this data representation. For example, when transmitting a TCP packet, the protocol stack must keep a copy of the packet in case the transmission gets lost, and sharing the buffer saves the copying cost. Allowing buffers to be shared can save some data copying (hence, time and space) in many common operations on the network stack. The use of fixed-size buffers simplifies memory allocators, even though it requires chaining when data exceeds the size of a single buffer. Mbufs contain metadata (packet size, flags, references to interfaces, sockets, credentials, and packet buffers), while the buffers contain the packet's payload. Ultimately, this representation of packets implements a message-passing interface among all layers of the network stack. Buffers are also reference-counted, so they can be shared by multiple consumers. Mbufs and buffers are dynamically allocated from a common pool, as their lifetime exceeds the scope of individual functions.

Packets are represented by descriptors (named mbuf, 5 skbuf, 9 or NDISbuffer, depending on the operating system) linked to chains of fixed-size buffers. In such an environment, designers adopted a tradeoff between convenience of use, performance, and lean memory usage.

#NETMAP DRIVER CHANGES SOFTWARE#

At the time, memory was a scarce resource links operated at low (by today's standards) speeds parallel processing was an advanced research topic and the ability to work at line rate in all possible conditions was compromised by hardware limitations in the NIC (network interface controller) even before the software was involved.

#NETMAP DRIVER CHANGES DRIVERS#

In current mainstream operating systems (Windows, Linux, BSD and its derivatives), the architecture of the networking code and device drivers is heavily influenced by design decisions made almost 30 years ago.

Most importantly, netmap is largely compatible with existing applications, so it can be incrementally deployed. Thanks to a careful design and the engineering of a new packet I/O API, netmap eliminates much unnecessary overhead and moves traffic up to 40 times faster than existing operating systems. The netmap framework is a promising step in this direction. We can do much better, not with more powerful hardware but by revising architectural decisions made long ago regarding the design of device drivers and network stacks. On these links, packets flow as fast as one every 67.2 nanoseconds, yet modern operating systems can take 10-20 times longer just to move one packet between the wire and the application. Today 10-gigabit interfaces are used more and more in datacenters and servers. Revisiting Network I/O APIs: The netmap Framework It is possible to achieve huge performance improvements in the way packet processing is done on modern operating systems.

Netmap driver changes