Date: Sat, 27 Oct 2001 03:31:48 +0900 From: Keiichi SHIMA / =?ISO-2022-JP?B?GyRCRWc3RDBsGyhC?= <keiichi@iij.ad.jp> To: Bosko Milekic <bmilekic@technokratis.com> Cc: David Malone <dwmalone@maths.tcd.ie>, Luigi Rizzo <rizzo@aciri.org>, Alfred Perlstein <bright@mu.org>, net@FreeBSD.ORG Subject: Re: performance issues with M_PREPEND on clusters Message-ID: <867ktiw8vf.wl@keiichi01.osaka.iij.ad.jp> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <keiichi@iij.ad.jp> KAME Project <keiichi@kame.net> 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?867ktiw8vf.wl>