Re: [PATCH v6 2/8] crypto: add driver-side scomp interface

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [Kernel]     [Gnu Classpath]     [Gnu Crypto]     [DM Crypt]     [Netfilter]     [Bugtraq]

  Powered by Linux