From owner-freebsd-net Fri Oct 26 9:19: 1 2001 Delivered-To: freebsd-net@freebsd.org Received: from technokratis.com (modemcable093.62-201-24.mtl.mc.videotron.ca [24.201.62.93]) by hub.freebsd.org (Postfix) with ESMTP id 10F0437B405 for ; Fri, 26 Oct 2001 09:18:58 -0700 (PDT) Received: (from bmilekic@localhost) by technokratis.com (8.11.4/8.11.3) id f9QGJDT21550; Fri, 26 Oct 2001 12:19:13 -0400 (EDT) (envelope-from bmilekic) Date: Fri, 26 Oct 2001 12:19:13 -0400 From: Bosko Milekic To: David Malone Cc: "Keiichi SHIMA / ?$BEg7D0l?(B" , Luigi Rizzo , Alfred Perlstein , net@FreeBSD.ORG Subject: Re: performance issues with M_PREPEND on clusters Message-ID: <20011026121913.B21512@technokratis.com> References: <86u1wmlj1s.wl@keiichi01.osaka.iij.ad.jp> <200110261310.aa66738@salmon.maths.tcd.ie> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200110261310.aa66738@salmon.maths.tcd.ie>; from dwmalone@maths.tcd.ie on Fri, Oct 26, 2001 at 01:10:34PM +0100 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org 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