| Message ID | 20230718125847.3869700-1-ardb@kernel.org |
|---|---|
| Headers | show |
| Series | crypto: consolidate and clean up compression APIs | expand |
On Tue, Jul 18, 2023 at 02:58:26PM +0200, Ard Biesheuvel wrote: > > Patch #2 removes the support for on-the-fly allocation of destination > buffers and scatterlists from the Intel QAT driver. This is never used, > and not even implemented by all drivers (the HiSilicon ZIP driver does > not support it). The diffstat of this patch makes a good case why the > caller should be in charge of allocating the memory, not the driver. The implementation in qat may not be optimal, but being able to allocate memory in the algorithm is a big plus for IPComp at least. Being able to allocate memory page by page as you decompress means that: 1. We're not affected by memory fragmentation. 2. We don't waste memory by always allocating for the worst case. Cheers,
On Fri, 28 Jul 2023 at 11:56, Herbert Xu <herbert@gondor.apana.org.au> wrote: > > On Tue, Jul 18, 2023 at 02:58:26PM +0200, Ard Biesheuvel wrote: > > > > Patch #2 removes the support for on-the-fly allocation of destination > > buffers and scatterlists from the Intel QAT driver. This is never used, > > and not even implemented by all drivers (the HiSilicon ZIP driver does > > not support it). The diffstat of this patch makes a good case why the > > caller should be in charge of allocating the memory, not the driver. > > The implementation in qat may not be optimal, but being able to > allocate memory in the algorithm is a big plus for IPComp at least. > > Being able to allocate memory page by page as you decompress > means that: > > 1. We're not affected by memory fragmentation. > 2. We don't waste memory by always allocating for the worst case. > So will IPcomp be able to simply assign those pages to the SKB afterwards?
On Fri, Jul 28, 2023 at 11:57:42AM +0200, Ard Biesheuvel wrote: > > So will IPcomp be able to simply assign those pages to the SKB afterwards? Yes that is the idea. The network stack is very much in love with SG lists :) Thanks,
On Fri, 28 Jul 2023 at 11:59, Herbert Xu <herbert@gondor.apana.org.au> wrote: > > On Fri, Jul 28, 2023 at 11:57:42AM +0200, Ard Biesheuvel wrote: > > > > So will IPcomp be able to simply assign those pages to the SKB afterwards? > > Yes that is the idea. The network stack is very much in love with > SG lists :) > Fair enough. But my point remains: this requires a lot of boilerplate on the part of the driver, and it would be better if we could do this in the acomp generic layer. Does the IPcomp case always know the decompressed size upfront?
On Fri, Jul 28, 2023 at 12:03:23PM +0200, Ard Biesheuvel wrote: > > Fair enough. But my point remains: this requires a lot of boilerplate > on the part of the driver, and it would be better if we could do this > in the acomp generic layer. Absolutely. If the hardware can't support allocate-as-you-go then this should very much go into the generic layer. > Does the IPcomp case always know the decompressed size upfront? No it doesn't know. Of course, we could optimise it because we know that in 99% cases, the packet is going to be less than 4K. But we need a safety-net for those weird jumbo packets. Thanks,