From owner-svn-src-all@FreeBSD.ORG Mon Mar 30 15:23:59 2015 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0E13518F; Mon, 30 Mar 2015 15:23:59 +0000 (UTC) Received: from work.netasq.com (gwlille.netasq.com [91.212.116.1]) by mx1.freebsd.org (Postfix) with ESMTP id 988F311E; Mon, 30 Mar 2015 15:23:57 +0000 (UTC) Received: from work.netasq.com (localhost.localdomain [127.0.0.1]) by work.netasq.com (Postfix) with ESMTP id F139B2700929; Mon, 30 Mar 2015 17:23:49 +0200 (CEST) Received: from localhost (localhost.localdomain [127.0.0.1]) by work.netasq.com (Postfix) with ESMTP id 5523C27004B1; Mon, 30 Mar 2015 17:23:49 +0200 (CEST) Received: from work.netasq.com ([127.0.0.1]) by localhost (work.netasq.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id w1aLpkld3k-Q; Mon, 30 Mar 2015 17:23:49 +0200 (CEST) Received: from work.netasq.com (localhost.localdomain [127.0.0.1]) by work.netasq.com (Postfix) with ESMTP id 065E627004A5; Mon, 30 Mar 2015 17:23:49 +0200 (CEST) Date: Mon, 30 Mar 2015 17:23:48 +0200 (CEST) From: Emeric POUPON To: Slawa Olhovchenkov 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> Subject: Re: svn commit: r280759 - head/sys/netinet MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Thread-Topic: svn commit: r280759 - head/sys/netinet Thread-Index: 05++eDCQkPV3URQ/eksJGTUrk2oqHQ== Cc: Hans Petter Selasky , Adrian Chadd , src-committers@freebsd.org, Ian Lepore , svn-src-all@freebsd.org, Gleb Smirnoff , svn-src-head@freebsd.org, Fabien Thomas X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2015 15:23:59 -0000 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" =C3=80: "Hans Petter Selasky" Cc: "Adrian Chadd" , src-committers@freebsd.org, "Ian L= epore" , svn-src-all@freebsd.org, "Gleb Smirnoff" , svn-src-head@freebsd.org, "Fabien Thomas" 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"