On Mon, 26 Jun 2023 at 11:53, Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx> wrote: > > On Mon, Jun 26, 2023 at 11:21:20AM +0200, Ard Biesheuvel wrote: > > > > As I asked before, could we do the same for the acomp API? The only > > existing user blocks on the completion, and the vast majority of > > implementations is software only. > > We already have scomp. It's not exported so we could export it. > > However, compression is quite different because it was one of the > original network stack algorithms (IPcomp). So SG will always be > needed. > > In fact, if anything SG fits quite well with decompression because > it would allow us to allocate pages as we go, avoiding the need > to allocate a large chunk of memory at the start as we do today. > > We don't make use of that ability today but that's something that > I'd like to address. > OK, so you are saying that you'd like to see the code in net/xfrm/xfrm_ipcomp.c ported to acomp, so that IPcomp can be backed using h/w offload? Would that be a tidying up exercise? Or does that actually address a real-world use case? In any case, what I would like to see addressed is the horrid scomp to acomp layer that ties up megabytes of memory in scratch space, just to emulate the acomp interface on top of scomp drivers, while no code exists that makes use of the async nature. Do you have an idea on how we might address this particular issue?
