Date: Mon, 30 Mar 2015 17:23:48 +0200 (CEST) From: Emeric POUPON <emeric.poupon@stormshield.eu> To: Slawa Olhovchenkov <slw@zxy.spb.ru> 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, Gleb Smirnoff <glebius@FreeBSD.org>, svn-src-head@freebsd.org, Fabien Thomas <fabient@freebsd.org> Subject: Re: svn commit: r280759 - head/sys/netinet Message-ID: <1872802434.26738716.1427729028579.JavaMail.zimbra@stormshield.eu> In-Reply-To: <20150330141616.GC74532@zxy.spb.ru> References: <20150329210757.GA64665@FreeBSD.org> <551933AF.4080300@selasky.org> <20150330120700.GH64665@FreeBSD.org> <551943B4.90102@selasky.org> <20150330125115.GI64665@FreeBSD.org> <551948A4.1070408@selasky.org> <5519535C.40608@selasky.org> <20150330141616.GC74532@zxy.spb.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
Hello, Sorry for late response, I didn't notice this issue was discussed here. In one of our tests, we have several (up to 12) cpu that emit packets with = the same src, dst and protocol to a remote host. We did this patch since we observed bad packet reassembly on the remote hos= t, due to different fragments emitted with the same ip id. It was an IPsec test (emitting ESP packets) but I guess we could easily rep= roduce this problem using several "ping -i 0 -s BIG_SIZE_HERE DST" commands= running in parallel. Even if we reached something like 1M pps, it is likely that we did not see = any performance penalty since the IPsec stack is quite time consuming. Now, the question is: is there a real performance issue here or is it likel= y to be hidden by other problems? If it is a real problem, maybe an acceptable tradeoff would be to make the = counter per CPU and: - initialize it with the cpu id, - increment it by the number of cpus. What do you think? Best Regards, Emeric ----- Mail original ----- De: "Slawa Olhovchenkov" <slw@zxy.spb.ru> =C3=80: "Hans Petter Selasky" <hps@selasky.org> Cc: "Adrian Chadd" <adrian@freebsd.org>, src-committers@freebsd.org, "Ian L= epore" <ian@freebsd.org>, svn-src-all@freebsd.org, "Gleb Smirnoff" <glebius= @FreeBSD.org>, svn-src-head@freebsd.org, "Fabien Thomas" <fabient@freebsd.o= rg> Envoy=C3=A9: Lundi 30 Mars 2015 16:16:17 Objet: Re: svn commit: r280759 - head/sys/netinet On Mon, Mar 30, 2015 at 03:45:00PM +0200, Hans Petter Selasky wrote: > Gleb, >=20 > On 03/30/15 14:59, Hans Petter Selasky wrote: > > On 03/30/15 14:51, Gleb Smirnoff wrote: > >> Hans, > >> > > > > Gleb: Can you answer my question first: > > > > Should the 16-bit IP ID field carry any useful information or not? > > >=20 > > Yes: > > > > An identifying value assigned by the sender to aid in assembling th= e > > fragments of a datagram. >=20 > The numbering should be somewhat sane and when you are suggesting that a= =20 > multi-line function and cache line issues will hit the system hard,=20 > which I don't doubt, functions like "unrhdr()" are probably out of the=20 > question? >=20 > >> Let me ask again: are you serious? Do you suggest to delay transmittin= g > >> network packets with a DELAY()? >=20 > Yes! It doesn't have to be done by the software. It can be done by the=20 > ethernet hardware too! >=20 > >> > >> H> Or maybe we can add an IPv4 option to escape a 32-bit IP ID field a= nd > >> H> don't use the 16-bit IP ID field. > >> > >> Is that also serious? Do you suggest to change layout of IP packet? > >> >=20 > IPv4 packets can carry additional options which is part of the standard= =20 > IPv4 packet layout, though routers which perform fragmentation would=20 > need to support it ... >=20 >=20 > Does this discussion mean that IPv4 traffic which is subject to=20 > fragmentation has a transmission rate limit depending on the roundtrip=20 > time to avoid risking bad defragmentation issues? You can't be know about needing fragmenatation. Fragmentation occur on remote transit routers, w/o information packet source. Any packet (w/o DF) can be fragmented. In some cases pakets one flow can be dispatched by different path and fragmented only on the one path. _______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1872802434.26738716.1427729028579.JavaMail.zimbra>