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

Jump to bottom

Dont pool IovArray but just allocate on the fly #10627

Merged
merged 9 commits into from Oct 2, 2020
Merged

Dont pool IovArray but just allocate on the fly #10627

merged 9 commits into from Oct 2, 2020

Conversation

normanmaurer
Copy link
Member

Motivation:

Pooling and re-using IovArray works for now but is not safe in its
current form once SQPOLL is used as we can not assume we can re-use the
IovArray once we called submit.

Modifications:

Just allocate the IovArray on the fly when needed by using the
ByteBufAllocator

Result:

Code is safe even with SQPOLL

@normanmaurer
Dont pool IovArray but just allocate on the fly
591b82d 
Motivation:

Pooling and re-using IovArray works for now but is not safe in its
current form once SQPOLL is used as we can not assume we can re-use the
IovArray once we called submit.

Modifications:

Just allocate the IovArray on the fly when needed by using the
ByteBufAllocator

Result:

Code is safe even with SQPOLL
@normanmaurer normanmaurer mentioned this pull request Oct 1, 2020
Closed
1Jo1
1Jo1 reviewed Oct 1, 2020
View reviewed changes
Copy link
Member

@1Jo1 1Jo1 left a comment •
edited

Choose a reason for hiding this comment

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

I think it would decrease the performance, we could still use Pool IovArrays, as we would save the index of each writeev event iovecArray which will be 'clear' in the cqe, what do you think?

@normanmaurer
Copy link
Member Author

@1Jo1 for now I don't see any perf drop with it... lets keep it simple for now

njhill
njhill reviewed Oct 1, 2020
View reviewed changes
Copy link
Member

@njhill njhill left a comment

Choose a reason for hiding this comment

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

Looks great, couple of comments.

I guess we are not worried about non-pooled direct buffers case for now? (sounds fine to me)

...sport-native-io_uring/src/main/java/io/netty/channel/uring/AbstractIOUringStreamChannel.java Show resolved Hide resolved
transport-native-unix-common/src/main/java/io/netty/channel/unix/IovArray.java Show resolved Hide resolved
@normanmaurer
Copy link
Member Author

@njhill thats right ...addressed your comments as well

@normanmaurer normanmaurer merged commit acd332a into io-uring Oct 2, 2020
@normanmaurer normanmaurer deleted the iovarray_reuse branch October 2, 2020 06:28
normanmaurer added a commit that referenced this pull request Oct 15, 2020
@normanmaurer
Dont pool IovArray but just allocate on the fly (#10627)
c5c17ec 
Motivation:

Pooling and re-using IovArray works for now but is not safe in its
current form once SQPOLL is used as we can not assume we can re-use the
IovArray once we called submit.

Modifications:

Just allocate the IovArray on the fly when needed by using the
ByteBufAllocator

Result:

Code is safe even with SQPOLL
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@chrisvest chrisvest chrisvest approved these changes

@1Jo1 1Jo1 1Jo1 approved these changes

@njhill njhill njhill approved these changes

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

None yet
4 participants
@normanmaurer @chrisvest @1Jo1 @njhill