Commit e4da63cd authored by Baruch Siach's avatar Baruch Siach Committed by Jakub Kicinski

docs: networking: packet_mmap: fix old config reference

Before commit 889b8f96 ("packet: Kill CONFIG_PACKET_MMAP.") there
used to be a CONFIG_PACKET_MMAP config symbol that depended on
CONFIG_PACKET. The text still implies that PACKET_MMAP can be disabled.
Remove that from the text, as well as reference to old kernel versions.

Also, drop reference to broken link to information for pre 2.6.5
kernels.

Make a slight working improvement (s/In/On/) while at it.
Signed-off-by: default avatarBaruch Siach <baruch@tkos.co.il>
Link: https://lore.kernel.org/r/80089f3783372c8fd7833f28ce774a171b2ef252.1609232919.git.baruch@tkos.co.ilSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
parent 17e94567
...@@ -8,7 +8,7 @@ Abstract ...@@ -8,7 +8,7 @@ Abstract
======== ========
This file documents the mmap() facility available with the PACKET 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 socket interface. This type of sockets is used for
i) capture network traffic with utilities like tcpdump, i) capture network traffic with utilities like tcpdump,
ii) transmit network traffic, or any other that needs raw ii) transmit network traffic, or any other that needs raw
...@@ -25,12 +25,12 @@ Please send your comments to ...@@ -25,12 +25,12 @@ Please send your comments to
Why use PACKET_MMAP Why use PACKET_MMAP
=================== ===================
In Linux 2.4/2.6/3.x if PACKET_MMAP is not enabled, the capture process is very Non PACKET_MMAP capture process (plain AF_PACKET) is very
inefficient. It uses very limited buffers and requires one system call to 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 capture each packet, it requires two if you want to get packet's timestamp
(like libpcap always does). (like libpcap always does).
In the other hand PACKET_MMAP is very efficient. PACKET_MMAP provides a size On 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 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, 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 most of the time there is no need to issue a single system call. Concerning
...@@ -252,8 +252,7 @@ PACKET_MMAP setting constraints ...@@ -252,8 +252,7 @@ PACKET_MMAP setting constraints
In kernel versions prior to 2.4.26 (for the 2.4 branch) and 2.6.5 (2.6 branch), 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 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 16384 in a 64 bit architecture.
see http://pusa.uv.es/~ulisses/packet_mmap/packet_mmap.pre-2.4.26_2.6.5.txt
Block size limit Block size limit
---------------- ----------------
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment