netdev - RE: Question about ip

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4F88C5DDA1E80143B232E89585ACE27D018F507F@DGGEMA502-MBX.china.huawei.com>
Date:   Wed, 30 Aug 2017 01:52:34 +0000
From:   "liujian (CE)" <liujian56@...wei.com>
To:     Florian Westphal <fw@...len.de>
CC:     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




Best Regards,
liujian


> -----Original Message-----
> From: netdev-owner@...r.kernel.org [mailto:netdev-owner@...r.kernel.org]
> On Behalf Of Florian Westphal
> Sent: Tuesday, August 29, 2017 9:47 PM
> To: liujian (CE)
> Cc: Florian Westphal; Jesper Dangaard Brouer; netdev@...r.kernel.org;
> Wangkefeng (Kevin); weiyongjun (A)
> 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.

Ok. 
Florian and Jesper, many thanks for this issue.