Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Integrate io_uring transport into 4.2 #14045

Merged
merged 24 commits into from May 15, 2024
Merged

Integrate io_uring transport into 4.2 #14045

merged 24 commits into from May 15, 2024

Conversation

normanmaurer
Copy link
Member

Motivation:

We should include our io_uring transport as part of 4.2

Modifications:

Add io_uring transport based on our incubator version and main version

Result:

Fixes #14010

@normanmaurer
Copy link
Member Author

This "version" is a combination of what we had in netty-incubator-transport-native-io_uring and our main branch.
You might wonder why not pick one or the other, the reason is that both had its pros and cons and so I tried to merge these to also work with our new IoHandler design.

The good news is that with this implementation it should be trivial to support things like file IO, as all it would take is to write a FileIoHandle that you can register and then use the returned IOUringIoRegistration to submit the relevant IOUringIoOps and react to the IOUringIoEvent.

Beside this I also want to take another stab on the IOUringDatagramChannel implementation and use a blocking fd there as well with fastpoll. I will work on this while already give you some chance to have a look at the code.

We should also remove all the methods on the SubmissionQueue that are now not used anymore as Channel implementations are using the IOUringIoRegistration to submit work to the SubmissionQueue.

@normanmaurer normanmaurer added this to the 4.2.0.Final milestone May 10, 2024
@normanmaurer
Copy link
Member Author

Also in the future we should look into using provided buffers: https://github.com/axboe/liburing/wiki/io_uring-and-networking-in-2023#provided-buffers

@normanmaurer
Copy link
Member Author

And I think we also should move from IOUring* to IoUring* for class / interface names. This is more inline with others like Nio etc.

@normanmaurer
Copy link
Member Author

And before I forget shout out to @axboe for all the help in answering my questions and also for working on future changes for io_uring based on some of my feedback. OSS rocks :)

* @param data the data
* @return ops.
*/
public static IOUringIoOps newAsyncCancel(int fd, int flags, long udata, short data) {
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We could basically add a method for any OP_ that io_uring supports. I just focused on the ones that we need. At the end people can just construct the IOUringIoOps themselves. These methods just make things easier the same way as liburing makes things easier compared to use the raw io_uring interface

Copy link
Contributor

@franz1981 franz1981 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

First round seems ok, but wanna run it and see if I am convinced the same :P

Related the dead code, that's why is not yet approved: need to delete quite a few no longer used methods!

@normanmaurer
Copy link
Member Author

First round seems ok, but wanna run it and see if I am convinced the same :P

For sure :) Keep me posted.

Related the dead code, that's why is not yet approved: need to delete quite a few no longer used methods!

Yes will do more cleanup etc. Just wanted to show something first

Motivation:

We should include our io_uring transport as part of 4.2

Modifications:

Add io_uring transport based on our incubator version and main version

Result:

Fixes #14010
@normanmaurer
Copy link
Member Author

Need to investigate why I see some AssertionError on the CI while I never see it here...

@normanmaurer
Copy link
Member Author

Need to investigate why I see some AssertionError on the CI while I never see it here...

Nevermind I did mess up while cleanup ... should be fixed now

@normanmaurer
Copy link
Member Author

@franz1981 @chrisvest I think this is ready to go now.

@normanmaurer
Copy link
Member Author

I will rename everything from IOUring* to IoUring* before pulling it in. I just wanted to keep the name like it is for now to make it easier to compare to main and the incubator version.

@chrisvest
Copy link
Contributor

It's a lot to review, but I'm having a look now.

Copy link
Contributor

@chrisvest chrisvest left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Had some comments. Mostly small stuff.

@normanmaurer
Copy link
Member Author

Had some comments. Mostly small stuff.

@chrisvest addressed and also did some more simplification... PTAL again

Copy link
Contributor

@franz1981 franz1981 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I need to give another round because I see there's some new changes

if (shutdownOutputFuture.isDone()) {
shutdownOutputDone(shutdownOutputFuture, promise);
} else {
shutdownOutputFuture.addListener(new ChannelFutureListener() {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we probably can find a way to turn these in labmdas too, where it makes sense: personally not super happy because lambdas still put pressure on lambda metafactory, but still...they make the code more succint

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yeah we can for sure. It's just what we had in the incubator version so I didn't touch it yet.

assert iovArray == null;
assert writeId == 0;
int numElements = Math.min(in.size(), Limits.IOV_MAX);
ByteBuf iovArrayBuffer = alloc().directBuffer(numElements * IovArray.IOV_SIZE);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we could pool the IovArray to save netty/netty-incubator-transport-io_uring#154
on the instance and just let it go if we could reuse it, right after

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes but like you said we can optimize later. Let's get this in first.


// These buffers are used for msghdr, iov, sockaddr_in / sockaddr_in6 when doing recvmsg / sendmsg
//
// TODO: Alternative we could also allocate these everytime from the ByteBufAllocator or we could use
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

better have an issue for this

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is existing code that we also have in the incubator version. it is just a copy and paste and we can decide later if we want an issue or not imho.


@Override
protected void doDisconnect() throws Exception {
// TODO: use io_uring for this too...
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

as ditto before: better to have an issue, unless closed in this pr

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

again... same as we have in the incubator version. We can create an issue once this is in.

Copy link
Contributor

@franz1981 franz1981 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right now just minor things, really.
After fixing wht @chrisvest asked for, I'm +100 to get this in, and well done @normanmaurer !

Copy link
Contributor

@chrisvest chrisvest left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this is good for this PR.

@normanmaurer normanmaurer merged commit 028394a into 4.2 May 15, 2024
3 checks passed
@normanmaurer normanmaurer deleted the io_uring_42_new branch May 15, 2024 08:23
@normanmaurer
Copy link
Member Author

Thanks a lot for everyone involved!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants