Andy Polyakov wrote: >> FYI "pushfl; popfl" is used to clear a bit in eflags that says whether >> or not to reload the encryption key from memory. For now I always force >> the reloading. Probably it could be more optimized later. > [...] > Which in turn means that as long as you *know* that no execution thread > interleaves several contexts, pushfl;popfl is redundant. Right?
I'd say it's not uncommon for apps to have different keys (i.e. contexts) for dataflows in different directions. E.g. one key for incoming and one for outgoing data. Right? For now I'd leave it as it is and would add the comparsion to the last context used later. > Get rid of htonl. It surely mapped to inline asm on Linux, but what > about other platforms? Just implement your own inline bswapl. If it wasn't inlined - who cares? It is only used in key generation, i.e. not very often. But I can add padlock_htonl() if you want. > In my opinion aligning code abuses malloc. I'd recommend to declare an > automatic buffer of say 1KB and use it as temporary aligned storage > whenever nbytes is less than size of this automatic buffer, and fall to > malloc only if it's larger. Once you have the code in place, see how > this buffer size affects the benchmark. For small blocks it may be worth the effort, yes. I'll make it 1.5kB so that an ethernet packet fits there. Do you agree with using alloca()? > Shouldn't you check if output buffer is aligned first? Because if it is > and input is not, then you don't have to use intermediate aligned > storage. Right? Good point ;-) Fortunately in the next generation of PadLock it won't be necessary to have in/out data aligned. Most of the aligner will be just skipped over. Michal Ludvig ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
