--2FkSFaIQeDFoAt0B
Content-Type: text/plain; charset=iso-8859-2
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Fri, Jan 12, 2007 at 06:42:33PM -0500, Thor Lancelot Simon wrote:
> On Sat, Jan 13, 2007 at 12:29:27AM +0100, Daniel de Kok wrote:
> >=20
> > It feels wrong - there is a subsystem that provides useful abstraction =
for=20
> > cryptography, where cryptosoft is just one "provider" that can register=
=20
> > itself. Doesn't mixing xcrypt instructions sacrifice that abstraction?
>=20
> I certainly don't think so.  I work with a lot of cryptographic hardware,
> and there are basically two kinds: hardware that acts like separate
> peripheral devices, that interfaces across the bus, needs a hardware
> driver, etc; and hardware that just basically is special-purpose
> instructions on the CPU you already have.  By your reasoning, we should
> have separate "providers" for every piece of code in the system that
> has multiple implementations tuned for specific processors in an
> arch/ subdirectory.  But the fact is that fake peripheral device drivers
> are not really a great abstraction for functionality that's actually
> just additional slots in the instruction set of your CPU.
>=20
> >From my point of view, cryptographic implementations that interface to
> the programmer and host like software ought to interface to opencrypto
> via cryptosoft.  The other way creates a great deal of code duplication
> and shoehorns functionality into an abstraction it just basically does
> not fit, for no good reason.  The VIA crypto hardware does not actually
> interface to the host like a separate hardware device and should not be
> treated as one.  There are other CPUs that do crypto this way and I
> would hate to see each one get its own reimplementation of cryptosoft
> when _one_ "fake peripheral" provider implementation is really quite
> enough.  And on the other hand, there are CPUs like the Alchemy ones
> and some other MIPS parts aimed at networking applications, where the
> crypto is separate functional units that you talk to like a bus
> perhipheral.  Those _should_ get their own drivers, for the obvious
> reason.  Motorola even sells different models in the Coldfire family
> that do it each way...
>=20
> That other stuff in the system should learn to use opencrypto is largely
> a separate issue, though I agree with you.  But certainly the current
> situation where cryptosoft uses one set of software transforms and
> sys/crypto another is just wrong.

Those are all good points, but it depends on how you look at opencrypto
providers. I don't look at them as separate hardware devices. In my
opinion even cryptosoft shouldn't be magic - it should be a separate
provider, which attaches just as usual hardware provider. Even more, I'd
like cryptosoft to register as separate instance for every CPU core
available. If we have 2xDualCore CPU, I'd like to see 4 instances of
cryptosoft provider registered.

This is all not quite possible yet, because there is no decent load
balancing algorithm in the opencrypto framework. Another problem is that
separate instances of cryptosoft on each CPU could cost too much context
switches if we don't implement shortcuts, ie. "pass a request to local
CPU if it's not too busy".

Currently I implement such functionality in geli(8) itself - I bind one
worker thread to every CPU available if there is no hardware crypto
support in the system.

--=20
Pawel Jakub Dawidek                       http://www.wheel.pl
pjd@FreeBSD.org                           http://www.FreeBSD.org
FreeBSD committer                         Am I Evil? Yes, I Am!

--2FkSFaIQeDFoAt0B
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (FreeBSD)

iD8DBQFFqKMgForvXbEpPzQRAloNAJ9uD5Kyql3vePsmeIULHqdCFu7gsQCfRRC/
RVJaMNlPqIVtm51zUHatxK8=
=3C0n
-----END PGP SIGNATURE-----

--2FkSFaIQeDFoAt0B--