Hi William, On Fri, May 08, 2020 at 04:34:26PM +0200, William Dauchy wrote: > Hello, > > Here a first experimentation of IO_URING on certificate loading. It > targets heavy users of certificates (several thousands), most likely > public hosting operators. I believe it could be a post v2.2 material if > people are interested. I tried to make it the less invasive possible in > ssl_sock.c to it remains maintainable.
I really like this. I remember that when Jens presented us io-uring at KR2019 we both suspected there were a lot of useful cases to expect from it when async I/O were needed. Your work could be extended to other files, like errorfiles, maps, ACLs, etc. However with the config parser being very linear, it's extremely unlikely that we could actually benefit from this in places other than certs. What makes certs specific is that a single config line can induce hundreds of thousands of file accesses and that these ones do benefit in being performed in parallel. Despite this I'm wondering if we should think about a generic approach like an async file open with a callback on what to call once the file is opened, or optionally an automatic async read and a callback set up for received data. This would bring the benefit of allowing to perform runtime FS accesses without destroying performance: right now, if you try to access the file system from Lua or maybe from within one of the device detection libs, or if you'd like to reload some files from the CLI, the whole thread totally freezes until the I/O is completed, which is why such accesses are absolutely forbidden. But done asynchronously it could be different. We could imagine an async read API to be used from Lua. We could even imagine being able to trigger reloading certain files (ACL patterns or error files maybe) from the CLI, or even to serve static files. This will of course not solve the security issues that come with doing this, but at least it could solve the performance issue. Probably that the work should be split into a functional and an implementation layer. The functional layer is the ability to perform async file operations. The implementation is done using uring. But for other OSes we could imagine using an emulation layer based on AIO or even a bunch of threads, which could still possibly provide some benefits during startup when loading tons of certificates, especially when that's from spinning disks (not sure if those are still in use though, last time I saw one was when I tried to repair my old Ultra5 a few months ago). > Other experimentation are ongoing around epoll operations (I'm thinking > about alternative way for busy polling) but that something that I want > to extend later with more serious testing. >From day one I've been totally convinced it's possible to create a new poller entirely based on io-uring. We could avoid a number of the ugly tricks we use in epoll to avoid useless epoll_ctl() calls. What's nice about our pollers is that they're entirely modular so it is perfectly possible to create your own and experiment with it. > I also recently got some > crazy ideas around traffic duplication to make use of async, but that's > another story. OK. I'll leave it to William L. to have a look at your patch and suggest what to do with it. It's definitely too late for 2.2 as you guessed, but maybe we could put it into "next" or create a dedicated "uring" branch to keep your ongoing work on the subject until it's considered mergeable. Thanks, Willy
