Skip to content

drpcwire: assemble packets into pooled buffers to drop a receive-path copy#59

Open
shubhamdhama wants to merge 2 commits into
shubham/buffer-pool-for-ringbufferfrom
shubham/ownership-transfer
Open

drpcwire: assemble packets into pooled buffers to drop a receive-path copy#59
shubhamdhama wants to merge 2 commits into
shubham/buffer-pool-for-ringbufferfrom
shubham/ownership-transfer

Conversation

@shubhamdhama

Copy link
Copy Markdown

Receiving a message used to copy its payload twice: PacketAssembler appended each frame into its own backing array, and the ring buffer's Enqueue then copied that array into a pooled buffer. The second copy existed only to move the data into a buffer the consumer could own.

The assembler now takes its buffer from the shared BufferPool and assembles frames directly into it, then hands ownership of that buffer to the completed packet. Enqueue stores the pooled pointer as is, and RawRecv/MsgRecv return the buffer to the pool once the message is consumed. This removes one full copy per received message.

To let ownership flow through the ring buffer, Packet.Data is now a *[]byte instead of []byte. BufferPool moves from drpcstream to drpcwire because the assembler lives in drpcwire and drpcwire cannot import drpcstream. NewPacketAssembler now requires a pool, and the manager passes its shared recvPool to both the stream assembler and the pending invoke-stream assembler.

Every completed packet now holds a pooled buffer, so each path returns it. handlePacket enqueues message buffers and hands ownership to the consumer, and defers Put for control and error packets after their data is read. The manager Puts the buffer after decoding metadata, and after the invoke is consumed; the latter is safe because NewServerStream copies the rpc name out before pdone fires.

Also drop SplitN, which had no remaining users. Stream writes split frames through SplitData directly.

shubhamdhama and others added 2 commits May 30, 2026 14:33
Add a BufferPool backed by sync.Pool that is shared across all streams
within a Manager. The ring buffer now obtains buffers from the pool on
Enqueue and transfers ownership to the caller on Dequeue, which advances
the tail immediately. This removes the two-step Dequeue/Done protocol
and simplifies Close (no longer needs to wait for held buffers).

The pool is a required parameter in the Stream constructor, created once
per Manager and passed to all streams it creates.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
… copy

Receiving a message used to copy its payload twice: PacketAssembler appended each frame into its own backing array, and the ring buffer's Enqueue then copied that array into a pooled buffer. The second copy existed only to move the data into a buffer the consumer could own.

The assembler now takes its buffer from the shared BufferPool and assembles frames directly into it, then hands ownership of that buffer to the completed packet. Enqueue stores the pooled pointer as is, and RawRecv/MsgRecv return the buffer to the pool once the message is consumed. This removes one full copy per received message.

To let ownership flow through the ring buffer, Packet.Data is now a *[]byte instead of []byte. BufferPool moves from drpcstream to drpcwire because the assembler lives in drpcwire and drpcwire cannot import drpcstream. NewPacketAssembler now requires a pool, and the manager passes its shared recvPool to both the stream assembler and the pending invoke-stream assembler.

Every completed packet now holds a pooled buffer, so each path returns it. handlePacket enqueues message buffers and hands ownership to the consumer, and defers Put for control and error packets after their data is read. The manager Puts the buffer after decoding metadata, and after the invoke is consumed; the latter is safe because NewServerStream copies the rpc name out before pdone fires.

Also drop SplitN, which had no remaining users. Stream writes split frames through SplitData directly.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
@shubhamdhama shubhamdhama force-pushed the shubham/buffer-pool-for-ringbuffer branch from a305254 to f5edd92 Compare June 11, 2026 14:50
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.

1 participant