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] [day] [month] [year] [list]
Date:   Wed, 16 Nov 2022 13:12:11 -0700
From:   Jens Axboe <axboe@...nel.dk>
To:     Jakub Kicinski <kuba@...nel.org>
Cc:     Stefan Roesch <shr@...kernel.io>, kernel-team@...com,
        olivier@...llion01.com, netdev@...r.kernel.org,
        io-uring@...r.kernel.org
Subject: Re: [RFC PATCH v3 0/3] io_uring: add napi busy polling support

On 11/16/22 1:09 PM, Jakub Kicinski wrote:
> On Wed, 16 Nov 2022 11:44:38 -0700 Jens Axboe wrote:
>> Thanks Jakub! Question on the need for patch 3, which I think came about
>> because of comments from you. Can you expand on why we need both an
>> enable and timeout setting? Are there cases where timeout == 0 and
>> enabled == true make sense?
> 
> The enable is for the "prefer busy poll" mode, rather that just busy
> polling.
> 
> The prefer busy poll mode disables interrupts and arms a (hopefully
> long enough) fail safe timer, and expects user to come back and busy
> poll before the timer fires. The timer length is set thru sysfs params
> for NAPI/queue.
> 
> Because the Rx traffic is fully async and not in control of the local
> app, this gives the local app the ability to postpone the Rx IRQ.
> No interruptions means lower response latency. 
> With the expectation that the app will read/"busy poll" next batch of
> packets once its done servicing the previous batch.
> 
> We don't have to implement this bit from the start, "normal" busy poll
> is already functional with patches 1 and 2.

Gotcha, ok makes sense to me. I'm fine with the patchset, just want
a few adjustments on the API side as per previous email. I think
Stefan is respinning with that, then we can get it queued up.

-- 
Jens Axboe


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ