From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paolo Abeni Subject: Re: [PATCH net] ixgbe: napi_poll must return the work done Date: Wed, 15 Jun 2016 17:43:47 +0200 Message-ID: <1466005427.24431.18.camel@redhat.com> References: <37ccedd746ed932b9d73eff592f324f2a3fc6c6f.1465995724.git.pabeni@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Cc: Netdev , Jeff Kirsher , intel-wired-lan , "David S. Miller" , Hannes Frederic Sowa To: Alexander Duyck Return-path: Received: from mx1.redhat.com ([209.132.183.28]:38243 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932439AbcFOPnv (ORCPT ); Wed, 15 Jun 2016 11:43:51 -0400 In-Reply-To: Sender: netdev-owner@vger.kernel.org List-ID: On Wed, 2016-06-15 at 08:20 -0700, Alexander Duyck wrote: > On Wed, Jun 15, 2016 at 6:37 AM, Paolo Abeni wrote: > > Currently the function ixgbe_poll() returns 0 when it clean completely > > the rx rings, but this foul budget accounting in core code. > > Fix this returning the actual work done, capped to weight - 1, since > > the core doesn't allow to return the full budget when the driver modifies > > the napi status > > > > Signed-off-by: Paolo Abeni > > I think the origin of reporting 0 was actually compatibility with some > NAPI code floating around from before the 2.6.24 kernel. > > I'd be curious to know how much this is actually fouling things up. > Can you point to any specific issues it was causing? I noticed this while instrumenting the napi poll loop for another patch. It's not easy to reproduce the bugged scenario, several NICs receiving a relevant amount of traffic on napi instances scheduled on the same softirq are needed. If any/some of them has the buggy poll() method, the napi_poll() loop may process (much) more than netdev_budget packets per invocation, possibly delaying others softirq more than needed/expected. The maxium delay will be no matter what capped to a couple of jiffies, due to the time-based loop end condition, so in the worst possible scenario (most probably not a real thing), this adds a latency of 2 jiffies -