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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAAywjhQAb+ExOuPo33ahT68592M4FDNuWx0ieVqevBfNR-Q5TQ@mail.gmail.com>
Date: Thu, 6 Feb 2025 14:06:14 -0800
From: Samiullah Khawaja <skhawaja@...gle.com>
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 Thu, Feb 6, 2025 at 1:19 PM Joe Damato <jdamato@...tly.com> wrote:
>
> On Tue, Feb 04, 2025 at 07:18:36PM -0800, Joe Damato wrote:
> > 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.
>
> Just to give you a sense of the questions I ran into while trying to
> reproduce this just now:
>
> - What is the base SHA? You should use --base when using git
>   format-patch. I assumed the latest net-next SHA and applied the
>   patches to that.
Yes that is true. I will use --base when I do it next. Thanks for the
suggestion.
>
> - Which C3 instance type? I chose c3-highcpu-192-metal, but I could
>   have chosen c3-standard-192-metal, apparently. No idea what
>   difference this makes on the results, if any.
The tricky part is that the c3 instance variant that I am using for
dev is probably not available publicly. It is a variant of
c3-standard-192-metal but we had to enable AF_XDP on it to make it
stable to be able to run onload. You will have to reproduce this on a
platform available to you with AF_XDP as suggested in the onload
github I shared. This is the problem with providing an
installer/runner script and also system configuration. My
configuration would not be best for your platform, but you should
certainly be able to reproduce the relative improvements in latency
using the different busypolling schemes (busy_read/busy_poll vs
threaded napi busy poll) I mentioned in the cover letter.
>
> - Was "tier 1 networking" enabled? I enabled it. No idea if it
>   matters or not. I assume not, since it would be internal
>   networking within the GCP VPC of my instances and not real egress?
>
> - What version of onload was used? Which SHA or release tag?
v9.0, I agree this should be added to the cover letter.
>
> - I have no idea where to put CPU affinity for the 1 TX/RX queue, I
>   assume CPU 2 based on your other message.
Yes I replied to Martin with this information, but like I said it
certainly depends on your platform and hence didn't include it in the
cover letter. Since I don't know what/where core 2 looks like on your
platform.
>
> - The neper commands provided seem to be the server side since there
>   is no -c mentioned. What is the neper client side command?
Same command with -c
>
> - What do the environment variables set for onload+neper mean?
>
> ...
>
> Do you follow what I'm getting at here? The cover lacks a tremendous
> amount of detail that makes reproducing the setup you are using
> unnecessarily difficult.
>
> Do you agree that I should be able to read the cover letter and, if
> so desired, go off and reproduce the setup and get similar results?
Yes you should be able to that, but there are micro details of your
platform and configuration that I have no way of knowing and suggest
configurations. I have certainly pointed out the relevant environment
and special configurations (netdev queues sizes, sysctls, irq defer,
neper command and onload environment variables) that I did for each
test case in my experiment. Beyond that I have no way of providing you
an internal C3 platform or providing system configuration for your
platform.