On Mon, Jul 14, 2014 at 12:08:28PM -0700, Tim Chen wrote: > On Mon, 2014-07-14 at 20:17 +0200, Peter Zijlstra wrote: > > Your multi-buffer thing isn't generic either, it seems lmiited to sha1. > > We actually have many other multi-buffer crypto algorithms already > published for encryption and other IPSec usages. So > multi-buffer algorithm is not just limited to SHA1. > We hope to port those to the kernel crypto library eventually. > http://www.intel.com/content/dam/www/public/us/en/documents/white-papers/fast-multi-buffer-ipsec-implementations-ia-processors-paper.pdf That's all nice and such; but the code as I've seen in these patches is very much sha1 specific. The mb part isn't separated out. > > It does not reuse padata, > padata tries to speed things up by parallelizing jobs to *multiple* > cpus. Whereas multi-buffer tries to speed things up by speeding things > up by using multiple data lanes in SIMD register in a *single* cpu. > These two usages are complementary but not the same. And if its single cpu, wth do you need that nr_running thing for another cpu for? Also, this difference wasn't clear to me. I still loathe all the async work, because it makes a mockery of accounting etc.. but that's a story for another day I suppose :-(
Attachment:
pgphtoPvNj41F.pgp
Description: PGP signature
