public inbox for netdev@vger.kernel.org
 help / color / mirror / Atom feed
From: Joe Damato <jdamato@fastly.com>
To: Samiullah Khawaja <skhawaja@google.com>
Cc: Jakub Kicinski <kuba@kernel.org>,
	"David S . Miller " <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	Paolo Abeni <pabeni@redhat.com>,
	almasrymina@google.com, netdev@vger.kernel.org
Subject: Re: [PATCH net-next v3 0/4] Add support to do threaded napi busy poll
Date: Tue, 4 Feb 2025 19:18:36 -0800	[thread overview]
Message-ID: <Z6LYjHJxx0pI45WU@LQ3V64L9R2> (raw)
In-Reply-To: <20250205001052.2590140-1-skhawaja@google.com>

On Wed, Feb 05, 2025 at 12:10:48AM +0000, Samiullah Khawaja wrote:
> Extend the already existing support of threaded napi poll to do continuous
> busy polling.

[...]

Overall, +1 to everything Martin said in his response. I think I'd
like to try to reproduce this myself to better understand the stated
numbers below.

IMHO: the cover letter needs more details.

> 
> Setup:
> 
> - Running on Google C3 VMs with idpf driver with following configurations.
> - IRQ affinity and coalascing is common for both experiments.

As Martin suggested, a lot more detail here would be helpful.

> - There is only 1 RX/TX queue configured.
> - First experiment enables busy poll using sysctl for both epoll and
>   socket APIs.
> - Second experiment enables NAPI threaded busy poll for the full device
>   using sysctl.
> 
> Non threaded NAPI busy poll enabled using sysctl.
> ```
> echo 400 | sudo tee /proc/sys/net/core/busy_poll
> echo 400 | sudo tee /proc/sys/net/core/busy_read

I'm not sure why busy_read is enabled here?

Maybe more details on how exactly the internals of onload+neper work
would explain it, but I presume it's an epoll_wait loop with
non-blocking reads so busy_read wouldn't do anything?

> echo 2 | sudo tee /sys/class/net/eth0/napi_defer_hard_irqs
> echo 15000  | sudo tee /sys/class/net/eth0/gro_flush_timeout
> ```

The deferral amounts above are relatively small, which makes me
wonder if you are seeing IRQ and softIRQ interference in the base
case?

I ask because it seems like in the test case (if I read the patch
correctly) the processing of packets happens when BH is disabled.

Did I get that right?

If so, then:
  - In the base case, IRQs can be generated and softirq can interfere
    with packet processing.

  - In the test case, packet processing happens but BH is disabled,
    reducing interference.

If I got that right, it sounds like IRQ suspension would show good
results in this case, too, and it's probably worth comparing IRQ
suspension in the onload+neper setup.

It seems like it shouldn't be too difficult to get onload+neper
using it and the data would be very enlightening.

  parent reply	other threads:[~2025-02-05  3:18 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-02-05  0:10 [PATCH net-next v3 0/4] Add support to do threaded napi busy poll Samiullah Khawaja
2025-02-05  0:10 ` [PATCH net-next v3 1/4] Add support to set napi threaded for individual napi Samiullah Khawaja
2025-02-05  2:50   ` Joe Damato
2025-02-05 23:10   ` David Laight
2025-02-06 18:40     ` Joe Damato
2025-02-05  0:10 ` [PATCH net-next v3 2/4] net: Create separate gro_flush helper function Samiullah Khawaja
2025-02-05  2:55   ` Joe Damato
2025-02-05  0:10 ` [PATCH net-next v3 3/4] Extend napi threaded polling to allow kthread based busy polling Samiullah Khawaja
2025-02-05  9:08   ` Paul Barker
2025-02-06  3:40   ` Samudrala, Sridhar
2025-02-05  0:10 ` [PATCH net-next v3 4/4] selftests: Add napi threaded busy poll test in `busy_poller` Samiullah Khawaja
2025-02-05  0:14 ` [PATCH net-next v3 0/4] Add support to do threaded napi busy poll Samiullah Khawaja
2025-02-05  1:32 ` Martin Karsten
2025-02-05 20:35   ` Samiullah Khawaja
2025-02-05 22:06     ` Joe Damato
2025-02-06  0:45       ` Samiullah Khawaja
2025-02-06 13:42         ` Joe Damato
2025-02-06 22:49           ` Samiullah Khawaja
2025-02-06 22:58             ` Joe Damato
2025-02-06  1:15       ` Martin Karsten
2025-02-06  4:43         ` Samiullah Khawaja
2025-02-06  4:50           ` Martin Karsten
2025-02-06  6:43             ` Samiullah Khawaja
2025-02-06 14:00               ` Joe Damato
2025-02-06 13:54           ` Joe Damato
2025-02-05  3:18 ` Joe Damato [this message]
2025-02-06 21:19   ` Joe Damato
2025-02-06 22:06     ` Samiullah Khawaja
2025-02-06 22:48       ` Joe Damato
2025-02-07  3:13         ` Samiullah Khawaja
2025-02-07  3:50           ` Joe Damato
2025-02-11  2:52       ` Martin Karsten
2025-02-06  5:36 ` Dave Taht
2025-02-06  5:49   ` Samiullah Khawaja
2025-02-06  5:57     ` Dave Taht
2025-02-06 14:01     ` Joe Damato
2025-02-06 19:50   ` David Laight

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=Z6LYjHJxx0pI45WU@LQ3V64L9R2 \
    --to=jdamato@fastly.com \
    --cc=almasrymina@google.com \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=kuba@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=skhawaja@google.com \
    /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