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
