From owner-freebsd-net Sat Jun 29 23: 9:33 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2821437B400; Sat, 29 Jun 2002 23:09:30 -0700 (PDT) Received: from iguana.icir.org (iguana.icir.org [192.150.187.36]) by mx1.FreeBSD.org (Postfix) with ESMTP id D25D843E09; Sat, 29 Jun 2002 23:09:29 -0700 (PDT) (envelope-from rizzo@iguana.icir.org) Received: (from rizzo@localhost) by iguana.icir.org (8.11.6/8.11.3) id g5U69Rw78773; Sat, 29 Jun 2002 23:09:27 -0700 (PDT) (envelope-from rizzo) Date: Sat, 29 Jun 2002 23:09:27 -0700 From: Luigi Rizzo To: Bosko Milekic Cc: Jeffrey Hsu , net@FreeBSD.ORG Subject: Re: Should we keep a cache of mbuf+cluster ready for use ? Message-ID: <20020629230927.A78684@iguana.icir.org> References: <20020629145303.A75543@iguana.icir.org> <0GYH00JJCOL3HO@mta7.pltn13.pbi.net> <20020629190844.A54115@unixdaemons.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020629190844.A54115@unixdaemons.com>; from bmilekic@unixdaemons.com on Sat, Jun 29, 2002 at 07:08:44PM -0400 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 Sat, Jun 29, 2002 at 07:08:44PM -0400, Bosko Milekic wrote: ... > I would prefer to see an interface that just grabs both a cluster and > an mbuf from their respective per-CPU caches (in -CURRENT) while only > grabbing the lock once, if at all this is that important to you. [*] I have to say i did the tests on a -stable uniprocessor box, so the locking costs are almost negligible there, and all the gain that i measured comes from not having to do the bookkeeping. On -current, I have no idea. But i wonder, which CPU gets to serve the interrupt handler (or equivalently, the polling loop) ? Is it picked up at random, or it is statically assigned to devices or irq lines or what ? Because the per-CPU allocation may or may not be a good idea depending on the above -- e.g. if the receiving and transmitting interrupt handler end up on different CPUs then the cache becomes totally useless (and i am not mentioning those clusters freed in the protocol stack because that still runs under Giant and it will take a while before it can be parallelised). cheers luigi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message