netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jesper Dangaard Brouer <brouer@redhat.com>
To: Alexander Duyck <alexander.duyck@gmail.com>
Cc: Netdev <netdev@vger.kernel.org>,
	"David S. Miller" <davem@davemloft.net>,
	Saeed Mahameed <saeedm@mellanox.com>,
	Or Gerlitz <gerlitz.or@gmail.com>,
	Eugenia Emantayev <eugenia@mellanox.com>,
	brouer@redhat.com
Subject: Re: [net-next PATCH V1 3/3] net: warn on napi_alloc_skb being called in wrong context
Date: Mon, 9 May 2016 22:03:17 +0200	[thread overview]
Message-ID: <20160509220317.3d5eadd5@redhat.com> (raw)
In-Reply-To: <CAKgT0UcJyxDvY+r6qsXSCQ4SjE2VH4NPGOrG9F7Ame50cQQpKA@mail.gmail.com>

On Mon, 9 May 2016 09:33:25 -0700
Alexander Duyck <alexander.duyck@gmail.com> wrote:

> On Mon, May 9, 2016 at 6:44 AM, Jesper Dangaard Brouer
> <brouer@redhat.com> wrote:
> > It have always been required to call napi_alloc_skb from NAPI/softirq
> > context, which implies running with local_bh_disable'ed.  Thus, this
> > code path should already be well tested. But recent SKB bulk changes
> > introduced will make this more volatile and bugs more subtle, if this
> > is violated.  
> 
> It hasn't been required to be in the softirq routine, bottom halves
> could have been disabled.  I used the NAPI parameter to try and
> enforce a strong correlation between the two but I didn't make it a
> hard requirement.  It isn't until you try to do the recycling that it
> becomes more of a requirement because then it is tied into the bulk
> free.
> 
> The bulk free routine had a stronger requirement for NAPI because it
> needed to have the __kfree_skb_flush routine called to finally free
> the skbuffs that were still hanging off the percpu skbuff structure.
> 
> > To catch any driver violating this add a loud WARN_ON.
> >
> > Performance wise, I do worry about adding this runtime check code into
> > the hotpath, of this highly optimized function call.  I've
> > micro-benchmarked it with both IP-forwarding and local UDP delivery,
> > and didn't see any regressions.  It does adds extra code size (icache).
> >
> > add/remove: 0/0 grow/shrink: 1/0 up/down: 43/0 (43)
> > function                                     old     new   delta
> > __napi_alloc_skb                             461     504     +43
> >
> > Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
> > ---
> >  net/core/skbuff.c |    3 +++
> >  1 file changed, 3 insertions(+)
> >
> > diff --git a/net/core/skbuff.c b/net/core/skbuff.c
> > index e85f1065b263..99addbf66f2e 100644
> > --- a/net/core/skbuff.c
> > +++ b/net/core/skbuff.c
> > @@ -498,6 +498,9 @@ struct sk_buff *__napi_alloc_skb(struct napi_struct *napi, unsigned int len,
> >         struct sk_buff *skb;
> >         void *data;
> >
> > +       /* Catch drivers violating, not having local BH disabled */
> > +       WARN_ON(!in_softirq());
> > +  
> 
> I'm pretty sure this still lets you get away with just disabling
> bottom halves.  I think what you would want is in_serving_softirq().

No, we want to allow this being call with just disabled bottom halves.
Thus, we have to use in_softirq() and not in_serving_softirq().


> >         len += NET_SKB_PAD + NET_IP_ALIGN;
> >
> >         if (unlikely((len > SKB_WITH_OVERHEAD(PAGE_SIZE)) ||
> >  



-- 
Best regards,
  Jesper Dangaard Brouer
  MSc.CS, Principal Kernel Engineer at Red Hat
  Author of http://www.iptv-analyzer.org
  LinkedIn: http://www.linkedin.com/in/brouer

  reply	other threads:[~2016-05-09 20:03 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-09 13:44 [net-next PATCH V1 0/3] net: enable use of kmem_cache_alloc_bulk in network stack Jesper Dangaard Brouer
2016-05-09 13:44 ` [net-next PATCH V1 1/3] net: bulk alloc and reuse of SKBs in NAPI context Jesper Dangaard Brouer
2016-05-09 16:20   ` Alexander Duyck
2016-05-09 19:59     ` Jesper Dangaard Brouer
2016-05-09 20:46       ` Alexander Duyck
2016-05-10  9:29         ` Jesper Dangaard Brouer
2016-05-10 12:30         ` Jesper Dangaard Brouer
2016-05-10 13:48           ` Eric Dumazet
2016-05-10 14:48             ` Jesper Dangaard Brouer
2016-05-10 15:44               ` Eric Dumazet
2016-05-10 17:46           ` Alexander Duyck
2016-05-09 13:44 ` [net-next PATCH V1 2/3] mlx4: use napi_alloc_skb API to get SKB bulk allocations Jesper Dangaard Brouer
2016-05-09 16:47   ` Alexander Duyck
2016-05-09 20:05     ` Jesper Dangaard Brouer
2016-05-09 13:44 ` [net-next PATCH V1 3/3] net: warn on napi_alloc_skb being called in wrong context Jesper Dangaard Brouer
2016-05-09 13:53   ` Sergei Shtylyov
2016-05-09 13:53   ` Sergei Shtylyov
2016-05-09 16:33   ` Alexander Duyck
2016-05-09 20:03     ` Jesper Dangaard Brouer [this message]
2016-05-20  8:14 ` [net-next PATCH V1 0/3] net: enable use of kmem_cache_alloc_bulk in network stack Jesper Dangaard Brouer

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=20160509220317.3d5eadd5@redhat.com \
    --to=brouer@redhat.com \
    --cc=alexander.duyck@gmail.com \
    --cc=davem@davemloft.net \
    --cc=eugenia@mellanox.com \
    --cc=gerlitz.or@gmail.com \
    --cc=netdev@vger.kernel.org \
    --cc=saeedm@mellanox.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).