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
