if you are interested into all the details, they are all here: https://github.com/axboe/liburing/issues/1190 it seems like I like to write a lot when I am investigating a problem. Pavel has been a great help in assisting me understanding what was happening. Next, I came to question where the integration of RCU came from and I have found this: https://lore.kernel.org/all/89ef84bf-48c2-594c-cc9c-f796adcab5e8@xxxxxxxxx/ I guess that in some use-case being able to dynamically manage hundreds of NAPI devices automatically that can suddenly all be swepted over during a device reconfiguration is something desirable to have for some... but in my case, this is an excessively a high price to pay for a flexibility that I do not need at all. I have a single NAPI device. Once I know what it is, it will pratically remain immutable until termination. For that reason, I am thinking that offering some sort of polymorphic NAPI device tracking strategy customization would be desirable. The current one, the RCU one, I would call it the dynamic_napi_tracking (rcu could be peppered in the name somewhere so people know what the strategy is up to) where as the new one that I am imagining would be called static_napi_tracking. NAPI devices would be added/removed by the user manually through an extended registration function. for the sake of conveniance, a clear_list operation could even be offered. The benefits of this new static tracking strategy would be numerous: - this removes the need to invoke the heavy duty RCU cavalry - no need to scan the list to remove stall devices - no need to search the list at each SQE submission to update the device timeout value So is this a good idea in your opinion?
