Date: Fri, 26 Oct 2001 13:38:27 -0400 From: Bosko Milekic <bmilekic@technokratis.com> To: Luigi Rizzo <rizzo@aciri.org> Cc: "Keiichi SHIMA / ?$BEg7D0l?(B" <keiichi@iij.ad.jp>, David Malone <dwmalone@maths.tcd.ie>, Alfred Perlstein <bright@mu.org>, net@FreeBSD.ORG Subject: Re: performance issues with M_PREPEND on clusters Message-ID: <20011026133827.A22096@technokratis.com> In-Reply-To: <20011026092840.F64631@iguana.aciri.org>; from rizzo@aciri.org on Fri, Oct 26, 2001 at 09:28:40AM -0700 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> <20011026092840.F64631@iguana.aciri.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Oct 26, 2001 at 09:28:40AM -0700, Luigi Rizzo wrote: > Bosko, Keiichi has a valid point. The semantics of an interface > are described by the documentation associated with it, not by its > name or the Oxford Dictionary. And what documentation would that be? Are you referring to the [incomplete] mbuf(9) man page which does not cover M_LEADINGSPACE, or are you referring to "The Implementation of 4.4BSD" (McKusick et al.) which, to my knowledge, doesn't specify anything regarding the writability of the underlying data (I don't know if it specifies anything regarding M_LEADINGSPACE to begin with)? The M_LEADINGSPACE macro always had the line of code that would return the leading space even for ext_bufs commented out, suggesting that the code did exist in the original implementation or was intended to. You yourself noticed that the behavior of M_LEADINGSPACE was incorrect in that it returned 0 for all ext_bufs. Therefore, the issue is not whether or not M_LEADINGSPACE should be changed because, clearly, it should and you yourself are lobbying to change it. The issue is how to change it properly, and I have already presented my opinion on how it should be done. Arguing that OpenBSD and/or NetBSD don't have this behavior is totally ridiculous, seeing as how they don't have the same "writability" macros (the last time I checked) that we do anyway. > As much as it might be misleading that M_LEADINGSPACE checks for > writability, it has probably been like this for a long time, we > have plenty of code that depends on this, and people looking for > documentation will likely see this behaviour documented. Changing No. It has never been like this. > it might introduce insidious bugs in the code -- because in reality, > clusters are almost never shared except for those on the TCP send > queue and for multicast packets (but who uses multicast, anyways), > so there is a chance that we will have buggy code that goes unnoticed > for a long time. > > cheers > luigi > > On Fri, Oct 26, 2001 at 12:17:24PM -0400, Bosko Milekic wrote: > > 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 > ... > > > 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 <keiichi@iij.ad.jp> > > > KAME Project <keiichi@kame.net> > > > > > > > -- > > Bosko Milekic > > bmilekic@technokratis.com > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-net" in the body of the message > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > -- Bosko Milekic bmilekic@technokratis.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20011026133827.A22096>