From owner-svn-src-head@FreeBSD.ORG Mon Mar 30 14:16:20 2015 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 65C13D3F; Mon, 30 Mar 2015 14:16:20 +0000 (UTC) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 16CCC892; Mon, 30 Mar 2015 14:16:20 +0000 (UTC) Received: from slw by zxy.spb.ru with local (Exim 4.84 (FreeBSD)) (envelope-from ) id 1YcaUD-000Nrq-2v; Mon, 30 Mar 2015 17:16:17 +0300 Date: Mon, 30 Mar 2015 17:16:17 +0300 From: Slawa Olhovchenkov To: Hans Petter Selasky Subject: Re: svn commit: r280759 - head/sys/netinet Message-ID: <20150330141616.GC74532@zxy.spb.ru> References: <20150329210757.GA64665@FreeBSD.org> <1427666182.82583.4.camel@freebsd.org> <55190EA7.9010905@selasky.org> <20150330105913.GF64665@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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5519535C.40608@selasky.org> User-Agent: Mutt/1.5.23 (2014-03-12) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false Cc: 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-head@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2015 14:16:20 -0000 On Mon, Mar 30, 2015 at 03:45:00PM +0200, Hans Petter Selasky wrote: > Gleb, > > 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? > > > > > Yes: > > > > An identifying value assigned by the sender to aid in assembling the > > fragments of a datagram. > > The numbering should be somewhat sane and when you are suggesting that a > multi-line function and cache line issues will hit the system hard, > which I don't doubt, functions like "unrhdr()" are probably out of the > question? > > >> Let me ask again: are you serious? Do you suggest to delay transmitting > >> network packets with a DELAY()? > > Yes! It doesn't have to be done by the software. It can be done by the > ethernet hardware too! > > >> > >> H> Or maybe we can add an IPv4 option to escape a 32-bit IP ID field and > >> H> don't use the 16-bit IP ID field. > >> > >> Is that also serious? Do you suggest to change layout of IP packet? > >> > > IPv4 packets can carry additional options which is part of the standard > IPv4 packet layout, though routers which perform fragmentation would > need to support it ... > > > Does this discussion mean that IPv4 traffic which is subject to > fragmentation has a transmission rate limit depending on the roundtrip > 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.