On Fri, Jun 24, 2016 at 05:26:43PM +0800, Herbert Xu wrote: > 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. Ok. > 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. Are you suggesting a different cache of scratch buffers for every algorithm implementation or a shared cache shared across all legacy scomp algorithms? > 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. Would it be ok 128K instead? We are proposing to use the acomp API from BTRFS. Limiting the size of the source and destination buffers to 64K would not work since BTRFS usually compresses 128KB. Here is the RFC sent by Weigang to the BTFS list: http://www.spinics.net/lists/linux-btrfs/msg56648.html Regards, -- Giovanni -- 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
