From: Paolo Abeni <pabeni@redhat.com>
To: intel-wired-lan@osuosl.org
Subject: [Intel-wired-lan] [PATCH net] ixgbe: napi_poll must return the work done
Date: Wed, 15 Jun 2016 17:43:47 +0200 [thread overview]
Message-ID: <1466005427.24431.18.camel@redhat.com> (raw)
In-Reply-To: <CAKgT0UeU7tfo=i5O1j9ORwBJUVYGta5Z-NLw+xKGVLeHQ=PPtg@mail.gmail.com>
On Wed, 2016-06-15 at 08:20 -0700, Alexander Duyck wrote:
> On Wed, Jun 15, 2016 at 6:37 AM, Paolo Abeni <pabeni@redhat.com> 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 <pabeni@redhat.com>
>
> 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 - <time required to process netdev_budget packets> (~1.8ms on
recent h/w with HZ==1000).
> If you end up
> having to submit a v2 for any reason it might be useful if you can
> provide the additional details on what actual issue it was causing.
>
> You might also want to look at the other Intel drivers, specifically
> ixgbevf and fm10k as I believe we have similar code in those drivers
> as well.
Thank you for the head-up. I need to get an hand on that h/w, first!
Paolo
>
> Acked-by: Alexander Duyck <aduyck@mirantis.com>
WARNING: multiple messages have this Message-ID (diff)
From: Paolo Abeni <pabeni@redhat.com>
To: Alexander Duyck <alexander.duyck@gmail.com>
Cc: Netdev <netdev@vger.kernel.org>,
Jeff Kirsher <jeffrey.t.kirsher@intel.com>,
intel-wired-lan <intel-wired-lan@lists.osuosl.org>,
"David S. Miller" <davem@davemloft.net>,
Hannes Frederic Sowa <hannes@redhat.com>
Subject: Re: [PATCH net] ixgbe: napi_poll must return the work done
Date: Wed, 15 Jun 2016 17:43:47 +0200 [thread overview]
Message-ID: <1466005427.24431.18.camel@redhat.com> (raw)
In-Reply-To: <CAKgT0UeU7tfo=i5O1j9ORwBJUVYGta5Z-NLw+xKGVLeHQ=PPtg@mail.gmail.com>
On Wed, 2016-06-15 at 08:20 -0700, Alexander Duyck wrote:
> On Wed, Jun 15, 2016 at 6:37 AM, Paolo Abeni <pabeni@redhat.com> 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 <pabeni@redhat.com>
>
> 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 - <time required to process netdev_budget packets> (~1.8ms on
recent h/w with HZ==1000).
> If you end up
> having to submit a v2 for any reason it might be useful if you can
> provide the additional details on what actual issue it was causing.
>
> You might also want to look at the other Intel drivers, specifically
> ixgbevf and fm10k as I believe we have similar code in those drivers
> as well.
Thank you for the head-up. I need to get an hand on that h/w, first!
Paolo
>
> Acked-by: Alexander Duyck <aduyck@mirantis.com>
next prev parent reply other threads:[~2016-06-15 15:43 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-15 13:37 [Intel-wired-lan] [PATCH net] ixgbe: napi_poll must return the work done Paolo Abeni
2016-06-15 13:37 ` Paolo Abeni
2016-06-15 15:20 ` [Intel-wired-lan] " Alexander Duyck
2016-06-15 15:20 ` Alexander Duyck
2016-06-15 15:43 ` Paolo Abeni [this message]
2016-06-15 15:43 ` Paolo Abeni
2016-06-15 16:34 ` [Intel-wired-lan] " Venkatesh Srinivas
2016-06-15 16:34 ` Venkatesh Srinivas
2016-06-16 17:10 ` [Intel-wired-lan] " Keller, Jacob E
2016-06-16 17:10 ` Keller, Jacob E
2016-06-16 17:40 ` [Intel-wired-lan] " Keller, Jacob E
2016-06-16 17:40 ` Keller, Jacob E
2016-06-16 17:43 ` [Intel-wired-lan] " Keller, Jacob E
2016-06-16 17:43 ` Keller, Jacob E
2016-07-13 15:12 ` [Intel-wired-lan] " Bowers, AndrewX
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1466005427.24431.18.camel@redhat.com \
--to=pabeni@redhat.com \
--cc=intel-wired-lan@osuosl.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.