From owner-freebsd-net Fri Oct 26 12: 9:57 2001 Delivered-To: freebsd-net@freebsd.org Received: from keiichi01.osaka.iij.ad.jp (g034172.ap.plala.or.jp [210.136.34.172]) by hub.freebsd.org (Postfix) with ESMTP id 2803D37B401 for ; Fri, 26 Oct 2001 12:09:52 -0700 (PDT) Received: from keiichi01.osaka.iij.ad.jp (localhost.osaka.iij.ad.jp [127.0.0.1]) by keiichi01.osaka.iij.ad.jp (8.11.6/8.11.6) with ESMTP id f9QJ9ZK01332; Sat, 27 Oct 2001 04:09:36 +0900 (JST) (envelope-from keiichi@iij.ad.jp) Date: Sat, 27 Oct 2001 04:09:12 +0900 Message-ID: <86lmhykylj.wl@keiichi01.osaka.iij.ad.jp> From: Keiichi SHIMA / =?ISO-2022-JP?B?GyRCRWc3RDBsGyhC?= To: Bosko Milekic Cc: David Malone , Luigi Rizzo , Alfred Perlstein , net@FreeBSD.ORG Subject: Re: performance issues with M_PREPEND on clusters In-Reply-To: <20011026145101.A22681@technokratis.com> References: <20011023110307.A34494@iguana.aciri.org> <20011023132813.I15052@elvis.mu.org> <20011023114650.C34494@iguana.aciri.org> <20011023140034.M15052@elvis.mu.org> <20011023140628.A36095@iguana.aciri.org> <20011023185759.A328@technokratis.com> <20011026110635.B14635@walton.maths.tcd.ie> <86u1wmlj1s.wl@keiichi01.osaka.iij.ad.jp> <20011026121724.A21512@technokratis.com> <867ktiw8vf.wl@keiichi01.osaka.iij.ad.jp> <20011026145101.A22681@technokratis.com> User-Agent: Wanderlust/2.6.0 (Twist And Shout) SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-1?Q?Unebigory=F2mae?=) APEL/10.2 MULE XEmacs/21.1 (patch 14) (Cuyahoga Valley) (i386--freebsd) Organization: Internet Initiative Japan Inc. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi Bosko, Bosko Milekic wrote: > > > M_LEADINGSPACE might be meant to return as you were saying. But > > because of some reasons (maybe a lack of time to implement the > > complete code), it behaves as we see now. For a long time, in many > > systems, M_LEADINGSPACE had been returning writable space only. As a > > result, some codes (including KAME) rely on the behavior. > > This is not true. M_LEADINGSPACE has not been returning writable space > only for a long time; it has been returning space in non-M_EXT mbufs for > a long time. Ah, I'm sorry, I was wrong. As you said, M_LEADINGSPACE returns 0 even if there are writable space before the data part of the mbuf cluster. Please note that I'm not saying you are wrong (maybe you are correct in theory). But there is a code (not only our code but others maybe..) relys on the current behaviour. Changing M_LEADINGSPACE return the writable space will not introduce any compatibility issues, while changing M_LEA... return the exact (writable or readonly) space will cause compatibility issue. I'm worring about that... > So, doing what you want to do *is* changing its behavior, > whether you like it or not. I don't know how many times I have to repeat > this until someone starts to get it. The issue is not whether or not > you're changing the behavior of M_LEADINGSPACE because Luigi's > suggestion obviously does. The issue is how to do it properly and the > way it's being proposed right now is not the proper way. > As it turns out, I'm really not up for extending this debate any > longer. I'm not going to kill myself because something like this is > being done wrongly, seeing as how I'm the only one arguing this side > (according to the response hits, it appears I'm alone with this > opinion), although I will maintain that I believe it is wrong, and for > good reason, but I may end up eventually beating myself up if I have to > repeat the same thing over and over again in the same thread. --- Keiichi SHIMA IIJ Research Laboratory KAME Project To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message