no I meant that I am already getting 2000/sec on the *server*.
By my calculations I should be able to get 3000/sec on the server
with the optimizations I want to do.
> 2000/sec is a good place to be, on a client. Expect less on a
> server, unfortunately.
>
> > I replaced OPENSSL_cleanse() {...} with { memset(); } already
> > - IT WAS THE TOP FUNCTION IN MY FIRST GPROF RUN!!!!!
>
> Yes. This is the OPENSSL_cleanse() of a maximum-sized SSL record,
> right at the outset of any session. It is amazingly expensive, but
> I have had trouble ascertaining whether it can be safely arranged
> for it to zero less data.
It's the algorithm that's expensive. What's wrong with memset? *duck*
I memset the full packet length and it drops of the first page of gprof
output. I mean how paranoid do you need to be hear?</flamebate>
> Which version of OpenSSL are you using?
openssl-0.9.8g
> It appears that in -current
> an engine can provide an HMAC method,
oh? ok thanks
> and the Broadcom hardware does
> directly support HMAC. The old way, where engines saw only raw hash
> operations (MD5 or SHA) even though SSLv3 or TLS was doing HMAC, was
> completely insane.
>
> I wish there were a way for an engine to provide an SSL-record-encryption
> or -decryption method. Most modern accellerators do those, too.
>
>
Yep
-paul
