Date: Mon, 18 Dec 2000 10:04:39 -0800 (PST) From: Archie Cobbs <archie@dellroad.org> To: Julian Elischer <julian@elischer.org> Cc: phk@FreeBSD.ORG, brian@FreeBSD.ORG, smp@FreeBSD.ORG Subject: Re: Netgraph locking primatives. take 1. Message-ID: <200012181804.eBII4dH65263@curve.dellroad.org> In-Reply-To: <3A3CFF88.6B98890@elischer.org> "from Julian Elischer at Dec 17, 2000 10:01:44 am"
next in thread | previous in thread | raw e-mail | index | archive | help
Julian Elischer writes: > Al netgraph activities (will) come in teh form of a packet of data or > a message. Both of these can be queued if a lock cannot be obtained. Sounds right. So senders can never assume that a packet will be delivered synchronously (though usually it would). "Activity" is a good word for it.. > The idea is that each node has a queue. > when a packet or message fails to aquire the lock, it is queued. > and the caller goes away. > > there are two types of aquire: > read, and write. > You can have as many readers as you like, but once you have a queued writer, > all further reader requeusts are queued behind it until it is completed. > > All data packets would be 'readers' and possibly some control messages too. > The common case is when you have a packet for a node, and there is no > contention. Hmm.. this *might* be somewhat of an oversimplification. An activity may run concurrently with some activities but not others, etc. Many activities may have only a very small critical section. Also, it's not obvious that data packets are "read only". Consider a node that wants to keep octet and packet counters (as many do) *and* wants to be able to return these statistics in a consistent snapshot. Probably the most efficient way to do this is to have a spin mutex around the small number of instructions that increment the counters (say recvPackets and recvOctets). In other words, it depends on how optimizable you want to make things. Having this code available for use by node writers would definitely be handy and provides a simple, tested, and reasonably efficient way to deal with the locking issue. But maybe it should also be possible to "opt out" by setting all data and control messages as "reader" activities and then doing roll your own locking within the node. Now this brings up the question, how is it determined what activities are "reader" activities vs. "writer" activites? The sample code doesn't have an enqueue() function that sets ngqe->flags. Perhaps each node type should supply a (read-only) "classifier" method to classify control messages one way or the other? -Archie __________________________________________________________________________ Archie Cobbs * Packet Design * http://www.packetdesign.com 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?200012181804.eBII4dH65263>