netdev - Re: [PATCH net 2/2] docs: networking: packet_mmap: don't mention PACKET

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20201217102037.6f5ceee9@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>
Date:   Thu, 17 Dec 2020 10:20:37 -0800
From:   Jakub Kicinski <kuba@...nel.org>
To:     Baruch Siach <baruch@...s.co.il>
Cc:     "David S. Miller" <davem@...emloft.net>,
        Jonathan Corbet <corbet@....net>, netdev@...r.kernel.org,
        linux-doc@...r.kernel.org,
        Ulisses Alonso Camaró <uaca@...mni.uv.es>
Subject: Re: [PATCH net 2/2] docs: networking: packet_mmap: don't mention
 PACKET_MMAP

On Tue, 15 Dec 2020 18:51:17 +0200 Baruch Siach wrote:
> Before commit 889b8f964f2f ("packet: Kill CONFIG_PACKET_MMAP.") there
> used to be a CONFIG_PACKET_MMAP config symbol that depended on
> CONFIG_PACKET. The text still refers to PACKET_MMAP as the name of this
> feature, implying that it can be disabled. Another naming variant is
> "Packet MMAP".
> 
> Use "PACKET mmap()" everywhere to unify the terminology. Rephrase the
> text the implied mmap() feature disable option.

Should we maybe say AF_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 Linux 2.4/2.6/3.x non mmap() PACKET capture process is very inefficient. It

We can drop the references to versions. Kernels older than 2.4 are
prehistoric, and we have 4.x and 5.x now.

> +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).

Would it be possible to avoid re-flowing the existing text. IMHO it's
okay if we end on a short line, and it makes the diff easier to review.

> -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.
> +In the other hand PACKET mmap() is very efficient. PACKET mmap() provides a

While at it - "on the other hand"?

> +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
> +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