Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 26 Oct 2001 20:47:27 +0900
From:      Keiichi SHIMA / =?ISO-2022-JP?B?GyRCRWc3RDBsGyhC?= <keiichi@iij.ad.jp>
To:        Bosko Milekic <bmilekic@technokratis.com>, 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:  <86u1wmlj1s.wl@keiichi01.osaka.iij.ad.jp>
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>

next in thread | previous in thread | raw e-mail | index | archive | help
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  <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?86u1wmlj1s.wl>