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: <a0f5b96b-c876-4c0a-a7b5-3809c26077d6@kernel.dk>
Date: Wed, 31 Jan 2024 13:52:31 -0700
From: Jens Axboe <axboe@...nel.dk>
To: Olivier Langlois <olivier@...llion01.com>,
 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 1/31/24 12:56 PM, Olivier Langlois wrote:
> 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...

Also happy to try and run it here, if you can share it? If not I have
some other stuff I can try as well, with netbench.

-- 
Jens Axboe


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ