Am 12.03.21 um 09:59 schrieb Ian Haywood:
On 12/03/2021 7:21 pm, Tobias Oberstein wrote:
sorry, I missed the beginning of the thread / discussion: are you working on a new, full Twisted reactor on top of io_uring?
and async filesystem is "just" one part / additional effort in that?
the advantage of io_uring is being able to combine file and network I/O, so this PR is a precondition to working on the reactor.
yeah, the advantages of io_uring are obvious, combining disk and network IO is one. even a network IO only twisted reactor for io_uring would be awesome! disk IO, for me, would be nice to have, but depends, eg LMDB mmaps the DB file, so it wouldn't go through io_uring anyways.
one more aspect: io_uring is also about zero-copy (besides reducing context switch overhead / reduce syscalls)
twisted protocol base classes always first buffer outgoing bytes in userspace. in a list that is later flattened, before pushing to kernel in the actual socket write. the latter only happens once the FD being written becomes writable of course.
since with io_uring the queue/ring to append to never blocks for writes, that buffering in twisted would lead to double buffering (as the ring already buffers)
then, io_uring follows a completion IO model (as IOCP). quite different from the "ready to write/read" model (as in epoll etc).
I am wondering, do you already have a design for these aspects of io_uring / twisted?
Twisted-Python mailing list Twisted-Python@twistedmatrix.com https://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python