Thread (23 messages) flat view 23 messages, 4 authors, 2017-01-26

RE: [PATCH net v2 0/4] r8152: fix scheduling napi

From: Hayes Wang <hidden>
Date: 2017-01-26 03:04:58
Also in: lkml

David Miller [mailto:davem@davemloft.net]
Sent: Thursday, January 26, 2017 3:31 AM
[...]
I think the fundamental issue is that since you can't stop URBs from
queueing up, you cannot properly synchronize NAPI and schedule polling
properly.

From my perspective what happened here is you want GRO support, but it
comes at the expense of this extremely racey NAPI support which does
not at all achieve one of the main advantages of NAPI which is
interrupt mitigation.
May you apply these patches first, until I find another way to replace
current one? The driver uses NAPI now and I have no idea to find better
way to replace current one. I think it would take me long time to find
out the solution. And the issue is still there until I finish this work.
If now I give up the NAPI and its advantages except for the interrupt
mitigation, some things would become worse.

Our hw supports packet aggregation. The purpose is interrupt mitigation,
too. I wouldn't say it is better than what the NAPI does. However, I
could say we try to improve it. If the interrupt could be disabled, I
would be happy to do it. However, it is the limitation of USB devices.
That is why I still use NAPI even though the interrupt cannot be disabled
for USB devices. Because one of the advantages of NAPI couldn't be
satisfied, I must not use the NAPI. Doesn't it seem too strict?

Best Regards,
Hayes
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help