From owner-freebsd-smp Fri Dec 8 13:51:57 2000 From owner-freebsd-smp@FreeBSD.ORG Fri Dec 8 13:51:54 2000 Return-Path: Delivered-To: freebsd-smp@freebsd.org Received: from smtp10.phx.gblx.net (smtp10.phx.gblx.net [206.165.6.140]) by hub.freebsd.org (Postfix) with ESMTP id 8D70137B400; Fri, 8 Dec 2000 13:51:54 -0800 (PST) Received: (from daemon@localhost) by smtp10.phx.gblx.net (8.9.3/8.9.3) id OAA37580; Fri, 8 Dec 2000 14:51:52 -0700 Received: from usr01.primenet.com(206.165.6.201) via SMTP by smtp10.phx.gblx.net, id smtpdu0XuUa; Fri Dec 8 14:51:44 2000 Received: (from tlambert@localhost) by usr01.primenet.com (8.8.5/8.8.5) id OAA24586; Fri, 8 Dec 2000 14:51:41 -0700 (MST) From: Terry Lambert Message-Id: <200012082151.OAA24586@usr01.primenet.com> Subject: Re: Netgraph and SMP To: phk@critter.freebsd.dk (Poul-Henning Kamp) Date: Fri, 8 Dec 2000 21:51:41 +0000 (GMT) Cc: cp@bsdi.com (Chuck Paterson), msmith@FreeBSD.ORG (Mike Smith), smp@FreeBSD.ORG In-Reply-To: <80663.976310686@critter> from "Poul-Henning Kamp" at Dec 08, 2000 10:24:46 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: tlambert@usr01.primenet.com Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > >For uses such as barriers for loading and unloading it is > >possible to have the counters and entry barriers all PCPU. You can then > >use more complex mechanisms to set the low level barrier and interrogate > >the counters. Terry ->>may<<- view this as another way of doing > >what he is suggesting. > > The thing that has me worried here is that using locking (as opposed > to atomic ops) in netgraph means that will expose netgraph paths to > heavy-duty locking synchronism, since TCP, UDP, IP, Mbuf will also > use a (separate) locking domain. It ought to reference on entry to netgraph; this will let it avoid locks for everything but adjusting the reference count, and won't damage reentrancy. It would mean stalling all of netgraph when loading or unloading a module, or establishing a connection or disconnecting nodes, though, but this might be OK. Sort of a BGL with multiple users/single manipulator for Netgraph. I think it's overly complicated, but you could also support the idea of per CPU connectedness, which would build the graph out on each CPU, making the relationship between nodes a per CPU thing. This would mean that you would not need to contend to build a graph per CPU, but that you would have to duplicate the build on each CPU. This would reduce to dealing with the lock only on load and unload (again). Each graph would need to set pointers to a shared state data object, though, since they are effectively the same objects with different function pointer linkages. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message