[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170829134635.GB9993@breakpoint.cc>
Date: Tue, 29 Aug 2017 15:46:35 +0200
From: Florian Westphal <fw@...len.de>
To: "liujian (CE)" <liujian56@...wei.com>
Cc: Florian Westphal <fw@...len.de>,
Jesper Dangaard Brouer <brouer@...hat.com>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"Wangkefeng (Kevin)" <wangkefeng.wang@...wei.com>,
"weiyongjun (A)" <weiyongjun1@...wei.com>
Subject: Re: Question about ip_defrag
liujian (CE) <liujian56@...wei.com> wrote:
[ trimming cc list ]
> Now, I have not the real environment.
> I use iperf generate fragment packets;
> and I always change NIC rx irq's affinity cpu, to make sure frag_mem_limit reach to thresh.
> my test machine, CPU num is 384.
Oh well, that explains it.
> > > + if (frag_mem_limit(nf) > nf->low_thresh) {
> > > inet_frag_schedule_worker(f);
> > > + update_frag_mem_limit(nf, SKB_TRUESIZE(1500) * 16);
> > > + }
You need to reduce this to a lower value.
Your cpu count * batch_value needs to be less than
low_thresh to avoid problems.
Wtih 384 cpus its close to 12 mbyte...
Perhaps do this:
update_frag_mem_limit(nf, 2 * 1024*1024 / NR_CPUS);
However, I think its better to revert the percpu counter change and
move back to a single atomic_t count.
Powered by blists - more mailing lists