Re: napi_busy_poll

[Olivier Langlois <olivier@trillion01.com>]

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...