Re: napi_busy_poll

[Olivier Langlois <olivier@trillion01.com>]

On Wed, 2022-02-16 at 11:12 +0800, Hao Xu wrote:
> 
> > 
> I read your code, I guess the thing is the sk->napi_id is set from
> skb->napi_id and the latter is set when the net device received some
> packets.
> > With my current knowledge, it makes little sense why busy polling
> > would
> > not be possible with RPS. Also, what exactly is a NAPI device is
> > quite
> > nebulous to me... Looking into the Intel igb driver code, it seems
> > like
> > 1 NAPI device is created for each interrupt vector/Rx buffer of the
> > device.
> AFAIK, yes, each Rx ring has its own NAPI.
> > 
> > Bottomline, it seems like I have fallen into a new rabbit hole. It
> > may
> > take me a day or 2 to figure it all... you are welcome to enlight
> > me if
> > you know a thing or 2 about those topics... I am kinda lost right
> > now...
> > 
> 
My dive into the net/core code has been beneficial!

I have found out that the reason why I did not have napi_id for my
sockets is because I have introduced a local SOCKS proxy into my setup.
By using the loopback device, this is de facto removing NAPI out of the
picture.

After having fixed this issue, I have started to test my code.

The modified io_cqring_wait() code does not work. With a pending recv()
request, the moment napi_busy_loop() is called, the recv() request
fails with an EFAULT error.

I suspect this might be because io_busy_loop_end() is doing something
that is not allowed while inside napi_busy_loop().

The simpler code change inside __io_sq_thread() might work but I still
have to validate.

I'll update later today or tomorrow with the latest result and
discovery!

Greetings,