In s3_srvr.c, in ssl3_accept, one finds a BUF_MEM_new() followed
by a BUF_MEM_grow(buf,SSL3_RT_MAX_PLAIN_LENGTH). This allocates a
16K buffer per SSL session for use during the handshake.
When the handshake is complete, BUF_MEM_free() zeroizes this buffer.
As it turns out, this 16K memset() is *the* bottleneck for performance
in at least one case I'm interested in -- I can accellerate all the actual
crypto operations with a hardware engine, but this memset() eats most of
the memory bandwidth of the machine when I get to a few thousand handshakes
per second.
Looking at other similar code I see buffers of minimal size initially
allocated, and then grown as needed. But I'm not sure every place I'd
have to touch in the path that uses _this_ buffer to be sure I could do
that safely.
So, two questions:
1) Does someone more familiar with the code see an immediate and
obvious way to avoid this 16K allocation, and thus 16K memset()?
2) Are there constraints I could impose on the handshake such that
the full 16K could never actually be required?
Thanks!
Thor
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
