From owner-freebsd-net Fri Oct 26 9:17:51 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 E36A437B403 for ; Fri, 26 Oct 2001 09:17:42 -0700 (PDT) Received: (from bmilekic@localhost) by technokratis.com (8.11.4/8.11.3) id f9QGHSZ21540; Fri, 26 Oct 2001 12:17:28 -0400 (EDT) (envelope-from bmilekic) Date: Fri, 26 Oct 2001 12:17:24 -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: <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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <86u1wmlj1s.wl@keiichi01.osaka.iij.ad.jp>; from keiichi@iij.ad.jp on Fri, Oct 26, 2001 at 08:47:27PM +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 Fri, Oct 26, 2001 at 08:47:27PM +0900, Keiichi SHIMA / ?$BEg7D0l?(B wrote: > 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. 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. 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. > --- > 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