On Sun, May 22, 2022 at 2:26 PM Jens Axboe <axboe@xxxxxxxxx> wrote:
>
> On top of the core io_uring changes, this pull request includes support
> for the xattr variants.
So I don't mind the code (having seen the earlier versions), but
looking at this all I *do* end up reacting to this part:
[torvalds@ryzen linux]$ wc -l fs/io_uring.c
12744 fs/io_uring.c
and no, this is not due to this xattr pull, but the xattr code did add
another few hundred lines of "io_uring command boilerplate for another
command" to this file that is a nasty file from hell.
I really think that it might be time to start thinking about splitting
that io_uring.c file up. Make it a directory, and have the core
command engine in io_uring/core.c, and then have the different actual
IO_URING_OP_xyz handling in separate files.
And yes, that would probably necessitate making the OP handling use
more of a dispatch table approach, but wouldn't that be good anyway?
That io_uring.c file is starting to have a lot of *big* switch
statements for the different cases.
Wouldn't it be nice to have a "op descriptor array" instead of the
switch (req->opcode) {
...
case IORING_OP_WRITE:
return io_prep_rw(req, sqe);
...
kind of tables?
Yes, the compiler may end up generating a binary-tree
compare-and-branch thing for a switch like that, and it might be
better than an indirect branch in these days of spectre costs for
branch prediction safety, but if we're talking a few tens of cycles
per op, that's probably not really a big deal.
And from a maintenenace standpoint, I really think it would be good to
try to try to walk away from those "case IORING_OP_xyz" things, and
try to split things up into more manageable pieces.
Hmm?
Linus
