xref: /freebsd/share/man/man4/netmap.4 (revision 9a14aa017b21c292740c00ee098195cd46642730)
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