Re: [GIT PULL] io_uring updates for 5.18-rc1

[Jens Axboe <axboe@kernel.dk>]

On 3/26/22 2:06 PM, Jakub Kicinski wrote:
> On Sat, 26 Mar 2022 13:47:24 -0600 Jens Axboe wrote:
>> On 3/26/22 1:28 PM, Jakub Kicinski wrote:
>>> On Fri, 18 Mar 2022 15:59:16 -0600 Jens Axboe wrote:  
>>>> - Support for NAPI on sockets (Olivier)  
>>>
>>> Were we CCed on these patches? I don't remember seeing them, 
>>> and looks like looks like it's inventing it's own constants
>>> instead of using the config APIs we have.  
>>
>> Don't know if it was ever posted on the netdev list
> 
> Hm, maybe I don't understand how things are supposed to work. 
> I'm surprised you're unfazed.

I'm surprised you're this surprised, to be honest. It's not like someone
has been sneaking in core networking bits behind your back.

>> but the patches have been discussed for 6-9 months on the io_uring
>> list.
> 
> You may need explain to me how that's relevant :) 
> The point is the networking maintainers have not seen it.

Sorry, should've expanded on that. It's been discussed on that list for
a while, and since it was just an io_uring feature, I guess nobody
considered that it would've been great to have netdev take a look at it.
For me personally, not because I think networking need to sign off on
it, but because if it is missing using some tunables that are relevant
for NAPI outside of io_uring, we of course need to be consistent there.

>> Which constants are you referring to? Only odd one I see is
>> NAPI_TIMEOUT, other ones are using the sysctl bits. If we're
>> missing something here, do speak up and we'll make sure it's
>> consistent with the regular NAPI.
> 
> SO_BUSY_POLL_BUDGET, 8 is quite low for many practical uses.

OK. I've just started doing some network tuning, but haven't gotten
around to specifically targeting NAPI just yet. Will do so soon.

> I'd also like to have a conversation about continuing to use
> the socket as a proxy for NAPI_ID, NAPI_ID is exposed to user
> space now. io_uring being a new interface I wonder if it's not 
> better to let the user specify the request parameters directly.

Definitely open to something that makes more sense, given we don't have
to shoehorn things through the regular API for NAPI with io_uring.

-- 
Jens Axboe