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]
Date: Wed, 31 Jan 2024 14:56:04 -0500
From: Olivier Langlois <olivier@...llion01.com>
To: Jens Axboe <axboe@...nel.dk>, Stefan Roesch <shr@...kernel.io>, 
	io-uring@...r.kernel.org, kernel-team@...com
Cc: ammarfaizi2@...weeb.org, netdev@...r.kernel.org, kuba@...nel.org
Subject: Re: [PATCH v15 0/7] io_uring: add napi busy polling support

On Wed, 2024-01-31 at 12:59 -0500, Olivier Langlois wrote:
> On Wed, 2024-01-31 at 10:32 -0700, Jens Axboe wrote:
> > 
> > Thanks for testing!
> > 
> > Any chance that you could run some tests with and without NAPI that
> > help
> > validate that it actually works? That part is what I'm most
> > interested
> > in, not too worried about the stability of it as I have scrutinized
> > it
> > pretty close already.
> > 
> 
> There is maybe a test that I can perform. The data that I receive is
> timestamped. I have a small test program that checks the age of the
> updates on their reception...
> 
> I would expect that it should be possible to perceive the busy
> polling
> effect by comparing the average update age with and without the
> feature
> enabled...
> 
> A word of warning... The service that my client is connecting to has
> relocated recently. I used to have an RTT of about 8mSec with it to
> about 400-500 mSec today...
> 
> because of the huge RTT, I am unsure that the test is going to be
> conclusive at all...
> 
> However, I am also in the process of relocating my client closer to
> the
> service. If you can wait a week or so, I should able to do that test
> with a RTT < 1 mSec...
> 
> Beside that, I could redo the same test that Stefan did with the ping
> client/server setup but would that test add any value to the current
> collective knowledge?
> 
> I'll do the update age test when I restart my client and I'll report
> back the result but my expectations aren't very high that it is going
> to be conclusive due to the huge RTT.
> 
> 
As I expected, the busy polling difference in the update age test is so
small compared to the RTT that the result is inconclusive, IMHO...

The number of collected updates to build the stats is 500.

System clocks are assumed to be synchronized and the RTT is the
difference between the local time and the update timestamp.
Actually, it may be more accurate to say that the displayed RTT values
are in fact TT...

latency NO napi busy poll:
[2024-01-31 11:28:34] INFO Main/processCollectedData rtt
min/avg/max/mdev = 74.509/76.752/115.969/3.110 ms

latency napi busy poll:
[2024-01-31 11:33:05] INFO Main/processCollectedData rtt
min/avg/max/mdev = 75.347/76.740/134.588/1.648 ms

I'll redo the test once my RTT is closer to 1mSec. The relative gain
should be more impressive...


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ