From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paolo Abeni Date: Wed, 15 Jun 2016 17:43:47 +0200 Subject: [Intel-wired-lan] [PATCH net] ixgbe: napi_poll must return the work done In-Reply-To: References: <37ccedd746ed932b9d73eff592f324f2a3fc6c6f.1465995724.git.pabeni@redhat.com> Message-ID: <1466005427.24431.18.camel@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: intel-wired-lan@osuosl.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 -