Date: Fri, 26 Oct 2001 10:47:34 -0700 From: Luigi Rizzo <rizzo@aciri.org> To: Bosko Milekic <bmilekic@technokratis.com> 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: <20011026104734.J64631@iguana.aciri.org> In-Reply-To: <20011026133827.A22096@technokratis.com> References: <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> <20011026133827.A22096@technokratis.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Oct 26, 2001 at 01:38:27PM -0400, Bosko Milekic wrote: > 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 Probably Stevens vol.2 comments that in depth. But mostly, we have legacy code (which is a form of documentation), and the other BSDs. Point is, i could make the one-line commit in mbuf.h and go to bed without being worried of breaking the kernel, whereas the change you have in mind would require you a scrutiny of the whole code to make sure that noone is depending on the writability check. Don't misunderstand me, in principle you are right, but in practice having the same interface with two different semantics in different OS is a recipe for trouble. Microsoft has done something similar with their socket API (at least for multicast, anyways), where primitives have a slightly different semantics and/or parameters in Windows than in Unix, and I, and am sure others, have wasted hours and hours tracking portability bugs of this kind. cheers luigi ----------------------------------+----------------------------------------- Luigi RIZZO, luigi@iet.unipi.it . ACIRI/ICSI (on leave from Univ. di Pisa) http://www.iet.unipi.it/~luigi/ . 1947 Center St, Berkeley CA 94704 Phone: (510) 666 2927 ----------------------------------+----------------------------------------- > [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 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?20011026104734.J64631>