[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <20180928.111418.1921695439745155316.davem@davemloft.net>
Date: Fri, 28 Sep 2018 11:14:18 -0700 (PDT)
From: David Miller <davem@...emloft.net>
To: edumazet@...gle.com
Cc: netdev@...r.kernel.org, michael.chan@...adcom.com,
aviad.krawczyk@...wei.com, songliubraving@...com,
dougmill@...ux.vnet.ibm.com, yisen.zhuang@...wei.com,
mst@...hat.com, jasowang@...hat.com, harish.patil@...ium.com,
manish.chopra@...ium.com, netanel@...zon.com,
linux-net-drivers@...arflare.com, tlfalcon@...ux.vnet.ibm.com
Subject: Re: [PATCH net 00/11] netpoll: second round of fixes.
From: Eric Dumazet <edumazet@...gle.com>
Date: Thu, 27 Sep 2018 09:31:50 -0700
> 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.
>
> First patch is a fix in poll_one_napi().
>
> Then following patches take care of ten drivers.
Series applied, thanks Eric.
Powered by blists - more mailing lists