From owner-freebsd-net  Fri Oct 26  5:28:33 2001
Delivered-To: freebsd-net@freebsd.org
Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [134.226.81.11])
	by hub.freebsd.org (Postfix) with SMTP id 81E1D37B405
	for <net@FreeBSD.ORG>; Fri, 26 Oct 2001 05:28:30 -0700 (PDT)
Received: from walton.maths.tcd.ie by salmon.maths.tcd.ie with SMTP
          id <aa71753@salmon>; 26 Oct 2001 13:28:29 +0100 (BST)
To: David Malone <dwmalone@maths.tcd.ie>
Cc: Keiichi SHIMA / =?ISO-2022-JP?B?GyRCRWc3RDBsGyhC?= <keiichi@iij.ad.jp>,
	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 
In-Reply-To: Your message of "Fri, 26 Oct 2001 13:10:34 BST."
             <200110261310.aa66738@salmon.maths.tcd.ie> 
Date: Fri, 26 Oct 2001 13:28:29 +0100
From: Ian Dowse <iedowse@maths.tcd.ie>
Message-ID:  <200110261328.aa71753@salmon.maths.tcd.ie>
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org

In message <200110261310.aa66738@salmon.maths.tcd.ie>, David Malone writes:
>
>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)

Yes, I think this is cleaner than the version that was just committed
to -stable, and it could have been committed to -current and MFC'd
in the normal way without changes. I really doubt that it is worth
splitting up M_WRITABLE just to marginally optimise M_LEADINGSPACE.

>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.

This optimisation seems the only reason why it might make sense to
change the current semantics of M_LEADINGSPACE to ignore writeability,
and I'm not sure that even this is worthwhile. While the word
'space' does not necessarily imply 'writable space', why would
anything ask for the leading or trailing space if writing to it
was not being considered?

Ian

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message