On Mon, Aug 24, 2020 at 11:47:30AM +0200, Ard Biesheuvel wrote: > > OK, so you are using a page size buffer for every request in flight, > and using that as a scratch buffer for the destination of the cbc() > transform? Not necessarily. It'll only allocate the page if the request size exceeds the buffer we already have in the request context. The request context size is dependent on the request context size of the underlying CBC, but it should be at least 512 bytes long. I should probably test always using the 512-byte buffer and perhaps it might be good enough. Note that the numbers I'm getting with aesni is already very close to the numbers of the underly cbc-aesni encryption so there is not much room for improvement. > I am not a fan of this approach, tbh. High latency/high bandwidth > users will cause lots of GFP_ATOMIC allocations, and synchronous CPU We could make the request context size be at least 2048 bytes long and that would obviate the need to allocate the page buffer. In any case, the cost of the page allocation is going to be drowned out by the crypto since this would only happen for large requests. > implementations will cause lots of writes polluting the D-cache for no > good reason. Non-cache coherent accelerators will cause unnecessary > traffic on the memory bus in addition to the undesirable D-cache > behavior. Perhaps, but would this be significant compared to the crypto cost? Only numbers can tell. > What we could do instead is having a certain flag/behavior in skcipher > where writes are omitted entirely, and cbcmac/cmac could opt into > that. But imho, the best way to improve this is to have a new AES-NI > asm helper (which I already implemented in my v2) that wraps the > AES-NI primitives in the right way to implement cbcmac. As I said before, I'm totally fine with a native aesni implementation for ccm/cbcmac as long as it's fully async like everything else. But a ccm/cbcmac based on cbc still makes sense since we're not going to reimplement the same thing in every crypto driver out there. Cheers, -- Email: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
