On Wed, Sep 27, 2000 at 12:10:30PM -0400, Michael T. Babcock wrote: > > A queuing concept is definately needed if this is to be done right the first > time (so to speak). The configuration of this interface, however, would be > the interesting challenge here. How to present to the user (the sysadmin, > most likely) the options for dealing with crypto on a per-system, perhaps > per-app basis. Prioritising certain applications over others, perhaps, > would end up being an issue as well. > > For example: > OpenSSL uses the "crypto accel api" for web serving. > FreeS/WAN uses it for VPN traffic. ok > GPG uses it to encrypt E-mails or generate signatures. This is a stretch! Unless there is a painfully obvious win of involving the kernel in GPGs activities I it should be left to do its stuff in userland. > > I would probably set the FreeS/WAN requests to have a slightly lower > priority than the OpenSSL requests because we host E-commerce sites ... and > the GPG traffic would be lowest, but I wouldn't want it to get swamped out > of the picture if the crypto card were at full use. Having it send a > suitable? number of requests to the software crypto system would be > necessary as well. > Hopefully this could be (indirectly) handled by other parts of the kernel, namely the QoS modules or the traffic shaper. > > It becomes quite interestingly complex ;-). > It certainly _can_ be made complex. astor -- Alexander Kjeldaas Mail: astor@xxxxxxx finger astor@xxxxxxxxxxxxxxxxx for OpenPGP key. Linux-crypto: cryptography in and on the Linux system Archive: http://mail.nl.linux.org/linux-crypto/
