diff options
author | Rosen Penev <rosenp@gmail.com> | 2019-03-03 22:21:19 -0800 |
---|---|---|
committer | Christian Lamparter <chunkeey@gmail.com> | 2019-03-13 16:35:45 +0100 |
commit | 96e0fa94c700fa95bb12bee1c0b75dfeea091b29 (patch) | |
tree | 791995ecac2350717292689bca2665ab07152964 /Makefile | |
parent | 26f7cf8ac3dbd8f525c3e5593a37a6b1fab3f132 (diff) | |
download | upstream-96e0fa94c700fa95bb12bee1c0b75dfeea091b29.tar.gz upstream-96e0fa94c700fa95bb12bee1c0b75dfeea091b29.tar.bz2 upstream-96e0fa94c700fa95bb12bee1c0b75dfeea091b29.zip |
ath79: ag71xx: Remove ndo_poll_controller
It is unused by default and upstream is trying to remove it as it has
negative effects when the driver is under load. Upstream explanation:
netpoll: avoid capture effects for NAPI drivers
As diagnosed by Song Liu, ndo_poll_controller() can
be very dangerous on loaded hosts, since the cpu
calling ndo_poll_controller() might steal all NAPI
contexts (for all RX/TX queues of the NIC).
This capture, showing one ksoftirqd eating all cycles
can last for unlimited amount of time, since one
cpu is generally not able to drain all the queues under load.
It seems that all networking drivers that do use NAPI
for their TX completions, should not provide a ndo_poll_controller() :
Most NAPI drivers have netpoll support already handled
in core networking stack, since netpoll_poll_dev(
uses poll_napi(dev) to iterate through registered
NAPI contexts for a device.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Diffstat (limited to 'Makefile')
0 files changed, 0 insertions, 0 deletions