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

On Wed, Jun 08, 2005 at 09:14:39AM +0900, YAMAMOTO Takashi wrote:
> > >what you're saying here is that you want performance but
> > >are not intersted in necessary work (=3D=3D audio).
> > >i don't think it's reasonable.
> >=20
> > Audio drivers have kHz sample rates and generally handle DMA buffers
> > with some nontrival number of samples. 10GbE ethernet NICs deliver
> > 800,000 1500-byte packet per second. You seriously think you can put
> > an onus on a developer, that working on the low-rate audio problem is
> > a pre-requisite to tackling the 10GbE problem?
> >=20
> > That strikes me as indefensible.
>=20
> interrupt rate is not important at all.
> the fact it can interrupt IPL_NET code is important.
>=20
> Jonathan, i can understand your frustration.
> however, i don't think there is a sane shortcut.

I've been trying to think of one. While I agree it'd be best to do things=
=20
cleanly, I'd really really like to let Jonathan get working on SMP network=
=20
processing.

I _think_ things would work if we carved out a perimeter in the network=20
stack area, and required a second lock to access it. Thus either biglock=20
or driver-specific code could grab it and, as I understand the issues, we=
=20
won't run into "you can get interrupted by biglock" concerns. I realize=20
that establishing such a perimeter would be a chunk of the SMP work...

However I then thought about splvm.

I think memory allocation will need to be sorted out before interrupt=20
handlers can allocate memory, or at least some sort of fix will be needed=
=20
(like something allocating at low IPL and feeding them to a pool for the=20
driver at IP_NET).

> you can tackle network code today as i said in another mail.
> (http://mail-index.NetBSD.org/tech-kern/2005/06/07/0014.html)
> is there any compelling reason not to do so?

To be honest, if it were only moving IP_AUDIO around, I'd say add defines=
=20
to the main tree to do it, so we could all choose to run the code=20
Jonathan's working on. Unfortunately splvm makes it more than that.

Take care,

Bill

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

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

iD8DBQFCqQPRWz+3JHUci9cRAoq9AKCHk7mt0LBXVG6LvOUAoJ8M7aaFpACgi6GT
fZVeHdaK4bOvGZfkR7grjP8=
=AHAS
-----END PGP SIGNATURE-----

--uAKRQypu60I7Lcqm--