Re: napi_busy_poll

[Hao Xu <haoxu@linux.alibaba.com>]

在 2022/2/19 下午3:14, Olivier Langlois 写道:
> 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...

We can do the deletion at the end of each OP which we should, like
the recv, the poll_task_func/apoll_task_func. Won't affect the main path
I guess.
> 
> 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.
Exactly, that is not a high priority thing right now.
> 
> 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...