From owner-freebsd-net Fri Oct 26 11:32:42 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 2B56437B407 for ; Fri, 26 Oct 2001 11:32:35 -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 f9QIVmK01135; Sat, 27 Oct 2001 03:31:58 +0900 (JST) (envelope-from keiichi@iij.ad.jp) Date: Sat, 27 Oct 2001 03:31:48 +0900 Message-ID: <867ktiw8vf.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: <20011026121724.A21512@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> 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: > > Just because M_LEADINGSPACE may be broken in the other systems does > not mean that it should be broken in our system as well. I am against > sacrificying good code in order to deal with the left-over stupidities > (pardon the seemingly harsh vocabulary) in the other systems, when it > comes to porting. I agree with you at the point that the good code should be accepted. With Luigi's patch, we will get more performance than before. It makes us possible to use the leading space (they were unusable before the patch) to prepend some lower-layer packet headers with no changes of existing code. > You should understand that M_LEADINGSPACE was meant to return the > number of leading bytes in the underlying data buffer and that it was > only broken when someone decided to half-implement ext bufs. This > brokeness happened to live on in present-day systems and unbreaking it > should not be put on hold for the sake of pseudo-compatibility, IMHO. 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. 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 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message