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

Reply via email to