Re: [PATCH 0/2] abstract napi tracking strategy

[Jens Axboe <axboe@kernel.dk>]

On 8/13/24 3:34 PM, Olivier Langlois wrote:
> On Tue, 2024-08-13 at 12:33 -0600, Jens Axboe wrote:
>> On 8/13/24 10:44 AM, Olivier Langlois wrote:
>>> the actual napi tracking strategy is inducing a non-negligeable
>>> overhead.
>>> Everytime a multishot poll is triggered or any poll armed, if the
>>> napi is
>>> enabled on the ring a lookup is performed to either add a new napi
>>> id into
>>> the napi_list or its timeout value is updated.
>>>
>>> For many scenarios, this is overkill as the napi id list will be
>>> pretty
>>> much static most of the time. To address this common scenario, a
>>> new
>>> abstraction has been created following the common Linux kernel
>>> idiom of
>>> creating an abstract interface with a struct filled with function
>>> pointers.
>>>
>>> Creating an alternate napi tracking strategy is therefore made in 2
>>> phases.
>>>
>>> 1. Introduce the io_napi_tracking_ops interface
>>> 2. Implement a static napi tracking by defining a new
>>> io_napi_tracking_ops
>>
>> I don't think we should create ops for this, unless there's a strict
>> need to do so. Indirect function calls aren't cheap, and the CPU side
>> mitigations for security issues made them worse.
>>
>> You're not wrong that ops is not an uncommon idiom in the kernel, but
>> it's a lot less prevalent as a solution than it used to. Exactly
>> because
>> of the above reasons.
>>
> if indirection is a very big deal, it might be possible to remove one
> level of indirection.

It's not that it's a huge deal, it's just more that if we're dealing
with a single abstraction, then I think it's somewhat overdesigning for
the use case. And I'd prefer to avoid that.

> I did entertain the idea of making copies of the io_napi_tracking_ops
> structs instead of storing their addresses. I did not kept this option
> because of the way that I did implement io_napi_get_tracking()...
> 
> but if this would be an acceptable compromise, this is definitely
> something possible.

Doesn't really change it, I think. See above.

-- 
Jens Axboe