From owner-freebsd-net Mon Oct 30 14:14:32 2000 Delivered-To: freebsd-net@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 5317137B479; Mon, 30 Oct 2000 14:14:28 -0800 (PST) Received: from beppo (beppo [192.67.166.79]) by feral.com (8.9.3/8.9.3) with ESMTP id OAA03349; Mon, 30 Oct 2000 14:14:03 -0800 Date: Mon, 30 Oct 2000 14:14:03 -0800 (PST) From: Matthew Jacob Reply-To: mjacob@feral.com To: David Greenman Cc: Bosko Milekic , freebsd-net@FreeBSD.ORG, freebsd-arch@FreeBSD.ORG Subject: Re: MP: per-CPU mbuf allocation lists In-Reply-To: <200010301927.LAA01623@implode.root.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, 30 Oct 2000, David Greenman wrote: > > I recently wrote an initial "scratch pad" design for per-CPU mbuf > > lists (in the MP case). The design consists simply of introducing > > these "fast" lists for each CPU and populating them with mbufs on bootup. > > Allocations from these lists would not need to be protected with a mutex > > as each CPU has its own. The general mmbfree list remains, and remains > > protected with a mutex, in case the per-CPU list is empty. > > I have only one question - is the lock overhead really so high that this > is needed? If you know that you can also pre-busdma wrap these lists (which is required for full alpha support, and may(?) be for ia64), yes, this makes sense to me (at least). I had a friend at Sun not speak to me for years because I didn't do this for the Solaris DKI/DDI. -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message