From owner-freebsd-net Fri Oct 26 5:10:38 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 A48B737B405 for ; Fri, 26 Oct 2001 05:10:35 -0700 (PDT) Received: from walton.maths.tcd.ie by salmon.maths.tcd.ie with SMTP id ; 26 Oct 2001 13:10:34 +0100 (BST) To: Keiichi SHIMA / =?ISO-2022-JP?B?GyRCRWc3RDBsGyhC?= Cc: Bosko Milekic , Luigi Rizzo , Alfred Perlstein , net@FreeBSD.ORG Subject: Re: performance issues with M_PREPEND on clusters In-reply-to: Your message of "Fri, 26 Oct 2001 20:47:27 +0900." <86u1wmlj1s.wl@keiichi01.osaka.iij.ad.jp> X-Request-Do: Date: Fri, 26 Oct 2001 13:10:34 +0100 From: David Malone Message-ID: <200110261310.aa66738@salmon.maths.tcd.ie> 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 > > 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