Date: Mon, 30 Mar 2015 17:16:17 +0300 From: Slawa Olhovchenkov <slw@zxy.spb.ru> To: Hans Petter Selasky <hps@selasky.org> Cc: Adrian Chadd <adrian@freebsd.org>, "src-committers@freebsd.org" <src-committers@freebsd.org>, Ian Lepore <ian@freebsd.org>, "svn-src-all@freebsd.org" <svn-src-all@freebsd.org>, Gleb Smirnoff <glebius@FreeBSD.org>, "svn-src-head@freebsd.org" <svn-src-head@freebsd.org>, Fabien Thomas <fabient@freebsd.org> Subject: Re: svn commit: r280759 - head/sys/netinet Message-ID: <20150330141616.GC74532@zxy.spb.ru> In-Reply-To: <5519535C.40608@selasky.org> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20150330141616.GC74532>