Date: Fri, 26 Oct 2001 13:10:34 +0100 From: David Malone <dwmalone@maths.tcd.ie> To: Keiichi SHIMA / =?ISO-2022-JP?B?GyRCRWc3RDBsGyhC?= <keiichi@iij.ad.jp> Cc: Bosko Milekic <bmilekic@technokratis.com>, Luigi Rizzo <rizzo@aciri.org>, Alfred Perlstein <bright@mu.org>, net@FreeBSD.ORG Subject: Re: performance issues with M_PREPEND on clusters Message-ID: <200110261310.aa66738@salmon.maths.tcd.ie> In-Reply-To: Your message of "Fri, 26 Oct 2001 20:47:27 %2B0900." <86u1wmlj1s.wl@keiichi01.osaka.iij.ad.jp>
next in thread | previous in thread | raw e-mail | index | archive | help
> > 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.
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.
David.
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? <200110261310.aa66738>