From owner-svn-src-all@FreeBSD.ORG Mon Mar 30 13:44:16 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 9A4E7589; Mon, 30 Mar 2015 13:44:16 +0000 (UTC) Received: from mail.turbocat.net (mail.turbocat.net [IPv6:2a01:4f8:d16:4514::2]) (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 50DB8215; Mon, 30 Mar 2015 13:44:16 +0000 (UTC) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id C8AD61FE023; Mon, 30 Mar 2015 15:44:13 +0200 (CEST) Message-ID: <5519535C.40608@selasky.org> Date: Mon, 30 Mar 2015 15:45:00 +0200 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Gleb Smirnoff Subject: Re: svn commit: r280759 - head/sys/netinet References: <20150328191629.GY64665@FreeBSD.org> <5517B433.5010508@selasky.org> <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> In-Reply-To: <551948A4.1070408@selasky.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: Adrian Chadd , "src-committers@freebsd.org" , Ian Lepore , "svn-src-all@freebsd.org" , "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 13:44:16 -0000 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? --HPS