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.
next prev 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