1.\" Copyright (c) 2011 Matteo Landi, Luigi Rizzo, Universita` di Pisa 2.\" All rights reserved. 3.\" 4.\" Redistribution and use in source and binary forms, with or without 5.\" modification, are permitted provided that the following conditions 6.\" are met: 7.\" 1. Redistributions of source code must retain the above copyright 8.\" notice, this list of conditions and the following disclaimer. 9.\" 2. Redistributions in binary form must reproduce the above copyright 10.\" notice, this list of conditions and the following disclaimer in the 11.\" documentation and/or other materials provided with the distribution. 12.\" 13.\" THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND 14.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE 15.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE 16.\" ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE 17.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL 18.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS 19.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) 20.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT 21.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY 22.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF 23.\" SUCH DAMAGE. 24.\" 25.\" This document is derived in part from the enet man page (enet.4) 26.\" distributed with 4.3BSD Unix. 27.\" 28.\" $FreeBSD$ 29.\" $Id: netmap.4 9662 2011-11-16 13:18:06Z luigi $: stable/8/share/man/man4/bpf.4 181694 2008-08-13 17:45:06Z ed $ 30.\" 31.Dd November 16, 2011 32.Dt NETMAP 4 33.Os 34.Sh NAME 35.Nm netmap 36.Nd a framework for fast packet I/O 37.Sh SYNOPSIS 38.Cd device netmap 39.Sh DESCRIPTION 40.Nm 41is a framework for fast and safe access to network devices 42(reaching 14.88 Mpps at less than 1 GHz). 43.Nm 44uses memory mapped buffers and metadata 45(buffer indexes and lengths) to communicate with the kernel, 46which is in charge of validating information through 47.Pa ioctl() 48and 49.Pa select()/poll(). 50.Nm 51can exploit the parallelism in multiqueue devices and 52multicore systems. 53.Pp 54.Pp 55.Nm 56requires explicit support in device drivers. 57For a list of supported devices, see the end of this manual page. 58.Sh OPERATION 59.Nm 60clients must first open the 61.Pa open("/dev/netmap") , 62and then issue an 63.Pa ioctl(...,NIOCREGIF,...) 64to bind the file descriptor to a network device. 65.Pp 66When a device is put in 67.Nm 68mode, its data path is disconnected from the host stack. 69The processes owning the file descriptor 70can exchange packets with the device, or with the host stack, 71through an mmapped memory region that contains pre-allocated 72buffers and metadata. 73.Pp 74Non blocking I/O is done with special 75.Pa ioctl()'s , 76whereas the file descriptor can be passed to 77.Pa select()/poll() 78to be notified about incoming packet or available transmit buffers. 79.Ss Data structures 80All data structures for all devices in 81.Nm 82mode are in a memory 83region shared by the kernel and all processes 84who open 85.Pa /dev/netmap 86(NOTE: visibility may be restricted in future implementations). 87All references between the shared data structure 88are relative (offsets or indexes). Some macros help converting 89them into actual pointers. 90.Pp 91The data structures in shared memory are the following: 92.Pp 93.Bl -tag -width XXX 94.It Dv struct netmap_if (one per interface) 95indicates the number of rings supported by an interface, their 96sizes, and the offsets of the 97.Pa netmap_rings 98associated to the interface. 99The offset of a 100.Pa struct netmap_if 101in the shared memory region is indicated by the 102.Pa nr_offset 103field in the structure returned by the 104.Pa NIOCREGIF 105(see below). 106.Bd -literal 107struct netmap_if { 108 char ni_name[IFNAMSIZ]; /* name of the interface. */ 109 const u_int ni_num_queues; /* number of hw ring pairs */ 110 const ssize_t ring_ofs[]; /* offset of tx and rx rings */ 111}; 112.Ed 113.It Dv struct netmap_ring (one per ring) 114contains the index of the current read or write slot (cur), 115the number of slots available for reception or transmission (avail), 116and an array of 117.Pa slots 118describing the buffers. 119There is one ring pair for each of the N hardware ring pairs 120supported by the card (numbered 0..N-1), plus 121one ring pair (numbered N) for packets from/to the host stack. 122.Bd -literal 123struct netmap_ring { 124 const ssize_t buf_ofs; 125 const uint32_t num_slots; /* number of slots in the ring. */ 126 uint32_t avail; /* number of usable slots */ 127 uint32_t cur; /* 'current' index for the user side */ 128 129 const uint16_t nr_buf_size; 130 uint16_t flags; 131 struct netmap_slot slot[0]; /* array of slots. */ 132} 133.Ed 134.It Dv struct netmap_slot (one per packet) 135contains the metadata for a packet: a buffer index (buf_idx), 136a buffer length (len), and some flags. 137.Bd -literal 138struct netmap_slot { 139 uint32_t buf_idx; /* buffer index */ 140 uint16_t len; /* packet length */ 141 uint16_t flags; /* buf changed, etc. */ 142#define NS_BUF_CHANGED 0x0001 /* must resync, buffer changed */ 143#define NS_REPORT 0x0002 /* tell hw to report results 144 * e.g. by generating an interrupt 145 */ 146}; 147.Ed 148.It Dv packet buffers 149are fixed size (approximately 2k) buffers allocated by the kernel 150that contain packet data. Buffers addresses are computed through 151macros. 152.El 153.Pp 154Some macros support the access to objects in the shared memory 155region. In particular: 156.Bd -literal 157struct netmap_if *nifp; 158struct netmap_ring *txring = NETMAP_TXRING(nifp, i); 159struct netmap_ring *rxring = NETMAP_RXRING(nifp, i); 160int i = txring->slot[txring->cur].buf_idx; 161char *buf = NETMAP_BUF(txring, i); 162.Ed 163.Ss IOCTLS 164.Pp 165.Nm 166supports some ioctl() to synchronize the state of the rings 167between the kernel and the user processes, plus some 168to query and configure the interface. 169The former do not require any argument, whereas the latter 170use a 171.Pa struct netmap_req 172defined as follows: 173.Bd -literal 174struct nmreq { 175 char nr_name[IFNAMSIZ]; 176 uint32_t nr_offset; /* nifp offset in the shared region */ 177 uint32_t nr_memsize; /* size of the shared region */ 178 uint32_t nr_numdescs; /* descriptors per queue */ 179 uint16_t nr_numqueues; 180 uint16_t nr_ringid; /* ring(s) we care about */ 181#define NETMAP_HW_RING 0x4000 /* low bits indicate one hw ring */ 182#define NETMAP_SW_RING 0x2000 /* we process the sw ring */ 183#define NETMAP_NO_TX_POLL 0x1000 /* no gratuitous txsync on poll */ 184#define NETMAP_RING_MASK 0xfff /* the actual ring number */ 185}; 186 187.Ed 188A device descriptor obtained through 189.Pa /dev/netmap 190also supports the ioctl supported by network devices. 191.Pp 192The netmap-specific 193.Xr ioctl 2 194command codes below are defined in 195.In net/netmap.h 196and are: 197.Bl -tag -width XXXX 198.It Dv NIOCGINFO 199returns information about the interface named in nr_name. 200On return, nr_memsize indicates the size of the shared netmap 201memory region (this is device-independent), 202nr_numslots indicates how many buffers are in a ring, 203nr_numrings indicates the number of rings supported by the hardware. 204.Pp 205If the device does not support netmap, the ioctl returns EINVAL. 206.It Dv NIOCREGIF 207puts the interface named in nr_name into netmap mode, disconnecting 208it from the host stack, and/or defines which rings are controlled 209through this file descriptor. 210On return, it gives the same info as NIOCGINFO, and nr_ringid 211indicates the identity of the rings controlled through the file 212descriptor. 213.Pp 214Possible values for nr_ringid are 215.Bl -tag -width XXXXX 216.It 0 217default, all hardware rings 218.It NETMAP_SW_RING 219the ``host rings'' connecting to the host stack 220.It NETMAP_HW_RING + i 221the i-th hardware ring 222.El 223By default, a 224.Nm poll 225or 226.Nm select 227call pushes out any pending packets on the transmit ring, even if 228no write events are specified. 229The feature can be disabled by or-ing 230.Nm NETMAP_NO_TX_SYNC 231to nr_ringid. 232But normally you should keep this feature unless you are using 233separate file descriptors for the send and receive rings, because 234otherwise packets are pushed out only if NETMAP_TXSYNC is called, 235or the send queue is full. 236.Pp 237.Pa NIOCREGIF 238can be used multiple times to change the association of a 239file descriptor to a ring pair, always within the same device. 240.It Dv NIOCUNREGIF 241brings an interface back to normal mode. 242.It Dv NIOCTXSYNC 243tells the hardware of new packets to transmit, and updates the 244number of slots available for transmission. 245.It Dv NIOCRXSYNC 246tells the hardware of consumed packets, and asks for newly available 247packets. 248.El 249.Ss SYSTEM CALLS 250.Nm 251uses 252.Nm select 253and 254.Nm poll 255to wake up processes when significant events occur. 256.Sh EXAMPLES 257The following code implements a traffic generator 258.Pp 259.Bd -literal -compact 260#include <net/netmap.h> 261#include <net/netmap_user.h> 262struct netmap_if *nifp; 263struct netmap_ring *ring; 264struct netmap_request nmr; 265 266fd = open("/dev/netmap", O_RDWR); 267bzero(&nmr, sizeof(nmr)); 268strcpy(nmr.nm_name, "ix0"); 269ioctl(fd, NIOCREG, &nmr); 270p = mmap(0, nmr.memsize, fd); 271nifp = NETMAP_IF(p, nmr.offset); 272ring = NETMAP_TXRING(nifp, 0); 273fds.fd = fd; 274fds.events = POLLOUT; 275for (;;) { 276 poll(list, 1, -1); 277 while (ring->avail-- > 0) { 278 i = ring->cur; 279 buf = NETMAP_BUF(ring, ring->slot[i].buf_index); 280 ... prepare packet in buf ... 281 ring->slot[i].len = ... packet length ... 282 ring->cur = NETMAP_RING_NEXT(ring, i); 283 } 284} 285.Ed 286.Sh SUPPORTED INTERFACES 287.Nm 288supports the following interfaces: 289.Xr em 4 , 290.Xr ixgbe 4 , 291.Xr re 4 , 292.Sh AUTHORS 293The 294.Nm 295framework has been designed and implemented by 296.An Luigi Rizzo 297and 298.An Matteo Landi 299in 2011 at the Universita` di Pisa. 300