Date: Fri, 8 Dec 2000 21:51:41 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: phk@critter.freebsd.dk (Poul-Henning Kamp) Cc: cp@bsdi.com (Chuck Paterson), msmith@FreeBSD.ORG (Mike Smith), smp@FreeBSD.ORG Subject: Re: Netgraph and SMP Message-ID: <200012082151.OAA24586@usr01.primenet.com> In-Reply-To: <80663.976310686@critter> from "Poul-Henning Kamp" at Dec 08, 2000 10:24:46 PM
next in thread | previous in thread | raw e-mail | index | archive | help
> >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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200012082151.OAA24586>