netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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


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