Date: Mon, 30 Mar 2015 18:20:45 +0200 (CEST) From: Emeric POUPON <emeric.poupon@stormshield.eu> To: Gleb Smirnoff <glebius@FreeBSD.org> Cc: Hans Petter Selasky <hps@selasky.org>, Adrian Chadd <adrian@freebsd.org>, src-committers@freebsd.org, Ian Lepore <ian@freebsd.org>, svn-src-all@freebsd.org, Slawa Olhovchenkov <slw@zxy.spb.ru>, svn-src-head@freebsd.org, Fabien Thomas <fabient@freebsd.org> Subject: Re: svn commit: r280759 - head/sys/netinet Message-ID: <964618150.26750606.1427732445799.JavaMail.zimbra@stormshield.eu> In-Reply-To: <20150330152707.GP64665@FreeBSD.org> References: <20150329210757.GA64665@FreeBSD.org> <551943B4.90102@selasky.org> <20150330125115.GI64665@FreeBSD.org> <551948A4.1070408@selasky.org> <5519535C.40608@selasky.org> <20150330141616.GC74532@zxy.spb.ru> <1872802434.26738716.1427729028579.JavaMail.zimbra@stormshield.eu> <20150330152707.GP64665@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Yes, sure! I will test it tomorrow and tell you the results. However, keep in mind I did not see any performance impact with the previou= s patch. Regards, ----- Mail original ----- De: "Gleb Smirnoff" <glebius@FreeBSD.org> =C3=80: "Emeric POUPON" <emeric.poupon@stormshield.eu> Cc: "Slawa Olhovchenkov" <slw@zxy.spb.ru>, "Hans Petter Selasky" <hps@selas= ky.org>, "Adrian Chadd" <adrian@freebsd.org>, src-committers@freebsd.org, "= Ian Lepore" <ian@freebsd.org>, svn-src-all@freebsd.org, svn-src-head@freebs= d.org, "Fabien Thomas" <fabient@freebsd.org> Envoy=C3=A9: Lundi 30 Mars 2015 17:27:07 Objet: Re: svn commit: r280759 - head/sys/netinet On Mon, Mar 30, 2015 at 05:23:48PM +0200, Emeric POUPON wrote: E> Hello, E>=20 E> Sorry for late response, I didn't notice this issue was discussed here. E>=20 E> In one of our tests, we have several (up to 12) cpu that emit packets wi= th the same src, dst and protocol to a remote host. E> We did this patch since we observed bad packet reassembly on the remote = host, due to different fragments emitted with the same ip id. E> It was an IPsec test (emitting ESP packets) but I guess we could easily = reproduce this problem using several "ping -i 0 -s BIG_SIZE_HERE DST" comma= nds running in parallel. E>=20 E> Even if we reached something like 1M pps, it is likely that we did not s= ee any performance penalty since the IPsec stack is quite time consuming. E> Now, the question is: is there a real performance issue here or is it li= kely to be hidden by other problems? E>=20 E> If it is a real problem, maybe an acceptable tradeoff would be to make t= he counter per CPU and: E> - initialize it with the cpu id, E> - increment it by the number of cpus. E>=20 E> What do you think? I already posted a patch that makes the counter per CPU. Can you please tes= t it? --=20 Totus tuus, Glebius.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?964618150.26750606.1427732445799.JavaMail.zimbra>