On Fri, 2022-02-18 at 16:06 +0800, Hao Xu wrote: > > > > > Concerning the remaining problem about when to remove the napi_id, > > I > > would say that a good place to do it would be when a request is > > completed and discarded if there was a refcount added to your > > napi_entry struct. > > > > The only thing that I hate about this idea is that in my scenario, > > the > > sockets are going to be pretty much the same for the whole io_uring > > context existance. Therefore, the whole ref counting overhead is > > useless and unneeded. > > I remember that now all the completion is in the original task( > > should be confirmed again), > > so it should be ok to just use simple 'unsigned int count' to show > > the number of users of a napi entry. And doing deletion when count > > is 0. For your scenario, which is only one napi in a iouring context, > > This won't be big overhead as well. > > The only thing is we may need to optimize the napi lookup process, > > but I'm not sure if it is necessary. > Hi Hao, You can forget about the ref count idea. What I hated about it was that it was incurring a cost to all the io_uring users including the vast majority of them that won't be using napi_busy_poll... One thing that I know that Pavel hates is when hot paths are littered with a bunch of new code. I have been very careful doing that in my design. I think that I have found a much better approach to tackle the problem of when to remove the napi_ids... I'll stop teasing about it... The code is ready, tested... All I need to do is prepare the patch and send it to the list for review. net/core/dev.c is using a hash to store the napi structs. This could possible be easily replicated in io_uring but for now, imho, this is a polishing detail only that can be revisited later after the proof of concept will have been accepted. So eager to share the patch... This is the next thing that I do before going to bed once I am done reading my emails...
