--nmemrqcdn5VTmUEE
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, Sep 06, 2006 at 06:29:32PM +0200, Joerg Sonnenberger wrote:
> On Wed, Sep 06, 2006 at 09:00:26AM -0700, Bill Studenmund wrote:
> > A lot. The IPL levels are how we tell a "fast spin lock" what interrupt=
 to=20
> > actually block.
>=20
> Well, considering e.g. the network stack, two main serialisation points
> exist:
> (a) inside the network stack to protect data structures like the routing
> table, the socket list etc.
> (b) the interface between network stack and network interfaces
>=20
> The problem (a) can be handled by multiple threads using *internal*
> locks. This does not need any further IPL protection.
> Interrupts only affect the (b), so the interface queue and the netisr hav=
e to be
> protected from concurrent access from the network stack and the interrupt
> of the nic. This access can protected by a spin lock as well, as long as
> it blocks that interrupt. For that the IPL can be replaced with a check
> whether the spin lock is already waited on by the local CPU. When
> constraining the use of spin locks to single "interrupt" blocking lock,
> this can be done cheap.

I think we're speaking past each other.

The IPL can not be replaced as you describe, because the IPL itself is not=
=20
used as you describe. The code used as you described, the splxxx() calls,=
=20
will be replaced with interupt-blocking mutexes. See Darrin's discussion=20
of this months ago, and a number of other posts.

Take care,

Bil

--nmemrqcdn5VTmUEE
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (NetBSD)

iD8DBQFE/w7BWz+3JHUci9cRArmOAJ981tJ1KqyFqWYDxA7uv+hEIDl39wCfSMYY
XRIQ9FMUtfWY1lh5Av9zIPA=
=Q1hG
-----END PGP SIGNATURE-----

--nmemrqcdn5VTmUEE--