Re: napi_busy_poll

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Linux Samsung SoC]     [Linux Rockchip SoC]     [Linux Actions SoC]     [Linux for Synopsys ARC Processors]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]


  Powered by Linux