Thanks Steve for the comment.
I guess there are other ways to do similar things, since I was not sure about the intentions of the original code I was trying to make the change in a way such that when checkpoint is not call it should behave like before. Adding a new field for me is less likely to interfere with other code. It seems to me the three evp_md_ctxs contained within the hmac_md_ctx has the data for restoring the state but I was not sure. Also the new field serves as a flag to tell if it has checkpoint data (I could have used an existing flag). My patch also contains some hacking I would think. anyway the real saving comes from redo of state preserving of the evp_md_ctx that contains evp_pkey_ctx which in turn contains hmac_ctx which again contains three evp_md_ctx's. the dup of these are called in tls1_mac() similar place for ssl3 and EVP_DigestSignFinal() these two are the super expensive ones (real super) the copy of ctx in HMAC_Final() --- this one is not too bad can be simplified. I would think the saving is so much that is worth changing maybe in future releases. regards, Michael ----- Original Message ----- From: Dr. Stephen Henson <st...@openssl.org> To: openssl-dev@openssl.org Cc: Sent: Tuesday, November 29, 2011 1:21 PM Subject: Re: major ssl read/ write performance improvement On Mon, Nov 28, 2011, Deng Michael wrote: > Hi, > > I have changed the mac code which gives substantial improvement for both read > and write (not handshake) > > The saving is fairly major, on cpu with cryto acceleration, the change can > more than double the overall ssl read /write speed for 1K record excluding OS > IO time. this implies the change removed majority of the code overhead for > read and write. > > The basic idea is to remove all the EVP_MD_CTX duplications (which is very > cpu intensive) during read and write. the original code involves numerous > memory allocations and frees for each read or write all due to the ctx's deep > copy. > > the new way of keeping the ctx is to make it do state checkpoint and restore > instead of deep copy, after this change there is NO memory operation for read > and write. The changes are not too big also. > > One catch (should not really be a catch) is that at application level NO MORE > than one thread can work on the SAME SSL/TLS connection for read or write > (read or write can be done at the same time). But I would think most apps > would NEVER allow more than one thread to read or write on the same > connection (I don't think it would work if you do that anyway, even without > my change). > > the patch file I attached is mad from 1.0.0e version. > Thanks for the patch. It should really go to the request tracker RT though. There are a few problems with the patch as it stands. Firstly new features will never be added to 1.0.0x only security and bug fixes. Your patch adds a field in the middle of an EVP_MD_CTX which will result in binary compatibility issues with existing applications so that makes it problematical including it in 1.0.1 either. Adding the field on the end would result in fewer problems but it would still increase the size of EVP_MD_CTX. However I wonder if the same savings could be achieved in a different way. If the destination EVP_MD_CTX is the same digest as the existing one no new memory is allocated and it should simply memcpy the result across which should be a far less expensive operation. So perhaps if instead of having a temporary EVP_MD_CTX which is created and destroyed regularly we could have a more persistent one tied to the SSL structure: so the initial copy would allocate memory but subsequent ones would only be a memcpy? Adding fields at the end of an SSL structure is likely to cause far fewer problems because SSL structures are allocated using SSL_new(). Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
