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: <CAAywjhS69zRTBM7ZLNR08kL+anYuffppzU5ZuNORxKGQgo7_TA@mail.gmail.com>
Date: Wed, 5 Feb 2025 20:43:48 -0800
From: Samiullah Khawaja <skhawaja@...gle.com>
To: Martin Karsten <mkarsten@...terloo.ca>
Cc: Joe Damato <jdamato@...tly.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 Wed, Feb 5, 2025 at 5:15 PM Martin Karsten <mkarsten@...terloo.ca> wrote:
>
> 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.
I think I have provided all the setup details and pointers to
components. I appreciate that you want to reproduce the results and If
you really really want to set it up then start by setting up onload on
your platform. I cannot provide a generic installer script for onload
that _claims_ to set it up on an arbitrary platform (with arbitrary
NIC and environment). If it works on your platform (on top of AF_XDP)
then from that point you can certainly build neper and run it using
the command I shared.
>
> 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
>