Re: need to pick a solution for dm-crypt IV generation and do it! [was: Re: dm: submit stacked requests in irq enabled context]
Until we move to some latest stable kernel as Keith mentioned. On 5/11/2017 11:22 AM, Neeraj Soni wrote: Thanks for inputs folks. So shall i conclude that there is no remedy available that can be applied on 4.4 and reverting this patch is only way forward to solve the degradation? Neeraj On 5/10/2017 8:25 PM, Gilad Ben-Yossef wrote: On Wed, May 10, 2017 at 5:45 PM, Mike Snitzerwrote: On Wed, May 10 2017 at 9:37am -0400, Gilad Ben-Yossef wrote: On Wed, May 10, 2017 at 11:49 AM, Neeraj Soni wrote: Hi Keith, Request based dm (dm-req-crypt) is being used for Disk Encryption solution in Android used by Google. Also as i mentioned reverting this fix improves the RR/RW numbers so this proves the request based dm is coming into path and is being used. Sadly, that is an out of tree module. Does it still use Qcom specific APIs in its implementation (qcrypto_* funcs)? It did the last time I've checked - and the driver that implements those is not upstream either... It makes it difficult to help - which is a shame since I am interested in enabling higher performance of dm-crypt when using HW based crypto transformation myself. I have absolutely no interest in request-based dm-crypt. It is a hack to work-around limitations in crypto IV generation. I agree. This is why I've said I'm interested in a high performance dm-crypt, not "request based dm-crypt". They are trying to solve the same problem but with the wrong solution and doing so out of upstream. As the parlance of our time seems to go... sad. :-) Cheers, Gilad
Re: need to pick a solution for dm-crypt IV generation and do it! [was: Re: dm: submit stacked requests in irq enabled context]
Thanks for inputs folks. So shall i conclude that there is no remedy available that can be applied on 4.4 and reverting this patch is only way forward to solve the degradation? Neeraj On 5/10/2017 8:25 PM, Gilad Ben-Yossef wrote: On Wed, May 10, 2017 at 5:45 PM, Mike Snitzerwrote: On Wed, May 10 2017 at 9:37am -0400, Gilad Ben-Yossef wrote: On Wed, May 10, 2017 at 11:49 AM, Neeraj Soni wrote: Hi Keith, Request based dm (dm-req-crypt) is being used for Disk Encryption solution in Android used by Google. Also as i mentioned reverting this fix improves the RR/RW numbers so this proves the request based dm is coming into path and is being used. Sadly, that is an out of tree module. Does it still use Qcom specific APIs in its implementation (qcrypto_* funcs)? It did the last time I've checked - and the driver that implements those is not upstream either... It makes it difficult to help - which is a shame since I am interested in enabling higher performance of dm-crypt when using HW based crypto transformation myself. I have absolutely no interest in request-based dm-crypt. It is a hack to work-around limitations in crypto IV generation. I agree. This is why I've said I'm interested in a high performance dm-crypt, not "request based dm-crypt". They are trying to solve the same problem but with the wrong solution and doing so out of upstream. As the parlance of our time seems to go... sad. :-) Cheers, Gilad
Re: need to pick a solution for dm-crypt IV generation and do it! [was: Re: dm: submit stacked requests in irq enabled context]
On Wed, May 10, 2017 at 5:45 PM, Mike Snitzerwrote: > On Wed, May 10 2017 at 9:37am -0400, > Gilad Ben-Yossef wrote: > >> On Wed, May 10, 2017 at 11:49 AM, Neeraj Soni >> wrote: >> > Hi Keith, >> > >> > Request based dm (dm-req-crypt) is being used for Disk Encryption solution >> > in Android used by Google. Also as i mentioned reverting this fix improves >> > the RR/RW numbers so this proves the request based dm is coming into path >> > and is being used. >> >> Sadly, that is an out of tree module. >> >> Does it still use Qcom specific APIs in its implementation (qcrypto_* funcs)? >> It did the last time I've checked - and the driver that implements >> those is not upstream either... >> >> It makes it difficult to help - which is a shame since I am interested >> in enabling higher performance >> of dm-crypt when using HW based crypto transformation myself. > > I have absolutely no interest in request-based dm-crypt. It is a hack > to work-around limitations in crypto IV generation. I agree. This is why I've said I'm interested in a high performance dm-crypt, not "request based dm-crypt". They are trying to solve the same problem but with the wrong solution and doing so out of upstream. As the parlance of our time seems to go... sad. :-) Cheers, Gilad -- Gilad Ben-Yossef Chief Coffee Drinker "If you take a class in large-scale robotics, can you end up in a situation where the homework eats your dog?" -- Jean-Baptiste Queru