From owner-freebsd-net Fri Oct 26 4:48:19 2001 Delivered-To: freebsd-net@freebsd.org Received: from neogw.osaka.iij.ad.jp (neogw.osaka.iij.ad.jp [202.232.14.130]) by hub.freebsd.org (Postfix) with ESMTP id 2828B37B405 for ; Fri, 26 Oct 2001 04:48:16 -0700 (PDT) Received: by neogw.osaka.iij.ad.jp; id UAA18160; Fri, 26 Oct 2001 20:48:10 +0900 (JST) Received: from keiichi01.osaka.iij.ad.jp(192.168.65.66) by neogw.osaka.iij.ad.jp via smap (V4.2) id xma018150; Fri, 26 Oct 01 20:47:45 +0900 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 f9QBlR427830; Fri, 26 Oct 2001 20:47:32 +0900 (JST) (envelope-from keiichi@iij.ad.jp) Date: Fri, 26 Oct 2001 20:47:27 +0900 Message-ID: <86u1wmlj1s.wl@keiichi01.osaka.iij.ad.jp> From: Keiichi SHIMA / =?ISO-2022-JP?B?GyRCRWc3RDBsGyhC?= To: Bosko Milekic , David Malone , Luigi Rizzo , Alfred Perlstein , net@FreeBSD.ORG Subject: Re: performance issues with M_PREPEND on clusters In-Reply-To: <20011026110635.B14635@walton.maths.tcd.ie> 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> 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, I am one of the KAME members. > The only problem I can see with this tack is that we might end up > with M_LEADINGSPACE macro which does something different to the > same macro in {Net,Open}BSD. I guess we should check what their > macros do at the moment. Right. And we will have a problem if someone changes the semantics of M_LEADINGSPACE. The M_LEADINGSPACE macro of Net/OpenBSD does the same as the current FreeBSD does, that is, returns 0 if M_EXT is set. > When I looked at this question last year I think I found that there > were few enough places in the kernel which used M_LEADINGSPACE, so > it should be fairly easy to check them. However, I think several > of the uses were in KAME code. The patch posted first by Luigi is safe because the patch doesn't change any semantics of M_LEADINGSPACE. I think it (and the patch) reasonbale that M_LEADINGSPACE returns 0 when the mbuf (cluster) is not writable and the real space when the mbuf (cluster) is writable. But, I disagree the later proposal from Bosko that changes the meaning of M_LEADINGSPACE. This leads more ifdefs in the shared code (ex. KAME, maybe other cross-platform projects) and the code complexity. --- 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