netdev - Re: [PATCH net-next v3 0/4] Add support to do threaded napi busy poll

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: <CAAywjhRd-tQz3ra6uUvZf_rwTT+5a04BfeA59bcG8ziW_4FLWg@mail.gmail.com>
Date: Wed, 5 Feb 2025 21:49:04 -0800
From: Samiullah Khawaja <skhawaja@...gle.com>
To: Dave Taht <dave.taht@...il.com>
Cc: Jakub Kicinski <kuba@...nel.org>, "David S . Miller" <davem@...emloft.net>, 
	Eric Dumazet <edumazet@...gle.com>, Paolo Abeni <pabeni@...hat.com>, almasrymina@...gle.com, 
	netdev@...r.kernel.org
Subject: Re: [PATCH net-next v3 0/4] Add support to do threaded napi busy poll

On Wed, Feb 5, 2025 at 9:36 PM Dave Taht <dave.taht@...il.com> wrote:
>
> I have often wondered the effects of reducing napi poll weight from 64
> to 16 or less.
Yes, that is Interesting. I think higher weight would allow it to
fetch more descriptors doing more batching but then packets are pushed
up the stack late. A lower value would push packet up the stack
quicker, but then if the core is being shared with the application
processing thread then the descriptors will spend more time in the NIC
queue.
>
> Also your test shows an increase in max latency...
>
> latency_max=0.200182942
I noticed this anomaly and my guess is that it is a packet drop and
this is basically a retransmit timeout. Going through tcpdumps to
confirm.