Tadeusz Struk <tadeusz.struk@xxxxxxxxx> wrote: > > The more I think about the sgl support the more it looks to me like it wasn't > a good idea. It will be copied into a flat buffer somewhere along the way anyway. > Like in the example below. > > I have that conversion already done, and for SW it looks like the data is copied 4 times > for a single operation: > 1 - from sgl to flat buffer, because MPI doesn't take sgls, (if the src has more ents) > 2 - from buff to MPI, then, after operation > 3 - export from MPI to a buff and > 4 - from buff to sgl (if is the output sg it also fragmented). > > I can see now that with all these padding schemes there will be more buffer copied > on top of this, so I wonder if it still make sense. > Herbert? I think it makes sense. Because to implement algif_akcipher someone will need to do the linearisation anyway. Moreover there is hardware out there that handles this transparently and we should not cripple them. We should add MPI helpers to read/write SG lists which can then be used by those implementations that need the capability. For the sake of simplicity you can simply start with a copy but later we can optimise it to be smarter. You can always have a fast-path for the case where the SG list is a single entry. 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
