From: Jakub Kicinski <kuba@kernel.org>
To: Baruch Siach <baruch@tkos.co.il>
Cc: "David S. Miller" <davem@davemloft.net>,
"Jonathan Corbet" <corbet@lwn.net>,
netdev@vger.kernel.org, linux-doc@vger.kernel.org,
"Ulisses Alonso Camaró" <uaca@alumni.uv.es>
Subject: Re: [PATCH net 2/2] docs: networking: packet_mmap: don't mention PACKET_MMAP
Date: Thu, 17 Dec 2020 10:20:37 -0800 [thread overview]
Message-ID: <20201217102037.6f5ceee9@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> (raw)
In-Reply-To: <1fc59ef61e324a969071ea537ccc2856adee3c5b.1608051077.git.baruch@tkos.co.il>
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
next prev parent reply other threads:[~2020-12-17 18:21 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-15 16:51 [PATCH net 1/2] docs: networking: packet_mmap: fix formatting for C macros Baruch Siach
2020-12-15 16:51 ` [PATCH net 2/2] docs: networking: packet_mmap: don't mention PACKET_MMAP Baruch Siach
2020-12-17 18:20 ` Jakub Kicinski [this message]
2020-12-17 21:28 ` Willem de Bruijn
2020-12-20 7:58 ` Baruch Siach
2020-12-20 14:52 ` Willem de Bruijn
2020-12-20 7:52 ` Baruch Siach
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20201217102037.6f5ceee9@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com \
--to=kuba@kernel.org \
--cc=baruch@tkos.co.il \
--cc=corbet@lwn.net \
--cc=davem@davemloft.net \
--cc=linux-doc@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=uaca@alumni.uv.es \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).