On Fri, Jun 24, 2016 at 09:37:28AM +0100, Giovanni Cabiddu wrote: > > I'll remove scomp and refit the software algos to plug into acomp > directly. > Would it be admissible if software algos implementations will vmalloc > the source and the destination buffers for linearizing the scatter gather > lists and will operate on those? Hmm, I guess we can still keep scomp and use vmalloc until someone spends the effort and optimises each algorithm to make them use acomp directly. So I'd still like to move the allocation down into the algorithm. That way IPsec no longer needs to keep around a 64K buffer when the average packet size is less than a page. What we can do for legacy scomp algorithms is to keep a per-cpu cache of 64K scratch buffers allocated using vmalloc. Obviously this means that if the output size exceeds 64K then we will fail the operation. But I don't really see an option besides optimising the algorithm to use acomp. IOW let's move the memory allocation logic of IPComp into the scomp layer. Before we do that we should also make sure that no other users of crypto compress needs output sizes in excess of 64K. Cheers, -- Email: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html