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: <b2c7d2dc-595f-4cae-ab00-61b89243fc9e@uwaterloo.ca>
Date: Wed, 5 Feb 2025 20:15:46 -0500
From: Martin Karsten <mkarsten@...terloo.ca>
To: Joe Damato <jdamato@...tly.com>, Samiullah Khawaja <skhawaja@...gle.com>,
 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 2025-02-05 17:06, Joe Damato wrote:
> On Wed, Feb 05, 2025 at 12:35:00PM -0800, Samiullah Khawaja wrote:
>> On Tue, Feb 4, 2025 at 5:32 PM Martin Karsten <mkarsten@...terloo.ca> wrote:
>>>
>>> On 2025-02-04 19:10, Samiullah Khawaja wrote:

[snip]

>>> Note that I don't dismiss the approach out of hand. I just think it's
>>> important to properly understand the purported performance improvements.
>> I think the performance improvements are apparent with the data I
>> provided, I purposefully used more sockets to show the real
>> differences in tail latency with this revision.
> 
> Respectfully, I don't agree that the improvements are "apparent." I
> think my comments and Martin's comments both suggest that the cover
> letter does not make the improvements apparent.
> 
>> Also one thing that you are probably missing here is that the change
>> here also has an API aspect, that is it allows a user to drive napi
>> independent of the user API or protocol being used.
> 
> I'm not missing that part; I'll let Martin speak for himself but I
> suspect he also follows that part.

Yes, the API aspect is quite interesting. In fact, Joe has given you 
pointers how to split this patch into multiple incremental steps, the 
first of which should be uncontroversial.

I also just read your subsequent response to Joe. He has captured the 
relevant concerns very well and I don't understand why you refuse to 
document your complete experiment setup for transparency and 
reproducibility. This shouldn't be hard.

To be clear: I would like to reproduce the experiments and then engage 
in a meaningful discussion about the pros and cons of this mechanism, 
but right now I need to speculate and there's no point in arguing 
speculation vs. assertions.

Thanks,
Martin