Date: Fri, 08 Dec 2000 16:03:30 -0800 From: Julian Elischer <julian@elischer.org> To: Poul-Henning Kamp <phk@critter.freebsd.dk> Cc: Chuck Paterson <cp@bsdi.com>, Mike Smith <msmith@FreeBSD.ORG>, smp@FreeBSD.ORG Subject: Re: Netgraph and SMP Message-ID: <3A3176D2.C3587387@elischer.org> References: <80663.976310686@critter>
next in thread | previous in thread | raw e-mail | index | archive | help
Poul-Henning Kamp wrote:
>
> In message <200012082121.eB8LLSQ07456@berserker.bsdi.com>, Chuck Paterson write
> s:
> >
> >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.
My aim is to have as little locking as possible. (You should know since I've
been CCing you for some of the discussions archie and I were having)
The difficulty comes with trying to not fall off the edge of the world when a
node or link is reconfigured while data is transiting through the system. At the
moment I'm using reference counts and VALID/INVALID flags to stop things from
disapearing out from under running code, but the boundary conditions are really
difficult. It's easy to stop a node from going away while the packeet is fairly
and squarly in teh node's control, but the problem occurs when a packet is
transitionning from one node to another. There are race conditions all over the
place.
I think that some simple spinlocks can remove those race conditions but I'd like
to use locks that allow more than one packet at a time to transition through a
node or graph. This implies a reader/writer lock, as Mike Smith pointed out.
Anyhow it's all theoretical at the moment as I'm still only drawing on paper
napkins at this stage.
(BTW any productive suggestions would be welcome)
>
> --
> Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
> phk@FreeBSD.ORG | TCP/IP since RFC 956
> FreeBSD committer | BSD since 4.3-tahoe
> Never attribute to malice what can adequately be explained by incompetence.
>
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-smp" in the body of the message
--
__--_|\ Julian Elischer
/ \ julian@elischer.org
( OZ ) World tour 2000
---> X_.---._/ presently in: Budapest
v
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?3A3176D2.C3587387>