Date: Fri, 26 Oct 2001 12:19:13 -0400 From: Bosko Milekic <bmilekic@technokratis.com> To: David Malone <dwmalone@maths.tcd.ie> Cc: "Keiichi SHIMA / ?$BEg7D0l?(B" <keiichi@iij.ad.jp>, Luigi Rizzo <rizzo@aciri.org>, Alfred Perlstein <bright@mu.org>, net@FreeBSD.ORG Subject: Re: performance issues with M_PREPEND on clusters Message-ID: <20011026121913.B21512@technokratis.com> In-Reply-To: <200110261310.aa66738@salmon.maths.tcd.ie>; from dwmalone@maths.tcd.ie on Fri, Oct 26, 2001 at 01:10:34PM %2B0100 References: <86u1wmlj1s.wl@keiichi01.osaka.iij.ad.jp> <200110261310.aa66738@salmon.maths.tcd.ie>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Oct 26, 2001 at 01:10:34PM +0100, David Malone wrote:
> So the M_LEADINGSPACE macro should probaly read:
>
> #define M_LEADINGSPACE(m) \
> (!M_WRITABLE(m) ? 0 : \
> (m)->m_flags & M_EXT ? (m)->m_data - (m)->m_ext.ext_buf : \
> (m)->m_flags & M_PKTHDR ? (m)->m_data - (m)->m_pktdat : \
> (m)->m_data - (m)->m_dat)
>
> and the comments for M_LEADINGSPACE and M_TRAILINGSPACE should note
> the inconsistancy where M_LEADINGSPACE returns the number of writable
> bytes and M_TRAILINGSPACE returns the number bytes, but doesn't indicate
> if they are writable or not.
>
> Maybe we should also provide M_{LEAD,TRAIL}INGSPACE_{R,W} macros
> with consistant behaviour. The _R macros would be cheaper 'cos
> they wouldn't have to check writability. These could be used in
> the case where you already know the storage is writable.
>
> (Here _R would mean "regardless" 'cos it's hard to imagine a
> situation where you want to know how many readable bytes are outside
> the valid data region in an mbuf ;-)
>
> Bosko - what do you think of modifying M_LEADINGSPACE as shown
> above and then providing these new macros? It would mean that we
> can leave shared code alone, but where we want to optimise
> M_LEADINGSPACE and M_TRAILINGSPACE we have the macros to do so.
I already stated what I thought about it: it's wrong for reasons
mentionned in previous Emails. It means that we will be adding support
for a broken macro, not to mention enlarging the macro, which is bad
especially for code that is actually using it properly.
> David.
--
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?20011026121913.B21512>