aboutsummaryrefslogtreecommitdiffstats
path: root/Makefile
diff options
context:
space:
mode:
authorRosen Penev <rosenp@gmail.com>2019-03-03 22:21:19 -0800
committerChristian Lamparter <chunkeey@gmail.com>2019-03-13 16:35:45 +0100
commit96e0fa94c700fa95bb12bee1c0b75dfeea091b29 (patch)
tree791995ecac2350717292689bca2665ab07152964 /Makefile
parent26f7cf8ac3dbd8f525c3e5593a37a6b1fab3f132 (diff)
downloadupstream-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