From owner-cvs-all Tue Jun 12 12:54:49 2001 Delivered-To: cvs-all@freebsd.org Received: from peace.mahoroba.org (peace.calm.imasy.or.jp [202.227.26.34]) by hub.freebsd.org (Postfix) with ESMTP id 8E5EB37B401; Tue, 12 Jun 2001 12:54:41 -0700 (PDT) (envelope-from ume@mahoroba.org) Received: from localhost (IDENT:3ZYIzqA/+lXXW7hAeqhzHFpedKGClOJBoEd5zBD3Okl/xI89L/9DKW15nu7QoBfE@localhost [::1]) (authenticated as ume with CRAM-MD5) by peace.mahoroba.org (8.11.4/8.11.4/peace) with ESMTP/inet6 id f5CJsKq44319; Wed, 13 Jun 2001 04:54:20 +0900 (JST) (envelope-from ume@mahoroba.org) Date: Wed, 13 Jun 2001 04:54:16 +0900 (JST) Message-Id: <20010613.045416.125862267.ume@mahoroba.org> To: bmilekic@technokratis.com Cc: cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/netinet ip_output.c From: Hajimu UMEMOTO In-Reply-To: <20010611152724.A33314@technokratis.com> References: <200106111838.f5BIcCJ05392@freefall.freebsd.org> <20010611152724.A33314@technokratis.com> X-Mailer: xcite1.38> Mew version 1.95b119 on Emacs 20.7 / Mule 4.0 =?iso-2022-jp?B?KBskQjJWMWMbKEIp?= X-PGP-Public-Key: http://www.imasy.org/~ume/publickey.asc X-PGP-Fingerprint: 6B 0C 53 FC 5D D0 37 91 05 D0 B3 EF 36 9B 6A BC X-URL: http://www.imasy.org/~ume/ X-Operating-System: FreeBSD 5.0-CURRENT Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG >>>>> On Mon, 11 Jun 2001 15:27:24 -0400 >>>>> Bosko Milekic said: bmilekic> The commit to sys/sys/mbuf.h severely bloated the mbstat structure. bmilekic> Quads were added to apparently account for trivial things, such as `number bmilekic> of times pullup was done,' and so on. There are several problems with this. These quads were wrongly added during KAME merge. I nuked it already. Sorry for bothering you. bmilekic> Furthermore, the other change to sys/sys/mbuf.h and friends had to do bmilekic> with moving a check from m_free() to the more general MFREE() macro. The check bmilekic> itself bloats the macro (increasing the size of the kernel). Normally, I bmilekic> wouldn't object but from the surrounding comments it appears that it is possible bmilekic> to fix the problem _properly_. The comment claims that the check is there bmilekic> because there is still code that doesn't call M_PULLUP() properly. As opposed bmilekic> to bloating the allocation/free code with the bogus check, how difficult would bmilekic> it be to ensure that M_PULLUP() is called properly? Since KAME code is writtenin in this form, restoring check from MFREE() to m_free() may have risk. -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan ume@mahoroba.org ume@bisd.hitachi.co.jp ume@{,jp.}FreeBSD.org http://www.imasy.org/~ume/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message