From owner-freebsd-net Sun Oct 28 18: 5: 8 2001 Delivered-To: freebsd-net@freebsd.org Received: from tokyogw.iij.ad.jp (tokyogw.iij.ad.jp [202.232.15.22]) by hub.freebsd.org (Postfix) with ESMTP id 5793037B406 for ; Sun, 28 Oct 2001 18:05:03 -0800 (PST) Received: by tokyogw.iij.ad.jp; id LAA23075; Mon, 29 Oct 2001 11:05:02 +0900 (JST) Received: from h055n005.iij.ad.jp(192.168.5.55) by tokyogw.iij.ad.jp via smap (V4.2) id xma022523; Mon, 29 Oct 01 11:04:07 +0900 Received: from keiichi01.osaka.iij.ad.jp (localhost.osaka.iij.ad.jp [127.0.0.1]) by keiichi01.osaka.iij.ad.jp (8.11.6/8.11.6) with ESMTP id f9T23pY04286; Mon, 29 Oct 2001 11:03:52 +0900 (JST) (envelope-from keiichi@iij.ad.jp) Date: Mon, 29 Oct 2001 11:03:51 +0900 Message-ID: <86ofmr2oe0.wl@keiichi01.osaka.iij.ad.jp> From: Keiichi SHIMA / =?ISO-2022-JP?B?GyRCRWc3RDBsGyhC?= To: Luigi Rizzo Cc: Bosko Milekic , David Malone , Alfred Perlstein , net@FreeBSD.ORG Subject: Re: performance issues with M_PREPEND on clusters In-Reply-To: <20011026075001.C64631@iguana.aciri.org> References: <20011023110307.A34494@iguana.aciri.org> <20011023132813.I15052@elvis.mu.org> <20011023114650.C34494@iguana.aciri.org> <20011023140034.M15052@elvis.mu.org> <20011023140628.A36095@iguana.aciri.org> <20011023185759.A328@technokratis.com> <20011026110635.B14635@walton.maths.tcd.ie> <86u1wmlj1s.wl@keiichi01.osaka.iij.ad.jp> <20011026075001.C64631@iguana.aciri.org> User-Agent: Wanderlust/2.6.0 (Twist And Shout) SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-1?Q?Unebigory=F2mae?=) APEL/10.2 MULE XEmacs/21.1 (patch 14) (Cuyahoga Valley) (i386--freebsd) Organization: Internet Initiative Japan Inc. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII 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 Hi Luigi, Luigi Rizzo wrote: > > so i have a question for you -- the next step on this kind of > optimizations is to avoid that m_pullup() allocates an mbuf > when data is already contiguous and in a writable (non-shared) > cluster. > > Garret was suggesting a new interface for this, at the beginning > i thought the same, but now i am a bit uncertain on whether > it is really necessary to use a different interface, > or whether this would cause compatibility > problems with other BSD's. > > Maybe you have already thought about this issue while developing > the KAME code, and can say something on the topic ? Though I am not a mbuf expert, I try to state my understanding. (If some other KAME guys read this thread, please response.) As Bill already said, there are the code those rely on the side-effect of m_pullup() which ensure that the data is not shared. Our code also has such dependency. If we change the behaviour, probably we will have invisible bugs. The possible way is to introduce a new API that does as you are proposing, that is to pullup the mbuf regardless of their writability. In this case, we can use the new API in a new code to gain the performance. Also, the old code works with no problem. I think, if we want a new m_pullup, a new API is a better solution. --- Keiichi SHIMA IIJ Research Laboratory KAME Project To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message