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

On Thu, Jun 09, 2005 at 10:43:01PM -0700, Jonathan Stone wrote:
>=20
> In message <20050610051334.GH892@bcd.geek.com.au>,
> Daniel Carosone writes:
>=20
> >On Thu, Jun 09, 2005 at 08:59:44PM -0700, Jonathan Stone wrote:
> >> Well, the more I think about it, the more I agree Stefan's
> >> observation, that the first item to attack is to get a device
> >> interrupt on CPU 0 to scehedule a softint on a _different_ CPU.
> >
> >Yes, not least because of that key word (almost :) 'schedule'.  This
> >also directly implies that the softint code is running (largely)
> >outside the kernel_lock.
>=20
> Not really; by `schedule' I meant simply schednetisr().

Pity :-)
=20
> My intent to handle hardware interrupts on one CPU, and the softnet on
> a different. At least one of those _has_ to be outside kernel_lock;
> but with supporting machinery like, just for example, Yamamoto-san's
> vintage-2003 patch, we could handle the device interrupt outside
> kernel_lock, and leave the softnet inside[*].=20

Duh, yes of course that's the least intrusive first step.

> [*] Modulo a small problem of 3.2 million synchronization
> ops, at 10GbE packet rates.

Without taking away from the point, that's something of a red herring,
I think, in that you're going to be doing interrupt mitigation in the
hardware just to avoid an unsustainable hw interrupt rate regardless
of cpu time spent servicing, and obviously one would want to batch
together the packets that come from servicing of that interrupt and
all the enqueing-for-further-processing synchronisation that comes
with it into one 'transaction' across the synchronisation perimiter.

I rather like the way Xen's request-ring structure works, for solving
a not-dissimilar problem of abstracting hardware driver interfaces
across the VMM while minimising contention between producers and
consumers (two sets of ring-state pointers).  Perhaps something
similar would be suitable for feeding hardware interrupt results into
within-kernel_lock code.

--
Dan.

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

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

iD8DBQFCqTpFEAVxvV4N66cRArwvAKC+bTyMJnAs1bKR8ASwkwZ/vuUPewCgwTYe
8dbvCwIAmYPCyOJVQzn4Q9s=
=adts
-----END PGP SIGNATURE-----

--Y3hCyKCCnioDaTIs--