Thread (9 messages) flat view 9 messages, 5 authors, 2018-11-22

RE: [PATCH v1 net] lan743x: fix return value for lan743x_tx_napi_poll

From: <Bryan.Whitehead@microchip.com>
Date: 2018-11-22 03:20:11

Did you look at the output of "perf top" or something along those lines to
figure out if your lan743x driver is indeed responsible for that by not being
scheduler friendly? What is likely happening is that you do not reclaim
"weight" packets and instead keep looping into NAPI context, which
prevents the system from making further progress.
I'm having trouble installing "perf" for my kernel. But I have used GPIO's and a scope
To make sure my poll routine is called and returns in a timely manner. I've never seen
A problem with it "not being scheduler friendly"
Calling napi_complete_done() for the TX path is not necessary AFAICT, what
you really want to do is call napi_complete() and make sure you:

- reclaim/free as many TX buffers as possible, without looking at the NAPI
weight which becomes irrelevant
- if you have been able to reclaim enough descriptors, wake-up the transmit
queue

So ignoring the NAPI weight like you do is correct, but calling
napi_complete_done() with a 0 argument does not sound correct to me.
--
Florian
I see that napi_complete just maps to napi_complete_done with a 0 argument anyway.
So they are currently functionally identical, but I will make a new version that uses
napi_complete as you suggested.

But it seems you would definitely agree that the previous version of lan743x driver
Which called napi_complete_done with 'weight' as the argument is wrong,
And therefor this fix is correct.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help