From: Jesse Brandeburg <jesse.brandeburg@intel.com>
To: intel-wired-lan@osuosl.org
Subject: [Intel-wired-lan] [PATCH net-next v1 1/2] net: core: count drops from GRO
Date: Fri, 8 Jan 2021 10:35:37 -0800 [thread overview]
Message-ID: <20210108103537.00005168@intel.com> (raw)
In-Reply-To: <CANn89iLcRrmXW_MGjuMMnNxWS+kaEnY=Y79hCPuiwiDd_G9=EA@mail.gmail.com>
Eric Dumazet wrote:
> > --- a/net/core/dev.c
> > +++ b/net/core/dev.c
> > @@ -6071,6 +6071,7 @@ static gro_result_t napi_skb_finish(struct napi_struct *napi,
> > break;
> >
> > case GRO_DROP:
> > + atomic_long_inc(&skb->dev->rx_dropped);
> > kfree_skb(skb);
> > break;
> >
> > @@ -6159,6 +6160,7 @@ static gro_result_t napi_frags_finish(struct napi_struct *napi,
> > break;
> >
> > case GRO_DROP:
> > + atomic_long_inc(&skb->dev->rx_dropped);
> > napi_reuse_skb(napi, skb);
> > break;
> >
>
>
> This is not needed. I think we should clean up ice instead.
My patch 2 already did that. I was trying to address the fact that I'm
*actually seeing* GRO_DROP return codes coming back from stack.
I'll try to reproduce that issue again that I saw. Maybe modern kernels
don't have the problem as frequently or at all.
> Drivers are supposed to have allocated the skb (using
> napi_get_frags()) before calling napi_gro_frags()
ice doesn't use napi_get_frags/napi_gro_frags, so I'm not sure how this
is relevant.
> Only napi_gro_frags() would return GRO_DROP, but we supposedly could
> crash at that point, since a driver is clearly buggy.
seems unlikely since we don't call those functions.
> We probably can remove GRO_DROP completely, assuming lazy drivers are fixed.
This might be ok, but doesn't explain why I was seeing this return
code (which was the whole reason I was trying to count them), however I
may have been running on a distro kernel from redhat/centos 8 when I
was seeing these events. I haven't fully completed spelunking all the
different sources, but might be able to follow down the rabbit hole
further.
> diff --git a/net/core/dev.c b/net/core/dev.c
> index 8fa739259041aaa03585b5a7b8ebce862f4b7d1d..c9460c9597f1de51957fdcfc7a64ca45bce5af7c
> 100644
> --- a/net/core/dev.c
> +++ b/net/core/dev.c
> @@ -6223,9 +6223,6 @@ gro_result_t napi_gro_frags(struct napi_struct *napi)
> gro_result_t ret;
> struct sk_buff *skb = napi_frags_skb(napi);
>
> - if (!skb)
> - return GRO_DROP;
> -
> trace_napi_gro_frags_entry(skb);
>
> ret = napi_frags_finish(napi, skb, dev_gro_receive(napi, skb));
This change (noted from your other patches is fine), and a likely
improvement, thanks for sending those!
WARNING: multiple messages have this Message-ID (diff)
From: Jesse Brandeburg <jesse.brandeburg@intel.com>
To: Eric Dumazet <edumazet@google.com>
Cc: netdev <netdev@vger.kernel.org>,
intel-wired-lan@lists.osuosl.org,
Jamal Hadi Salim <jhs@mojatatu.com>
Subject: Re: [PATCH net-next v1 1/2] net: core: count drops from GRO
Date: Fri, 8 Jan 2021 10:35:37 -0800 [thread overview]
Message-ID: <20210108103537.00005168@intel.com> (raw)
In-Reply-To: <CANn89iLcRrmXW_MGjuMMnNxWS+kaEnY=Y79hCPuiwiDd_G9=EA@mail.gmail.com>
Eric Dumazet wrote:
> > --- a/net/core/dev.c
> > +++ b/net/core/dev.c
> > @@ -6071,6 +6071,7 @@ static gro_result_t napi_skb_finish(struct napi_struct *napi,
> > break;
> >
> > case GRO_DROP:
> > + atomic_long_inc(&skb->dev->rx_dropped);
> > kfree_skb(skb);
> > break;
> >
> > @@ -6159,6 +6160,7 @@ static gro_result_t napi_frags_finish(struct napi_struct *napi,
> > break;
> >
> > case GRO_DROP:
> > + atomic_long_inc(&skb->dev->rx_dropped);
> > napi_reuse_skb(napi, skb);
> > break;
> >
>
>
> This is not needed. I think we should clean up ice instead.
My patch 2 already did that. I was trying to address the fact that I'm
*actually seeing* GRO_DROP return codes coming back from stack.
I'll try to reproduce that issue again that I saw. Maybe modern kernels
don't have the problem as frequently or at all.
> Drivers are supposed to have allocated the skb (using
> napi_get_frags()) before calling napi_gro_frags()
ice doesn't use napi_get_frags/napi_gro_frags, so I'm not sure how this
is relevant.
> Only napi_gro_frags() would return GRO_DROP, but we supposedly could
> crash at that point, since a driver is clearly buggy.
seems unlikely since we don't call those functions.
> We probably can remove GRO_DROP completely, assuming lazy drivers are fixed.
This might be ok, but doesn't explain why I was seeing this return
code (which was the whole reason I was trying to count them), however I
may have been running on a distro kernel from redhat/centos 8 when I
was seeing these events. I haven't fully completed spelunking all the
different sources, but might be able to follow down the rabbit hole
further.
> diff --git a/net/core/dev.c b/net/core/dev.c
> index 8fa739259041aaa03585b5a7b8ebce862f4b7d1d..c9460c9597f1de51957fdcfc7a64ca45bce5af7c
> 100644
> --- a/net/core/dev.c
> +++ b/net/core/dev.c
> @@ -6223,9 +6223,6 @@ gro_result_t napi_gro_frags(struct napi_struct *napi)
> gro_result_t ret;
> struct sk_buff *skb = napi_frags_skb(napi);
>
> - if (!skb)
> - return GRO_DROP;
> -
> trace_napi_gro_frags_entry(skb);
>
> ret = napi_frags_finish(napi, skb, dev_gro_receive(napi, skb));
This change (noted from your other patches is fine), and a likely
improvement, thanks for sending those!
next prev parent reply other threads:[~2021-01-08 18:35 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-06 21:55 [Intel-wired-lan] [PATCH net-next v1 0/2] GRO drop accounting Jesse Brandeburg
2021-01-06 21:55 ` Jesse Brandeburg
2021-01-06 21:55 ` [Intel-wired-lan] [PATCH net-next v1 1/2] net: core: count drops from GRO Jesse Brandeburg
2021-01-06 21:55 ` Jesse Brandeburg
2021-01-07 18:47 ` [Intel-wired-lan] " Jacob Keller
2021-01-07 21:15 ` Alexander Duyck
2021-01-08 18:23 ` Jesse Brandeburg
2021-01-08 0:50 ` Shannon Nelson
2021-01-08 0:50 ` Shannon Nelson
2021-01-08 18:26 ` [Intel-wired-lan] " Jesse Brandeburg
2021-01-08 18:26 ` Jesse Brandeburg
2021-01-08 19:21 ` [Intel-wired-lan] " Shannon Nelson
2021-01-08 19:21 ` Shannon Nelson
2021-01-08 20:26 ` [Intel-wired-lan] " Saeed Mahameed
2021-01-08 20:26 ` Saeed Mahameed
2021-01-08 22:17 ` [Intel-wired-lan] " Eric Dumazet
2021-01-08 22:17 ` Eric Dumazet
2021-01-14 13:53 ` [Intel-wired-lan] " Jamal Hadi Salim
2021-01-14 13:53 ` Jamal Hadi Salim
2021-01-08 9:25 ` [Intel-wired-lan] " Eric Dumazet
2021-01-08 9:25 ` Eric Dumazet
2021-01-08 18:35 ` Jesse Brandeburg [this message]
2021-01-08 18:35 ` Jesse Brandeburg
2021-01-08 18:45 ` [Intel-wired-lan] " Eric Dumazet
2021-01-08 18:45 ` Eric Dumazet
2021-01-09 0:54 ` [Intel-wired-lan] " Jacob Keller
2021-01-06 21:55 ` [Intel-wired-lan] [PATCH net-next v1 2/2] ice: remove GRO drop accounting Jesse Brandeburg
2021-01-06 21:55 ` Jesse Brandeburg
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=20210108103537.00005168@intel.com \
--to=jesse.brandeburg@intel.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.