mirror of
https://github.com/AuxXxilium/linux_dsm_epyc7002.git
synced 2024-12-16 02:36:51 +07:00
68a360e82e
No device driver will ever return an skb_shared_info structure with syststamp non-zero, so remove the branch that tests for this and optionally marks the packet timestamp as TP_STATUS_TS_SYS_HARDWARE. Do not remove the definition TP_STATUS_TS_SYS_HARDWARE, as processes may refer to it. Signed-off-by: Willem de Bruijn <willemb@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
1062 lines
36 KiB
Plaintext
1062 lines
36 KiB
Plaintext
--------------------------------------------------------------------------------
|
|
+ ABSTRACT
|
|
--------------------------------------------------------------------------------
|
|
|
|
This file documents the mmap() facility available with the PACKET
|
|
socket interface on 2.4/2.6/3.x kernels. This type of sockets is used for
|
|
i) capture network traffic with utilities like tcpdump, ii) transmit network
|
|
traffic, or any other that needs raw access to network interface.
|
|
|
|
You can find the latest version of this document at:
|
|
http://wiki.ipxwarzone.com/index.php5?title=Linux_packet_mmap
|
|
|
|
Howto can be found at:
|
|
http://wiki.gnu-log.net (packet_mmap)
|
|
|
|
Please send your comments to
|
|
Ulisses Alonso Camaró <uaca@i.hate.spam.alumni.uv.es>
|
|
Johann Baudy <johann.baudy@gnu-log.net>
|
|
|
|
-------------------------------------------------------------------------------
|
|
+ Why use PACKET_MMAP
|
|
--------------------------------------------------------------------------------
|
|
|
|
In Linux 2.4/2.6/3.x if PACKET_MMAP is not enabled, the capture process is very
|
|
inefficient. It uses very limited buffers and requires one system call to
|
|
capture each packet, it requires two if you want to get packet's timestamp
|
|
(like libpcap always does).
|
|
|
|
In the other hand PACKET_MMAP is very efficient. PACKET_MMAP provides a size
|
|
configurable circular buffer mapped in user space that can be used to either
|
|
send or receive packets. This way reading packets just needs to wait for them,
|
|
most of the time there is no need to issue a single system call. Concerning
|
|
transmission, multiple packets can be sent through one system call to get the
|
|
highest bandwidth. By using a shared buffer between the kernel and the user
|
|
also has the benefit of minimizing packet copies.
|
|
|
|
It's fine to use PACKET_MMAP to improve the performance of the capture and
|
|
transmission process, but it isn't everything. At least, if you are capturing
|
|
at high speeds (this is relative to the cpu speed), you should check if the
|
|
device driver of your network interface card supports some sort of interrupt
|
|
load mitigation or (even better) if it supports NAPI, also make sure it is
|
|
enabled. For transmission, check the MTU (Maximum Transmission Unit) used and
|
|
supported by devices of your network. CPU IRQ pinning of your network interface
|
|
card can also be an advantage.
|
|
|
|
--------------------------------------------------------------------------------
|
|
+ How to use mmap() to improve capture process
|
|
--------------------------------------------------------------------------------
|
|
|
|
From the user standpoint, you should use the higher level libpcap library, which
|
|
is a de facto standard, portable across nearly all operating systems
|
|
including Win32.
|
|
|
|
Said that, at time of this writing, official libpcap 0.8.1 is out and doesn't include
|
|
support for PACKET_MMAP, and also probably the libpcap included in your distribution.
|
|
|
|
I'm aware of two implementations of PACKET_MMAP in libpcap:
|
|
|
|
http://wiki.ipxwarzone.com/ (by Simon Patarin, based on libpcap 0.6.2)
|
|
http://public.lanl.gov/cpw/ (by Phil Wood, based on lastest libpcap)
|
|
|
|
The rest of this document is intended for people who want to understand
|
|
the low level details or want to improve libpcap by including PACKET_MMAP
|
|
support.
|
|
|
|
--------------------------------------------------------------------------------
|
|
+ How to use mmap() directly to improve capture process
|
|
--------------------------------------------------------------------------------
|
|
|
|
From the system calls stand point, the use of PACKET_MMAP involves
|
|
the following process:
|
|
|
|
|
|
[setup] socket() -------> creation of the capture socket
|
|
setsockopt() ---> allocation of the circular buffer (ring)
|
|
option: PACKET_RX_RING
|
|
mmap() ---------> mapping of the allocated buffer to the
|
|
user process
|
|
|
|
[capture] poll() ---------> to wait for incoming packets
|
|
|
|
[shutdown] close() --------> destruction of the capture socket and
|
|
deallocation of all associated
|
|
resources.
|
|
|
|
|
|
socket creation and destruction is straight forward, and is done
|
|
the same way with or without PACKET_MMAP:
|
|
|
|
int fd = socket(PF_PACKET, mode, htons(ETH_P_ALL));
|
|
|
|
where mode is SOCK_RAW for the raw interface were link level
|
|
information can be captured or SOCK_DGRAM for the cooked
|
|
interface where link level information capture is not
|
|
supported and a link level pseudo-header is provided
|
|
by the kernel.
|
|
|
|
The destruction of the socket and all associated resources
|
|
is done by a simple call to close(fd).
|
|
|
|
Similarly as without PACKET_MMAP, it is possible to use one socket
|
|
for capture and transmission. This can be done by mapping the
|
|
allocated RX and TX buffer ring with a single mmap() call.
|
|
See "Mapping and use of the circular buffer (ring)".
|
|
|
|
Next I will describe PACKET_MMAP settings and its constraints,
|
|
also the mapping of the circular buffer in the user process and
|
|
the use of this buffer.
|
|
|
|
--------------------------------------------------------------------------------
|
|
+ How to use mmap() directly to improve transmission process
|
|
--------------------------------------------------------------------------------
|
|
Transmission process is similar to capture as shown below.
|
|
|
|
[setup] socket() -------> creation of the transmission socket
|
|
setsockopt() ---> allocation of the circular buffer (ring)
|
|
option: PACKET_TX_RING
|
|
bind() ---------> bind transmission socket with a network interface
|
|
mmap() ---------> mapping of the allocated buffer to the
|
|
user process
|
|
|
|
[transmission] poll() ---------> wait for free packets (optional)
|
|
send() ---------> send all packets that are set as ready in
|
|
the ring
|
|
The flag MSG_DONTWAIT can be used to return
|
|
before end of transfer.
|
|
|
|
[shutdown] close() --------> destruction of the transmission socket and
|
|
deallocation of all associated resources.
|
|
|
|
Socket creation and destruction is also straight forward, and is done
|
|
the same way as in capturing described in the previous paragraph:
|
|
|
|
int fd = socket(PF_PACKET, mode, 0);
|
|
|
|
The protocol can optionally be 0 in case we only want to transmit
|
|
via this socket, which avoids an expensive call to packet_rcv().
|
|
In this case, you also need to bind(2) the TX_RING with sll_protocol = 0
|
|
set. Otherwise, htons(ETH_P_ALL) or any other protocol, for example.
|
|
|
|
Binding the socket to your network interface is mandatory (with zero copy) to
|
|
know the header size of frames used in the circular buffer.
|
|
|
|
As capture, each frame contains two parts:
|
|
|
|
--------------------
|
|
| struct tpacket_hdr | Header. It contains the status of
|
|
| | of this frame
|
|
|--------------------|
|
|
| data buffer |
|
|
. . Data that will be sent over the network interface.
|
|
. .
|
|
--------------------
|
|
|
|
bind() associates the socket to your network interface thanks to
|
|
sll_ifindex parameter of struct sockaddr_ll.
|
|
|
|
Initialization example:
|
|
|
|
struct sockaddr_ll my_addr;
|
|
struct ifreq s_ifr;
|
|
...
|
|
|
|
strncpy (s_ifr.ifr_name, "eth0", sizeof(s_ifr.ifr_name));
|
|
|
|
/* get interface index of eth0 */
|
|
ioctl(this->socket, SIOCGIFINDEX, &s_ifr);
|
|
|
|
/* fill sockaddr_ll struct to prepare binding */
|
|
my_addr.sll_family = AF_PACKET;
|
|
my_addr.sll_protocol = htons(ETH_P_ALL);
|
|
my_addr.sll_ifindex = s_ifr.ifr_ifindex;
|
|
|
|
/* bind socket to eth0 */
|
|
bind(this->socket, (struct sockaddr *)&my_addr, sizeof(struct sockaddr_ll));
|
|
|
|
A complete tutorial is available at: http://wiki.gnu-log.net/
|
|
|
|
By default, the user should put data at :
|
|
frame base + TPACKET_HDRLEN - sizeof(struct sockaddr_ll)
|
|
|
|
So, whatever you choose for the socket mode (SOCK_DGRAM or SOCK_RAW),
|
|
the beginning of the user data will be at :
|
|
frame base + TPACKET_ALIGN(sizeof(struct tpacket_hdr))
|
|
|
|
If you wish to put user data at a custom offset from the beginning of
|
|
the frame (for payload alignment with SOCK_RAW mode for instance) you
|
|
can set tp_net (with SOCK_DGRAM) or tp_mac (with SOCK_RAW). In order
|
|
to make this work it must be enabled previously with setsockopt()
|
|
and the PACKET_TX_HAS_OFF option.
|
|
|
|
--------------------------------------------------------------------------------
|
|
+ PACKET_MMAP settings
|
|
--------------------------------------------------------------------------------
|
|
|
|
To setup PACKET_MMAP from user level code is done with a call like
|
|
|
|
- Capture process
|
|
setsockopt(fd, SOL_PACKET, PACKET_RX_RING, (void *) &req, sizeof(req))
|
|
- Transmission process
|
|
setsockopt(fd, SOL_PACKET, PACKET_TX_RING, (void *) &req, sizeof(req))
|
|
|
|
The most significant argument in the previous call is the req parameter,
|
|
this parameter must to have the following structure:
|
|
|
|
struct tpacket_req
|
|
{
|
|
unsigned int tp_block_size; /* Minimal size of contiguous block */
|
|
unsigned int tp_block_nr; /* Number of blocks */
|
|
unsigned int tp_frame_size; /* Size of frame */
|
|
unsigned int tp_frame_nr; /* Total number of frames */
|
|
};
|
|
|
|
This structure is defined in /usr/include/linux/if_packet.h and establishes a
|
|
circular buffer (ring) of unswappable memory.
|
|
Being mapped in the capture process allows reading the captured frames and
|
|
related meta-information like timestamps without requiring a system call.
|
|
|
|
Frames are grouped in blocks. Each block is a physically contiguous
|
|
region of memory and holds tp_block_size/tp_frame_size frames. The total number
|
|
of blocks is tp_block_nr. Note that tp_frame_nr is a redundant parameter because
|
|
|
|
frames_per_block = tp_block_size/tp_frame_size
|
|
|
|
indeed, packet_set_ring checks that the following condition is true
|
|
|
|
frames_per_block * tp_block_nr == tp_frame_nr
|
|
|
|
Lets see an example, with the following values:
|
|
|
|
tp_block_size= 4096
|
|
tp_frame_size= 2048
|
|
tp_block_nr = 4
|
|
tp_frame_nr = 8
|
|
|
|
we will get the following buffer structure:
|
|
|
|
block #1 block #2
|
|
+---------+---------+ +---------+---------+
|
|
| frame 1 | frame 2 | | frame 3 | frame 4 |
|
|
+---------+---------+ +---------+---------+
|
|
|
|
block #3 block #4
|
|
+---------+---------+ +---------+---------+
|
|
| frame 5 | frame 6 | | frame 7 | frame 8 |
|
|
+---------+---------+ +---------+---------+
|
|
|
|
A frame can be of any size with the only condition it can fit in a block. A block
|
|
can only hold an integer number of frames, or in other words, a frame cannot
|
|
be spawned across two blocks, so there are some details you have to take into
|
|
account when choosing the frame_size. See "Mapping and use of the circular
|
|
buffer (ring)".
|
|
|
|
--------------------------------------------------------------------------------
|
|
+ PACKET_MMAP setting constraints
|
|
--------------------------------------------------------------------------------
|
|
|
|
In kernel versions prior to 2.4.26 (for the 2.4 branch) and 2.6.5 (2.6 branch),
|
|
the PACKET_MMAP buffer could hold only 32768 frames in a 32 bit architecture or
|
|
16384 in a 64 bit architecture. For information on these kernel versions
|
|
see http://pusa.uv.es/~ulisses/packet_mmap/packet_mmap.pre-2.4.26_2.6.5.txt
|
|
|
|
Block size limit
|
|
------------------
|
|
|
|
As stated earlier, each block is a contiguous physical region of memory. These
|
|
memory regions are allocated with calls to the __get_free_pages() function. As
|
|
the name indicates, this function allocates pages of memory, and the second
|
|
argument is "order" or a power of two number of pages, that is
|
|
(for PAGE_SIZE == 4096) order=0 ==> 4096 bytes, order=1 ==> 8192 bytes,
|
|
order=2 ==> 16384 bytes, etc. The maximum size of a
|
|
region allocated by __get_free_pages is determined by the MAX_ORDER macro. More
|
|
precisely the limit can be calculated as:
|
|
|
|
PAGE_SIZE << MAX_ORDER
|
|
|
|
In a i386 architecture PAGE_SIZE is 4096 bytes
|
|
In a 2.4/i386 kernel MAX_ORDER is 10
|
|
In a 2.6/i386 kernel MAX_ORDER is 11
|
|
|
|
So get_free_pages can allocate as much as 4MB or 8MB in a 2.4/2.6 kernel
|
|
respectively, with an i386 architecture.
|
|
|
|
User space programs can include /usr/include/sys/user.h and
|
|
/usr/include/linux/mmzone.h to get PAGE_SIZE MAX_ORDER declarations.
|
|
|
|
The pagesize can also be determined dynamically with the getpagesize (2)
|
|
system call.
|
|
|
|
Block number limit
|
|
--------------------
|
|
|
|
To understand the constraints of PACKET_MMAP, we have to see the structure
|
|
used to hold the pointers to each block.
|
|
|
|
Currently, this structure is a dynamically allocated vector with kmalloc
|
|
called pg_vec, its size limits the number of blocks that can be allocated.
|
|
|
|
+---+---+---+---+
|
|
| x | x | x | x |
|
|
+---+---+---+---+
|
|
| | | |
|
|
| | | v
|
|
| | v block #4
|
|
| v block #3
|
|
v block #2
|
|
block #1
|
|
|
|
kmalloc allocates any number of bytes of physically contiguous memory from
|
|
a pool of pre-determined sizes. This pool of memory is maintained by the slab
|
|
allocator which is at the end the responsible for doing the allocation and
|
|
hence which imposes the maximum memory that kmalloc can allocate.
|
|
|
|
In a 2.4/2.6 kernel and the i386 architecture, the limit is 131072 bytes. The
|
|
predetermined sizes that kmalloc uses can be checked in the "size-<bytes>"
|
|
entries of /proc/slabinfo
|
|
|
|
In a 32 bit architecture, pointers are 4 bytes long, so the total number of
|
|
pointers to blocks is
|
|
|
|
131072/4 = 32768 blocks
|
|
|
|
PACKET_MMAP buffer size calculator
|
|
------------------------------------
|
|
|
|
Definitions:
|
|
|
|
<size-max> : is the maximum size of allocable with kmalloc (see /proc/slabinfo)
|
|
<pointer size>: depends on the architecture -- sizeof(void *)
|
|
<page size> : depends on the architecture -- PAGE_SIZE or getpagesize (2)
|
|
<max-order> : is the value defined with MAX_ORDER
|
|
<frame size> : it's an upper bound of frame's capture size (more on this later)
|
|
|
|
from these definitions we will derive
|
|
|
|
<block number> = <size-max>/<pointer size>
|
|
<block size> = <pagesize> << <max-order>
|
|
|
|
so, the max buffer size is
|
|
|
|
<block number> * <block size>
|
|
|
|
and, the number of frames be
|
|
|
|
<block number> * <block size> / <frame size>
|
|
|
|
Suppose the following parameters, which apply for 2.6 kernel and an
|
|
i386 architecture:
|
|
|
|
<size-max> = 131072 bytes
|
|
<pointer size> = 4 bytes
|
|
<pagesize> = 4096 bytes
|
|
<max-order> = 11
|
|
|
|
and a value for <frame size> of 2048 bytes. These parameters will yield
|
|
|
|
<block number> = 131072/4 = 32768 blocks
|
|
<block size> = 4096 << 11 = 8 MiB.
|
|
|
|
and hence the buffer will have a 262144 MiB size. So it can hold
|
|
262144 MiB / 2048 bytes = 134217728 frames
|
|
|
|
Actually, this buffer size is not possible with an i386 architecture.
|
|
Remember that the memory is allocated in kernel space, in the case of
|
|
an i386 kernel's memory size is limited to 1GiB.
|
|
|
|
All memory allocations are not freed until the socket is closed. The memory
|
|
allocations are done with GFP_KERNEL priority, this basically means that
|
|
the allocation can wait and swap other process' memory in order to allocate
|
|
the necessary memory, so normally limits can be reached.
|
|
|
|
Other constraints
|
|
-------------------
|
|
|
|
If you check the source code you will see that what I draw here as a frame
|
|
is not only the link level frame. At the beginning of each frame there is a
|
|
header called struct tpacket_hdr used in PACKET_MMAP to hold link level's frame
|
|
meta information like timestamp. So what we draw here a frame it's really
|
|
the following (from include/linux/if_packet.h):
|
|
|
|
/*
|
|
Frame structure:
|
|
|
|
- Start. Frame must be aligned to TPACKET_ALIGNMENT=16
|
|
- struct tpacket_hdr
|
|
- pad to TPACKET_ALIGNMENT=16
|
|
- struct sockaddr_ll
|
|
- Gap, chosen so that packet data (Start+tp_net) aligns to
|
|
TPACKET_ALIGNMENT=16
|
|
- Start+tp_mac: [ Optional MAC header ]
|
|
- Start+tp_net: Packet data, aligned to TPACKET_ALIGNMENT=16.
|
|
- Pad to align to TPACKET_ALIGNMENT=16
|
|
*/
|
|
|
|
The following are conditions that are checked in packet_set_ring
|
|
|
|
tp_block_size must be a multiple of PAGE_SIZE (1)
|
|
tp_frame_size must be greater than TPACKET_HDRLEN (obvious)
|
|
tp_frame_size must be a multiple of TPACKET_ALIGNMENT
|
|
tp_frame_nr must be exactly frames_per_block*tp_block_nr
|
|
|
|
Note that tp_block_size should be chosen to be a power of two or there will
|
|
be a waste of memory.
|
|
|
|
--------------------------------------------------------------------------------
|
|
+ Mapping and use of the circular buffer (ring)
|
|
--------------------------------------------------------------------------------
|
|
|
|
The mapping of the buffer in the user process is done with the conventional
|
|
mmap function. Even the circular buffer is compound of several physically
|
|
discontiguous blocks of memory, they are contiguous to the user space, hence
|
|
just one call to mmap is needed:
|
|
|
|
mmap(0, size, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0);
|
|
|
|
If tp_frame_size is a divisor of tp_block_size frames will be
|
|
contiguously spaced by tp_frame_size bytes. If not, each
|
|
tp_block_size/tp_frame_size frames there will be a gap between
|
|
the frames. This is because a frame cannot be spawn across two
|
|
blocks.
|
|
|
|
To use one socket for capture and transmission, the mapping of both the
|
|
RX and TX buffer ring has to be done with one call to mmap:
|
|
|
|
...
|
|
setsockopt(fd, SOL_PACKET, PACKET_RX_RING, &foo, sizeof(foo));
|
|
setsockopt(fd, SOL_PACKET, PACKET_TX_RING, &bar, sizeof(bar));
|
|
...
|
|
rx_ring = mmap(0, size * 2, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0);
|
|
tx_ring = rx_ring + size;
|
|
|
|
RX must be the first as the kernel maps the TX ring memory right
|
|
after the RX one.
|
|
|
|
At the beginning of each frame there is an status field (see
|
|
struct tpacket_hdr). If this field is 0 means that the frame is ready
|
|
to be used for the kernel, If not, there is a frame the user can read
|
|
and the following flags apply:
|
|
|
|
+++ Capture process:
|
|
from include/linux/if_packet.h
|
|
|
|
#define TP_STATUS_COPY 2
|
|
#define TP_STATUS_LOSING 4
|
|
#define TP_STATUS_CSUMNOTREADY 8
|
|
|
|
TP_STATUS_COPY : This flag indicates that the frame (and associated
|
|
meta information) has been truncated because it's
|
|
larger than tp_frame_size. This packet can be
|
|
read entirely with recvfrom().
|
|
|
|
In order to make this work it must to be
|
|
enabled previously with setsockopt() and
|
|
the PACKET_COPY_THRESH option.
|
|
|
|
The number of frames that can be buffered to
|
|
be read with recvfrom is limited like a normal socket.
|
|
See the SO_RCVBUF option in the socket (7) man page.
|
|
|
|
TP_STATUS_LOSING : indicates there were packet drops from last time
|
|
statistics where checked with getsockopt() and
|
|
the PACKET_STATISTICS option.
|
|
|
|
TP_STATUS_CSUMNOTREADY: currently it's used for outgoing IP packets which
|
|
its checksum will be done in hardware. So while
|
|
reading the packet we should not try to check the
|
|
checksum.
|
|
|
|
for convenience there are also the following defines:
|
|
|
|
#define TP_STATUS_KERNEL 0
|
|
#define TP_STATUS_USER 1
|
|
|
|
The kernel initializes all frames to TP_STATUS_KERNEL, when the kernel
|
|
receives a packet it puts in the buffer and updates the status with
|
|
at least the TP_STATUS_USER flag. Then the user can read the packet,
|
|
once the packet is read the user must zero the status field, so the kernel
|
|
can use again that frame buffer.
|
|
|
|
The user can use poll (any other variant should apply too) to check if new
|
|
packets are in the ring:
|
|
|
|
struct pollfd pfd;
|
|
|
|
pfd.fd = fd;
|
|
pfd.revents = 0;
|
|
pfd.events = POLLIN|POLLRDNORM|POLLERR;
|
|
|
|
if (status == TP_STATUS_KERNEL)
|
|
retval = poll(&pfd, 1, timeout);
|
|
|
|
It doesn't incur in a race condition to first check the status value and
|
|
then poll for frames.
|
|
|
|
++ Transmission process
|
|
Those defines are also used for transmission:
|
|
|
|
#define TP_STATUS_AVAILABLE 0 // Frame is available
|
|
#define TP_STATUS_SEND_REQUEST 1 // Frame will be sent on next send()
|
|
#define TP_STATUS_SENDING 2 // Frame is currently in transmission
|
|
#define TP_STATUS_WRONG_FORMAT 4 // Frame format is not correct
|
|
|
|
First, the kernel initializes all frames to TP_STATUS_AVAILABLE. To send a
|
|
packet, the user fills a data buffer of an available frame, sets tp_len to
|
|
current data buffer size and sets its status field to TP_STATUS_SEND_REQUEST.
|
|
This can be done on multiple frames. Once the user is ready to transmit, it
|
|
calls send(). Then all buffers with status equal to TP_STATUS_SEND_REQUEST are
|
|
forwarded to the network device. The kernel updates each status of sent
|
|
frames with TP_STATUS_SENDING until the end of transfer.
|
|
At the end of each transfer, buffer status returns to TP_STATUS_AVAILABLE.
|
|
|
|
header->tp_len = in_i_size;
|
|
header->tp_status = TP_STATUS_SEND_REQUEST;
|
|
retval = send(this->socket, NULL, 0, 0);
|
|
|
|
The user can also use poll() to check if a buffer is available:
|
|
(status == TP_STATUS_SENDING)
|
|
|
|
struct pollfd pfd;
|
|
pfd.fd = fd;
|
|
pfd.revents = 0;
|
|
pfd.events = POLLOUT;
|
|
retval = poll(&pfd, 1, timeout);
|
|
|
|
-------------------------------------------------------------------------------
|
|
+ What TPACKET versions are available and when to use them?
|
|
-------------------------------------------------------------------------------
|
|
|
|
int val = tpacket_version;
|
|
setsockopt(fd, SOL_PACKET, PACKET_VERSION, &val, sizeof(val));
|
|
getsockopt(fd, SOL_PACKET, PACKET_VERSION, &val, sizeof(val));
|
|
|
|
where 'tpacket_version' can be TPACKET_V1 (default), TPACKET_V2, TPACKET_V3.
|
|
|
|
TPACKET_V1:
|
|
- Default if not otherwise specified by setsockopt(2)
|
|
- RX_RING, TX_RING available
|
|
|
|
TPACKET_V1 --> TPACKET_V2:
|
|
- Made 64 bit clean due to unsigned long usage in TPACKET_V1
|
|
structures, thus this also works on 64 bit kernel with 32 bit
|
|
userspace and the like
|
|
- Timestamp resolution in nanoseconds instead of microseconds
|
|
- RX_RING, TX_RING available
|
|
- VLAN metadata information available for packets
|
|
(TP_STATUS_VLAN_VALID, TP_STATUS_VLAN_TPID_VALID),
|
|
in the tpacket2_hdr structure:
|
|
- TP_STATUS_VLAN_VALID bit being set into the tp_status field indicates
|
|
that the tp_vlan_tci field has valid VLAN TCI value
|
|
- TP_STATUS_VLAN_TPID_VALID bit being set into the tp_status field
|
|
indicates that the tp_vlan_tpid field has valid VLAN TPID value
|
|
- How to switch to TPACKET_V2:
|
|
1. Replace struct tpacket_hdr by struct tpacket2_hdr
|
|
2. Query header len and save
|
|
3. Set protocol version to 2, set up ring as usual
|
|
4. For getting the sockaddr_ll,
|
|
use (void *)hdr + TPACKET_ALIGN(hdrlen) instead of
|
|
(void *)hdr + TPACKET_ALIGN(sizeof(struct tpacket_hdr))
|
|
|
|
TPACKET_V2 --> TPACKET_V3:
|
|
- Flexible buffer implementation:
|
|
1. Blocks can be configured with non-static frame-size
|
|
2. Read/poll is at a block-level (as opposed to packet-level)
|
|
3. Added poll timeout to avoid indefinite user-space wait
|
|
on idle links
|
|
4. Added user-configurable knobs:
|
|
4.1 block::timeout
|
|
4.2 tpkt_hdr::sk_rxhash
|
|
- RX Hash data available in user space
|
|
- Currently only RX_RING available
|
|
|
|
-------------------------------------------------------------------------------
|
|
+ AF_PACKET fanout mode
|
|
-------------------------------------------------------------------------------
|
|
|
|
In the AF_PACKET fanout mode, packet reception can be load balanced among
|
|
processes. This also works in combination with mmap(2) on packet sockets.
|
|
|
|
Currently implemented fanout policies are:
|
|
|
|
- PACKET_FANOUT_HASH: schedule to socket by skb's packet hash
|
|
- PACKET_FANOUT_LB: schedule to socket by round-robin
|
|
- PACKET_FANOUT_CPU: schedule to socket by CPU packet arrives on
|
|
- PACKET_FANOUT_RND: schedule to socket by random selection
|
|
- PACKET_FANOUT_ROLLOVER: if one socket is full, rollover to another
|
|
- PACKET_FANOUT_QM: schedule to socket by skbs recorded queue_mapping
|
|
|
|
Minimal example code by David S. Miller (try things like "./test eth0 hash",
|
|
"./test eth0 lb", etc.):
|
|
|
|
#include <stddef.h>
|
|
#include <stdlib.h>
|
|
#include <stdio.h>
|
|
#include <string.h>
|
|
|
|
#include <sys/types.h>
|
|
#include <sys/wait.h>
|
|
#include <sys/socket.h>
|
|
#include <sys/ioctl.h>
|
|
|
|
#include <unistd.h>
|
|
|
|
#include <linux/if_ether.h>
|
|
#include <linux/if_packet.h>
|
|
|
|
#include <net/if.h>
|
|
|
|
static const char *device_name;
|
|
static int fanout_type;
|
|
static int fanout_id;
|
|
|
|
#ifndef PACKET_FANOUT
|
|
# define PACKET_FANOUT 18
|
|
# define PACKET_FANOUT_HASH 0
|
|
# define PACKET_FANOUT_LB 1
|
|
#endif
|
|
|
|
static int setup_socket(void)
|
|
{
|
|
int err, fd = socket(AF_PACKET, SOCK_RAW, htons(ETH_P_IP));
|
|
struct sockaddr_ll ll;
|
|
struct ifreq ifr;
|
|
int fanout_arg;
|
|
|
|
if (fd < 0) {
|
|
perror("socket");
|
|
return EXIT_FAILURE;
|
|
}
|
|
|
|
memset(&ifr, 0, sizeof(ifr));
|
|
strcpy(ifr.ifr_name, device_name);
|
|
err = ioctl(fd, SIOCGIFINDEX, &ifr);
|
|
if (err < 0) {
|
|
perror("SIOCGIFINDEX");
|
|
return EXIT_FAILURE;
|
|
}
|
|
|
|
memset(&ll, 0, sizeof(ll));
|
|
ll.sll_family = AF_PACKET;
|
|
ll.sll_ifindex = ifr.ifr_ifindex;
|
|
err = bind(fd, (struct sockaddr *) &ll, sizeof(ll));
|
|
if (err < 0) {
|
|
perror("bind");
|
|
return EXIT_FAILURE;
|
|
}
|
|
|
|
fanout_arg = (fanout_id | (fanout_type << 16));
|
|
err = setsockopt(fd, SOL_PACKET, PACKET_FANOUT,
|
|
&fanout_arg, sizeof(fanout_arg));
|
|
if (err) {
|
|
perror("setsockopt");
|
|
return EXIT_FAILURE;
|
|
}
|
|
|
|
return fd;
|
|
}
|
|
|
|
static void fanout_thread(void)
|
|
{
|
|
int fd = setup_socket();
|
|
int limit = 10000;
|
|
|
|
if (fd < 0)
|
|
exit(fd);
|
|
|
|
while (limit-- > 0) {
|
|
char buf[1600];
|
|
int err;
|
|
|
|
err = read(fd, buf, sizeof(buf));
|
|
if (err < 0) {
|
|
perror("read");
|
|
exit(EXIT_FAILURE);
|
|
}
|
|
if ((limit % 10) == 0)
|
|
fprintf(stdout, "(%d) \n", getpid());
|
|
}
|
|
|
|
fprintf(stdout, "%d: Received 10000 packets\n", getpid());
|
|
|
|
close(fd);
|
|
exit(0);
|
|
}
|
|
|
|
int main(int argc, char **argp)
|
|
{
|
|
int fd, err;
|
|
int i;
|
|
|
|
if (argc != 3) {
|
|
fprintf(stderr, "Usage: %s INTERFACE {hash|lb}\n", argp[0]);
|
|
return EXIT_FAILURE;
|
|
}
|
|
|
|
if (!strcmp(argp[2], "hash"))
|
|
fanout_type = PACKET_FANOUT_HASH;
|
|
else if (!strcmp(argp[2], "lb"))
|
|
fanout_type = PACKET_FANOUT_LB;
|
|
else {
|
|
fprintf(stderr, "Unknown fanout type [%s]\n", argp[2]);
|
|
exit(EXIT_FAILURE);
|
|
}
|
|
|
|
device_name = argp[1];
|
|
fanout_id = getpid() & 0xffff;
|
|
|
|
for (i = 0; i < 4; i++) {
|
|
pid_t pid = fork();
|
|
|
|
switch (pid) {
|
|
case 0:
|
|
fanout_thread();
|
|
|
|
case -1:
|
|
perror("fork");
|
|
exit(EXIT_FAILURE);
|
|
}
|
|
}
|
|
|
|
for (i = 0; i < 4; i++) {
|
|
int status;
|
|
|
|
wait(&status);
|
|
}
|
|
|
|
return 0;
|
|
}
|
|
|
|
-------------------------------------------------------------------------------
|
|
+ AF_PACKET TPACKET_V3 example
|
|
-------------------------------------------------------------------------------
|
|
|
|
AF_PACKET's TPACKET_V3 ring buffer can be configured to use non-static frame
|
|
sizes by doing it's own memory management. It is based on blocks where polling
|
|
works on a per block basis instead of per ring as in TPACKET_V2 and predecessor.
|
|
|
|
It is said that TPACKET_V3 brings the following benefits:
|
|
*) ~15 - 20% reduction in CPU-usage
|
|
*) ~20% increase in packet capture rate
|
|
*) ~2x increase in packet density
|
|
*) Port aggregation analysis
|
|
*) Non static frame size to capture entire packet payload
|
|
|
|
So it seems to be a good candidate to be used with packet fanout.
|
|
|
|
Minimal example code by Daniel Borkmann based on Chetan Loke's lolpcap (compile
|
|
it with gcc -Wall -O2 blob.c, and try things like "./a.out eth0", etc.):
|
|
|
|
/* Written from scratch, but kernel-to-user space API usage
|
|
* dissected from lolpcap:
|
|
* Copyright 2011, Chetan Loke <loke.chetan@gmail.com>
|
|
* License: GPL, version 2.0
|
|
*/
|
|
|
|
#include <stdio.h>
|
|
#include <stdlib.h>
|
|
#include <stdint.h>
|
|
#include <string.h>
|
|
#include <assert.h>
|
|
#include <net/if.h>
|
|
#include <arpa/inet.h>
|
|
#include <netdb.h>
|
|
#include <poll.h>
|
|
#include <unistd.h>
|
|
#include <signal.h>
|
|
#include <inttypes.h>
|
|
#include <sys/socket.h>
|
|
#include <sys/mman.h>
|
|
#include <linux/if_packet.h>
|
|
#include <linux/if_ether.h>
|
|
#include <linux/ip.h>
|
|
|
|
#ifndef likely
|
|
# define likely(x) __builtin_expect(!!(x), 1)
|
|
#endif
|
|
#ifndef unlikely
|
|
# define unlikely(x) __builtin_expect(!!(x), 0)
|
|
#endif
|
|
|
|
struct block_desc {
|
|
uint32_t version;
|
|
uint32_t offset_to_priv;
|
|
struct tpacket_hdr_v1 h1;
|
|
};
|
|
|
|
struct ring {
|
|
struct iovec *rd;
|
|
uint8_t *map;
|
|
struct tpacket_req3 req;
|
|
};
|
|
|
|
static unsigned long packets_total = 0, bytes_total = 0;
|
|
static sig_atomic_t sigint = 0;
|
|
|
|
static void sighandler(int num)
|
|
{
|
|
sigint = 1;
|
|
}
|
|
|
|
static int setup_socket(struct ring *ring, char *netdev)
|
|
{
|
|
int err, i, fd, v = TPACKET_V3;
|
|
struct sockaddr_ll ll;
|
|
unsigned int blocksiz = 1 << 22, framesiz = 1 << 11;
|
|
unsigned int blocknum = 64;
|
|
|
|
fd = socket(AF_PACKET, SOCK_RAW, htons(ETH_P_ALL));
|
|
if (fd < 0) {
|
|
perror("socket");
|
|
exit(1);
|
|
}
|
|
|
|
err = setsockopt(fd, SOL_PACKET, PACKET_VERSION, &v, sizeof(v));
|
|
if (err < 0) {
|
|
perror("setsockopt");
|
|
exit(1);
|
|
}
|
|
|
|
memset(&ring->req, 0, sizeof(ring->req));
|
|
ring->req.tp_block_size = blocksiz;
|
|
ring->req.tp_frame_size = framesiz;
|
|
ring->req.tp_block_nr = blocknum;
|
|
ring->req.tp_frame_nr = (blocksiz * blocknum) / framesiz;
|
|
ring->req.tp_retire_blk_tov = 60;
|
|
ring->req.tp_feature_req_word = TP_FT_REQ_FILL_RXHASH;
|
|
|
|
err = setsockopt(fd, SOL_PACKET, PACKET_RX_RING, &ring->req,
|
|
sizeof(ring->req));
|
|
if (err < 0) {
|
|
perror("setsockopt");
|
|
exit(1);
|
|
}
|
|
|
|
ring->map = mmap(NULL, ring->req.tp_block_size * ring->req.tp_block_nr,
|
|
PROT_READ | PROT_WRITE, MAP_SHARED | MAP_LOCKED, fd, 0);
|
|
if (ring->map == MAP_FAILED) {
|
|
perror("mmap");
|
|
exit(1);
|
|
}
|
|
|
|
ring->rd = malloc(ring->req.tp_block_nr * sizeof(*ring->rd));
|
|
assert(ring->rd);
|
|
for (i = 0; i < ring->req.tp_block_nr; ++i) {
|
|
ring->rd[i].iov_base = ring->map + (i * ring->req.tp_block_size);
|
|
ring->rd[i].iov_len = ring->req.tp_block_size;
|
|
}
|
|
|
|
memset(&ll, 0, sizeof(ll));
|
|
ll.sll_family = PF_PACKET;
|
|
ll.sll_protocol = htons(ETH_P_ALL);
|
|
ll.sll_ifindex = if_nametoindex(netdev);
|
|
ll.sll_hatype = 0;
|
|
ll.sll_pkttype = 0;
|
|
ll.sll_halen = 0;
|
|
|
|
err = bind(fd, (struct sockaddr *) &ll, sizeof(ll));
|
|
if (err < 0) {
|
|
perror("bind");
|
|
exit(1);
|
|
}
|
|
|
|
return fd;
|
|
}
|
|
|
|
static void display(struct tpacket3_hdr *ppd)
|
|
{
|
|
struct ethhdr *eth = (struct ethhdr *) ((uint8_t *) ppd + ppd->tp_mac);
|
|
struct iphdr *ip = (struct iphdr *) ((uint8_t *) eth + ETH_HLEN);
|
|
|
|
if (eth->h_proto == htons(ETH_P_IP)) {
|
|
struct sockaddr_in ss, sd;
|
|
char sbuff[NI_MAXHOST], dbuff[NI_MAXHOST];
|
|
|
|
memset(&ss, 0, sizeof(ss));
|
|
ss.sin_family = PF_INET;
|
|
ss.sin_addr.s_addr = ip->saddr;
|
|
getnameinfo((struct sockaddr *) &ss, sizeof(ss),
|
|
sbuff, sizeof(sbuff), NULL, 0, NI_NUMERICHOST);
|
|
|
|
memset(&sd, 0, sizeof(sd));
|
|
sd.sin_family = PF_INET;
|
|
sd.sin_addr.s_addr = ip->daddr;
|
|
getnameinfo((struct sockaddr *) &sd, sizeof(sd),
|
|
dbuff, sizeof(dbuff), NULL, 0, NI_NUMERICHOST);
|
|
|
|
printf("%s -> %s, ", sbuff, dbuff);
|
|
}
|
|
|
|
printf("rxhash: 0x%x\n", ppd->hv1.tp_rxhash);
|
|
}
|
|
|
|
static void walk_block(struct block_desc *pbd, const int block_num)
|
|
{
|
|
int num_pkts = pbd->h1.num_pkts, i;
|
|
unsigned long bytes = 0;
|
|
struct tpacket3_hdr *ppd;
|
|
|
|
ppd = (struct tpacket3_hdr *) ((uint8_t *) pbd +
|
|
pbd->h1.offset_to_first_pkt);
|
|
for (i = 0; i < num_pkts; ++i) {
|
|
bytes += ppd->tp_snaplen;
|
|
display(ppd);
|
|
|
|
ppd = (struct tpacket3_hdr *) ((uint8_t *) ppd +
|
|
ppd->tp_next_offset);
|
|
}
|
|
|
|
packets_total += num_pkts;
|
|
bytes_total += bytes;
|
|
}
|
|
|
|
static void flush_block(struct block_desc *pbd)
|
|
{
|
|
pbd->h1.block_status = TP_STATUS_KERNEL;
|
|
}
|
|
|
|
static void teardown_socket(struct ring *ring, int fd)
|
|
{
|
|
munmap(ring->map, ring->req.tp_block_size * ring->req.tp_block_nr);
|
|
free(ring->rd);
|
|
close(fd);
|
|
}
|
|
|
|
int main(int argc, char **argp)
|
|
{
|
|
int fd, err;
|
|
socklen_t len;
|
|
struct ring ring;
|
|
struct pollfd pfd;
|
|
unsigned int block_num = 0, blocks = 64;
|
|
struct block_desc *pbd;
|
|
struct tpacket_stats_v3 stats;
|
|
|
|
if (argc != 2) {
|
|
fprintf(stderr, "Usage: %s INTERFACE\n", argp[0]);
|
|
return EXIT_FAILURE;
|
|
}
|
|
|
|
signal(SIGINT, sighandler);
|
|
|
|
memset(&ring, 0, sizeof(ring));
|
|
fd = setup_socket(&ring, argp[argc - 1]);
|
|
assert(fd > 0);
|
|
|
|
memset(&pfd, 0, sizeof(pfd));
|
|
pfd.fd = fd;
|
|
pfd.events = POLLIN | POLLERR;
|
|
pfd.revents = 0;
|
|
|
|
while (likely(!sigint)) {
|
|
pbd = (struct block_desc *) ring.rd[block_num].iov_base;
|
|
|
|
if ((pbd->h1.block_status & TP_STATUS_USER) == 0) {
|
|
poll(&pfd, 1, -1);
|
|
continue;
|
|
}
|
|
|
|
walk_block(pbd, block_num);
|
|
flush_block(pbd);
|
|
block_num = (block_num + 1) % blocks;
|
|
}
|
|
|
|
len = sizeof(stats);
|
|
err = getsockopt(fd, SOL_PACKET, PACKET_STATISTICS, &stats, &len);
|
|
if (err < 0) {
|
|
perror("getsockopt");
|
|
exit(1);
|
|
}
|
|
|
|
fflush(stdout);
|
|
printf("\nReceived %u packets, %lu bytes, %u dropped, freeze_q_cnt: %u\n",
|
|
stats.tp_packets, bytes_total, stats.tp_drops,
|
|
stats.tp_freeze_q_cnt);
|
|
|
|
teardown_socket(&ring, fd);
|
|
return 0;
|
|
}
|
|
|
|
-------------------------------------------------------------------------------
|
|
+ PACKET_QDISC_BYPASS
|
|
-------------------------------------------------------------------------------
|
|
|
|
If there is a requirement to load the network with many packets in a similar
|
|
fashion as pktgen does, you might set the following option after socket
|
|
creation:
|
|
|
|
int one = 1;
|
|
setsockopt(fd, SOL_PACKET, PACKET_QDISC_BYPASS, &one, sizeof(one));
|
|
|
|
This has the side-effect, that packets sent through PF_PACKET will bypass the
|
|
kernel's qdisc layer and are forcedly pushed to the driver directly. Meaning,
|
|
packet are not buffered, tc disciplines are ignored, increased loss can occur
|
|
and such packets are also not visible to other PF_PACKET sockets anymore. So,
|
|
you have been warned; generally, this can be useful for stress testing various
|
|
components of a system.
|
|
|
|
On default, PACKET_QDISC_BYPASS is disabled and needs to be explicitly enabled
|
|
on PF_PACKET sockets.
|
|
|
|
-------------------------------------------------------------------------------
|
|
+ PACKET_TIMESTAMP
|
|
-------------------------------------------------------------------------------
|
|
|
|
The PACKET_TIMESTAMP setting determines the source of the timestamp in
|
|
the packet meta information for mmap(2)ed RX_RING and TX_RINGs. If your
|
|
NIC is capable of timestamping packets in hardware, you can request those
|
|
hardware timestamps to be used. Note: you may need to enable the generation
|
|
of hardware timestamps with SIOCSHWTSTAMP (see related information from
|
|
Documentation/networking/timestamping.txt).
|
|
|
|
PACKET_TIMESTAMP accepts the same integer bit field as SO_TIMESTAMPING:
|
|
|
|
int req = SOF_TIMESTAMPING_RAW_HARDWARE;
|
|
setsockopt(fd, SOL_PACKET, PACKET_TIMESTAMP, (void *) &req, sizeof(req))
|
|
|
|
For the mmap(2)ed ring buffers, such timestamps are stored in the
|
|
tpacket{,2,3}_hdr structure's tp_sec and tp_{n,u}sec members. To determine
|
|
what kind of timestamp has been reported, the tp_status field is binary |'ed
|
|
with the following possible bits ...
|
|
|
|
TP_STATUS_TS_RAW_HARDWARE
|
|
TP_STATUS_TS_SOFTWARE
|
|
|
|
... that are equivalent to its SOF_TIMESTAMPING_* counterparts. For the
|
|
RX_RING, if neither is set (i.e. PACKET_TIMESTAMP is not set), then a
|
|
software fallback was invoked *within* PF_PACKET's processing code (less
|
|
precise).
|
|
|
|
Getting timestamps for the TX_RING works as follows: i) fill the ring frames,
|
|
ii) call sendto() e.g. in blocking mode, iii) wait for status of relevant
|
|
frames to be updated resp. the frame handed over to the application, iv) walk
|
|
through the frames to pick up the individual hw/sw timestamps.
|
|
|
|
Only (!) if transmit timestamping is enabled, then these bits are combined
|
|
with binary | with TP_STATUS_AVAILABLE, so you must check for that in your
|
|
application (e.g. !(tp_status & (TP_STATUS_SEND_REQUEST | TP_STATUS_SENDING))
|
|
in a first step to see if the frame belongs to the application, and then
|
|
one can extract the type of timestamp in a second step from tp_status)!
|
|
|
|
If you don't care about them, thus having it disabled, checking for
|
|
TP_STATUS_AVAILABLE resp. TP_STATUS_WRONG_FORMAT is sufficient. If in the
|
|
TX_RING part only TP_STATUS_AVAILABLE is set, then the tp_sec and tp_{n,u}sec
|
|
members do not contain a valid value. For TX_RINGs, by default no timestamp
|
|
is generated!
|
|
|
|
See include/linux/net_tstamp.h and Documentation/networking/timestamping
|
|
for more information on hardware timestamps.
|
|
|
|
-------------------------------------------------------------------------------
|
|
+ Miscellaneous bits
|
|
-------------------------------------------------------------------------------
|
|
|
|
- Packet sockets work well together with Linux socket filters, thus you also
|
|
might want to have a look at Documentation/networking/filter.txt
|
|
|
|
--------------------------------------------------------------------------------
|
|
+ THANKS
|
|
--------------------------------------------------------------------------------
|
|
|
|
Jesse Brandeburg, for fixing my grammathical/spelling errors
|
|
|