On Thu, 1 Feb 2018 12:07:21 +0200 Gilad Ben-Yossef <gilad@xxxxxxxxxxxxx> wrote: > On Thu, Feb 1, 2018 at 12:04 PM, Stephan Mueller <smueller@xxxxxxxxxx> wrote: > > Am Donnerstag, 1. Februar 2018, 10:35:07 CET schrieb Gilad Ben-Yossef: > > > > Hi Gilad, > > > >> > > >> > Which works well for the sort of optimization I did and for hardware that > >> > can do iv dependency tracking itself. If hardware dependency tracking was > >> > avilable, you would be able to queue up requests with a chained IV > >> > without taking any special precautions at all. The hardware would > >> > handle the IV update dependencies. > >> > > >> > So in conclusion, Stephan's approach should work and give us a nice > >> > small patch suitable for stable inclusion. > >> > > >> > However, if people know that their setup overhead can be put in parallel > >> > with previous requests (even when the IV is not yet updated) then they > >> > will > >> > probably want to do something inside their own driver and set the flag > >> > that Stephan is proposing adding to bypass the mutex approach. > >> > >> The patches from Stephan looks good to me, but I think we can do better > >> for the long term approach you are discussing. > > > > What you made me think of is the following: shouldn't we relay the inline IV > > flag on to the crypto drivers? > > > > The reason is to allow a clean implementation of the enabling or disabling of > > the dependency handling in the driver. Jonathan's driver, for example, decides > > based on the pointer value of the IV buffer whether it is the same buffer and > > thus dependency handling is to be applied. This is fragile. I agree it's inelegant and a flag would be better than pointer tricks (though they are safe currently - we never know what might change in future) It was really a minimal example rather than a suggestion of the ultimate solution ;) I was planning on suggesting a flag myself once the basic discussion concluded the approach was worthwhile. > > > > As AF_ALG knows whether the inline IV with separate IVs per request or the > > serialization with one IV buffer for all requests is requested, it should > > relay this state on to the drivers. Thus, for example, Jonathan's driver can > > be changed to rely on this flag instead on the buffer pointer value to decide > > whether to enable its dependency handling. > > Yes, that is exactly what I was trying to point out :-) Agreed - make things explicit rather than basically relying on knowing how the above layers are working. Thanks, Jonathan
