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

Support appending foreign buffers to pipe without copy #25848

Open
tmds opened this issue Apr 11, 2018 · 2 comments
Open

Support appending foreign buffers to pipe without copy #25848

tmds opened this issue Apr 11, 2018 · 2 comments
Labels
area-System.IO.Pipelines enhancement Product code improvement that does NOT require public API changes/additions
Milestone

Comments

@tmds
Copy link
Member

tmds commented Apr 11, 2018

Moved from dotnet/corefxlab#2031

Foreign buffers are buffers not allocated with the Pipe MemoryPool.

Use-cases (by @Drawaes @mgravell @ReubenBond)

  • Send the same data to multiple Pipes
  • Pass existing data that is not related to pipelines
  • Embed existing data (e.g. add header)

With the current API, these buffers are copied into buffers owned by the Pipe MemoryPool:

Challenges:

  • The buffer usage needs to be tracked in order to know when it can be re-used.
  • some Transports (e.g. RIO) may not be capable of sending foreign buffers. They should detect this and copy the data in an appropriate buffer.

CC @davidfowl

@Drawaes
Copy link
Contributor

Drawaes commented Apr 18, 2018

One factor to consider is that the use case I have most of the time will not be a "foreign" buffer it will be from the same pool just a different pipe. So it should be fine in the RIO case.

Also we managed to sneak in some changes to pipelines that will allow a buffer to identify it's pool in the final API reviews before lockdown.

@msftgits msftgits transferred this issue from dotnet/corefx Jan 31, 2020
@msftgits msftgits added this to the Future milestone Jan 31, 2020
@maryamariyan maryamariyan added the untriaged New issue has not been triaged by the area owner label Feb 23, 2020
@BrennanConroy BrennanConroy removed the untriaged New issue has not been triaged by the area owner label Jul 8, 2020
@BrennanConroy
Copy link
Member

From #32894:

This API would allow a user to insert their own buffer into a PipeWriter's stream.

This allows a PipeWriter to be truly zero-copy for such a scenario, while currently they must copy their buffer into the PipeWriter's internal buffer. An example might be a block of pre-serialized data that a user might reuse throughout a stream's lifetime. The transport implementation could then take the resulting sequence of the PipeWriter's own buffers and the user's buffers and perform a gathered write to the socket.

class PipeWriter
{
    // Allocate a reusable block that is guaranteed to be zero-copy if passed to AppendBuffer().
    public virtual IMemoryOwner<byte> GetReusableMemory(int length);

    // If the buffer is compatible with the pipe writer's needs, use the buffer directly. Otherwise, do an implicit GetSpan()+Copy()+Advance().
    // ValueTask completes once the buffer is no longer in use by the PipeWriter.
    // Unlike WriteAsync, does not flush.
    public virtual ValueTask AppendBufferAsync(ReadOnlyMemory<byte> buffer);
}

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area-System.IO.Pipelines enhancement Product code improvement that does NOT require public API changes/additions
Projects
None yet
Development

No branches or pull requests

5 participants