On Mon, Jun 13, 2016 at 04:56:12PM +0800, Herbert Xu wrote: > The backup path is also very unlikely to work because we'll be > hitting this with 64K sizes and this just won't work with a 4K > page size. Is scatterwalk_map_and_copy broken? > So up until now we've getting around this 64K issue with vmalloc, > and then we try to conserve the precious vmalloc resource by using > per-cpu allocation. I don't clearly understand what is the issue. Can you please give me more details? > This totally breaks down once you go to DMA, where an SG list is > required. scomp backends should be used only for software implementations. A driver backend which needs DMA should plug into acomp. > Unfortunately, this means that there is no easy way > to linearise the data for our software implementations. > > There is no easy way out I'm afraid. I think we'll have to bite > the bullet and refit our software algos so that they handle SG > lists. Although feasible, I think it wouldn't be an easy job. > Not only will this solve the problem at hand, it'll also mean that > acomp users will never have to do vmalloc so it's a win-win. It > also means that we won't need the scomp interface at all. > > This does bring up another question of who should be allocating the > output memory. Up until now it has been up to the user to do so. > However, if our algos can actually handle SG lists then I think it > should be fairly easy to make them do the allocation instead. What > do you think? I would prefer the user of the api to allocate and manage the output memory. Thanks, -- 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
