| Message ID | 1508059209-25529-1-git-send-email-gilad@benyossef.com |
|---|---|
| Headers | show |
| Series | simplify crypto wait for async op | expand |
On Sun, Oct 15, 2017 at 10:19:45AM +0100, Gilad Ben-Yossef wrote: > > Changes from v8: > - Remove the translation of EAGAIN return code to the > previous return code of EBUSY for the user space > interface of algif as no one seems to rely on it as > requested by Herbert Xu. Sorry, but I forgot to mention that EAGAIN is not a good value to use because it's used by the network system calls for other meanings (interrupted by a signal). So if we stop doing the translation then we also need to pick a different value, perhaps E2BIG or something similar that have no current use within the crypto API or network API. Thanks, -- Email: Herbert Xu <herbert@gondor.apana.org.au> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
On Sun, Oct 15, 2017 at 6:38 PM, Herbert Xu <herbert@gondor.apana.org.au> wrote: > > On Sun, Oct 15, 2017 at 10:19:45AM +0100, Gilad Ben-Yossef wrote: > > > > Changes from v8: > > - Remove the translation of EAGAIN return code to the > > previous return code of EBUSY for the user space > > interface of algif as no one seems to rely on it as > > requested by Herbert Xu. > > Sorry, but I forgot to mention that EAGAIN is not a good value > to use because it's used by the network system calls for other > meanings (interrupted by a signal). > > So if we stop doing the translation then we also need to pick > a different value, perhaps E2BIG or something similar that have > no current use within the crypto API or network API. Yes, I see what you mean. With a netlink based interface this can be confusing to debug. Would you mind if we used ENOSPC instead of E2BIG? "No space left on device" seems more appropriate than "Argument list too long". Thanks, 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
On Tue, Oct 17, 2017 at 02:55:21PM +0300, Gilad Ben-Yossef wrote: > > Would you mind if we used ENOSPC instead of E2BIG? > > "No space left on device" seems more appropriate than > "Argument list too long". It's fine by me. Thanks, -- Email: Herbert Xu <herbert@gondor.apana.org.au> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
On Sun, Oct 15, 2017 at 10:19:45AM +0100, Gilad Ben-Yossef wrote: > Many users of kernel async. crypto services have a pattern of > starting an async. crypto op and than using a completion > to wait for it to end. > > This patch set simplifies this common use case in two ways: > > First, by separating the return codes of the case where a > request is queued to a backlog due to the provider being > busy (-EBUSY) from the case the request has failed due > to the provider being busy and backlogging is not enabled > (-EAGAIN). > > Next, this change is than built on to create a generic API > to wait for a async. crypto operation to complete. > > The end result is a smaller code base and an API that is > easier to use and more difficult to get wrong. > > The patch set was boot tested on x86_64 and arm64 which > at the very least tests the crypto users via testmgr and > tcrypt but I do note that I do not have access to some > of the HW whose drivers are modified nor do I claim I was > able to test all of the corner cases. > > The patch set is based upon linux-next release tagged > next-20171013. Has there been any performance impact analysis of these changes? I ended up with patches for one of the crypto drivers which converted its interrupt handling to threaded interrupts being reverted because it caused a performance degredation. Moving code to latest APIs to simplify it is not always beneficial. -- RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up According to speedtest.net: 8.21Mbps down 510kbps up