From owner-freebsd-net Fri Oct 26 11:51: 8 2001 Delivered-To: freebsd-net@freebsd.org Received: from technokratis.com (modemcable093.62-201-24.mtl.mc.videotron.ca [24.201.62.93]) by hub.freebsd.org (Postfix) with ESMTP id 369C937B412 for ; Fri, 26 Oct 2001 11:50:43 -0700 (PDT) Received: (from bmilekic@localhost) by technokratis.com (8.11.4/8.11.3) id f9QIp1p22744; Fri, 26 Oct 2001 14:51:01 -0400 (EDT) (envelope-from bmilekic) Date: Fri, 26 Oct 2001 14:51:01 -0400 From: Bosko Milekic To: "Keiichi SHIMA / ?$BEg7D0l?(B" Cc: David Malone , Luigi Rizzo , Alfred Perlstein , net@FreeBSD.ORG Subject: Re: performance issues with M_PREPEND on clusters Message-ID: <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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <867ktiw8vf.wl@keiichi01.osaka.iij.ad.jp>; from keiichi@iij.ad.jp on Sat, Oct 27, 2001 at 03:31:48AM +0900 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 On Sat, Oct 27, 2001 at 03:31:48AM +0900, Keiichi SHIMA / ?$BEg7D0l?(B 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. 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. > So, I would suggest that we should not change M_LEADINGSPACE behavior, > and write some documents (or comment in the source may be enough) > about that. Because one of the reasons of the confusion of > M_LEADINGSPACE is there were no documentation about that, we had only > the code and the code said that it returns a writable length. > > (if necessary) we should create a new API to get the real(?) space as > David have proposed. > > Best regards, > > --- > Keiichi SHIMA > IIJ Research Laboratory > KAME Project -- Bosko Milekic bmilekic@technokratis.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message