From owner-cvs-all@FreeBSD.ORG Sun Aug 31 23:02:48 2003 Return-Path: Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9544916A4C1 for ; Sun, 31 Aug 2003 23:02:48 -0700 (PDT) Received: from relay.pair.com (relay.pair.com [209.68.1.20]) by mx1.FreeBSD.org (Postfix) with SMTP id 982AD43FDD for ; Sun, 31 Aug 2003 23:02:46 -0700 (PDT) (envelope-from silby@silby.com) Received: (qmail 87290 invoked from network); 1 Sep 2003 06:02:45 -0000 Received: from niwun.pair.com (HELO localhost) (209.68.2.70) by relay.pair.com with SMTP; 1 Sep 2003 06:02:45 -0000 X-pair-Authenticated: 209.68.2.70 Date: Mon, 1 Sep 2003 01:01:42 -0500 (CDT) From: Mike Silbersack To: src-committers@FreeBSD.org In-Reply-To: <200309010555.h815tbYK021677@repoman.freebsd.org> Message-ID: <20030901005712.X667@odysseus.silby.com> References: <200309010555.h815tbYK021677@repoman.freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: cvs-src@FreeBSD.org cc: cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/kern uipc_mbuf.c src/sys/netinetip_output.c src/sys/sys mbuf.h X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Sep 2003 06:02:48 -0000 On Sun, 31 Aug 2003, Mike Silbersack wrote: > - Fragmentation is handled by the function m_fragment, which can > be called from whereever fragmentation is needed. Note that this > function is wrapped in #ifdef MBUF_STRESS_TEST to discourage non-testing > use. Note that I #ifdef'd the function, but I left the definition in mbuf.h without any #ifdefs around it, because that seemed evil. If there's a more correct way of handling this, please tell me. > - Add two modes of random fragmentation. Chains with fragments all of > the same random length and chains with fragments that are each uniquely > random in length may now be requested. While testing this feature, I came to the conclusion that arc4random must be somewhat statistically random, as I was using arc4random & 255, and chain lengths seemed to be coming up about 11 frags in length. (256 / 2) = 128 * 11 = 1408, which is pretty close to the length of an ethernet packet. Not very scientific, but interesting. (I was watching via a ppsratelimited check on the chainlength, and didn't write down exact results either, so it's actually totally unscientific.) Mike "Silby" Silbersack