All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jesper Dangaard Brouer <brouer@redhat.com>
To: "liujian (CE)" <liujian56@huawei.com>
Cc: "davem@davemloft.net" <davem@davemloft.net>,
	"kuznet@ms2.inr.ac.ru" <kuznet@ms2.inr.ac.ru>,
	"yoshfuji@linux-ipv6.org" <yoshfuji@linux-ipv6.org>,
	"elena.reshetova@intel.com" <elena.reshetova@intel.com>,
	"edumazet@google.com" <edumazet@google.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	brouer@redhat.com
Subject: Re: Question about ip_defrag
Date: Thu, 24 Aug 2017 20:59:26 +0200	[thread overview]
Message-ID: <20170824205926.2c45e3a1@redhat.com> (raw)
In-Reply-To: <4F88C5DDA1E80143B232E89585ACE27D018F0AE1@DGGEMA502-MBX.china.huawei.com>


On Thu, 24 Aug 2017 16:04:41 +0000 "liujian (CE)" <liujian56@huawei.com> wrote:

> >What kernel version have you seen this issue with?  
>
> 3.10,with some backport.
>
>  >As far as I remember, this issue have been fixed before...  
>
> which one patch? I didnot find out the patch:(

AFAIK it was some bugs in the percpu_counter code.  If you need to
backport look at the git commits:

 git log lib/percpu_counter.c include/linux/percpu_counter.h

Are you maintaining your own 3.10 kernel?

I know that for RHEL7 (also kernel 3.10) we backported the
percpu_counter fixes...

--Jesper


> 发件人: Jesper Dangaard Brouer
> 收件人: liujian (CE)<liujian56@huawei.com<mailto:liujian56@huawei.com>>
> 抄送: davem@davemloft.net<mailto:davem@davemloft.net>;kuznet@ms2.inr.ac.ru<mailto:kuznet@ms2.inr.ac.ru>;yoshfuji@linux-ipv6.org<mailto:yoshfuji@linux-ipv6.org>;elena.reshetova@intel.com<mailto:elena.reshetova@intel.com>;edumazet@google.com<mailto:edumazet@google.com>;netdev@vger.kernel.org<mailto:netdev@vger.kernel.org>;brouer@redhat.com<mailto:brouer@redhat.com>
> 主题: Re: Question about ip_defrag
> 时间: 2017-08-24 21:53:17
> 
> 
> On Thu, 24 Aug 2017 13:15:33 +0000 "liujian (CE)" <liujian56@huawei.com> wrote:
> > Hello,
> >
> > With below patch we met one issue.
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v4.13-rc6&id=6d7b857d541e
> >
> > the issue:
> > Ip_defrag fail caused by frag_mem_limit reached 4M(frags.high_thresh).
> > At this moment,sum_frag_mem_limit is about 10K.
> > and my test machine's cpu num is 64.
> >
> > Can i only change frag_mem_limit to sum_ frag_mem_limit?
> >
> >
> > diff --git a/net/ipv4/inet_fragment.c b/net/ipv4/inet_fragment.c
> > index 96e95e8..f09c00b 100644
> > --- a/net/ipv4/inet_fragment.c
> > +++ b/net/ipv4/inet_fragment.c
> > @@ -120,7 +120,7 @@ static void inet_frag_secret_rebuild(struct inet_frags *f)
> >  static bool inet_fragq_should_evict(const struct inet_frag_queue *q)
> >  {
> >         return q->net->low_thresh == 0 ||
> > -              frag_mem_limit(q->net) >= q->net->low_thresh;
> > +              sum_frag_mem_limit(q->net) >= q->net->low_thresh;
> >  }
> >
> >  static unsigned int
> > @@ -355,7 +355,7 @@ static struct inet_frag_queue *inet_frag_alloc(struct netns_frags *nf,
> >  {
> >         struct inet_frag_queue *q;
> >
> > -       if (!nf->high_thresh || frag_mem_limit(nf) > nf->high_thresh) {
> > +       if (!nf->high_thresh || sum_frag_mem_limit(nf) > nf->high_thresh) {
> >                 inet_frag_schedule_worker(f);
> >                 return NULL;
> >         }
> > @@ -396,7 +396,7 @@ struct inet_frag_queue *inet_frag_find(struct netns_frags *nf,
> >         struct inet_frag_queue *q;
> >         int depth = 0;
> >
> > -       if (frag_mem_limit(nf) > nf->low_thresh)
> > +       if (sum_frag_mem_limit(nf) > nf->low_thresh)
> >                 inet_frag_schedule_worker(f);
> >
> >         hash &= (INETFRAGS_HASHSZ - 1);
> > --
> >
> > Thank you for your time.  
> 
> What kernel version have you seen this issue with?
> 
> As far as I remember, this issue have been fixed before...
> 
> --
> Best regards,
>   Jesper Dangaard Brouer
>   MSc.CS, Principal Kernel Engineer at Red Hat
>   LinkedIn: http://www.linkedin.com/in/brouer



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

  parent reply	other threads:[~2017-08-24 18:59 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <4F88C5DDA1E80143B232E89585ACE27D018F07E2@DGGEMA502-MBX.china.huawei.com>
2017-08-24 13:53 ` Question about ip_defrag Jesper Dangaard Brouer
     [not found]   ` <4F88C5DDA1E80143B232E89585ACE27D018F0AE1@DGGEMA502-MBX.china.huawei.com>
2017-08-24 18:59     ` Jesper Dangaard Brouer [this message]
2017-08-25  1:33       ` liujian (CE)
2017-08-28  8:08       ` liujian (CE)
2017-08-28 14:00         ` Florian Westphal
2017-08-29  7:20           ` Jesper Dangaard Brouer
2017-08-29  7:44             ` liujian (CE)
2017-08-29  7:53             ` Florian Westphal
2017-08-30 10:58               ` Jesper Dangaard Brouer
2017-08-30 11:58                 ` Florian Westphal
2017-08-30 12:22                   ` Jesper Dangaard Brouer
2017-08-29  7:40           ` liujian (CE)
2017-08-29 13:01           ` liujian (CE)
2017-08-29 13:46             ` Florian Westphal
2017-08-30  1:52               ` liujian (CE)

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=20170824205926.2c45e3a1@redhat.com \
    --to=brouer@redhat.com \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=elena.reshetova@intel.com \
    --cc=kuznet@ms2.inr.ac.ru \
    --cc=liujian56@huawei.com \
    --cc=netdev@vger.kernel.org \
    --cc=yoshfuji@linux-ipv6.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.