search

DataDog / glommio

Glommio is a thread-per-core crate that makes writing highly parallel asynchronous applications in a thread-per-core architecture easier for rustaceans.
Other
2.93k stars 161 forks source link

RFC: 0-copy support for writing reads #650

Open vlovich opened 2 months ago

vlovich commented 2 months ago

If I'm copying from 1 file to another, currently I have to allocate a DmaBuffer & copy_from_slice the ReadResult into the DmaBuffer. @glommer would it make sense to extend DmaBuffer to have a From<ReadResult> trait and extend it's internal storage enum to hold a ReadResultInner? Or is this a bad idea for some reason?

While I'm at it, does it make sense to extend the write method to be generic over some trait to allow the input for the write to be just a plain old byte slice that only needs to outlive the duration of the write?

glommer commented 2 months ago

As long as ownership is clear, I don't see anything wrong with that. By the time it materializes on our side, the kernel is done with it already so there's no risk there.

The second one is more complex. I had issues before with the kernel and us not agreeing with what "the duration of the write" is. The standard poll methods are bad for it, because they don't guarantee that the same buffer is used in two invocations if the write doesn't complete. If we go for a specialized API, may work.

vlovich commented 2 months ago

I'm not sure I follow the explanation about the second case. You're saying the completion event comes back but the kernel keeps using the referenced buffer? I'm sure I'm understanding that wrong because that would apply equally to the DmaBuffer case I would imagine which needs to know when to free the underlying buffer.

It sounds like something more nuanced though because you mention a second write and polling but I'm not familiar enough with io_uring to follow. What do you mean by specialized API?