QUIC_STREAM_EVENT_SEND_COMPLETE should include the number of buffers sent
Describe the feature you'd like supported
It would be nice if the event data of QUIC_STREAM_EVENT_SEND_COMPLETE contained the number of buffers (count) that were initially passed into StreamSend.
Proposed solution
This would make it easier to build zero-copy implementations when send buffering is disabled so that data can be freed easily after sending has completed.
Additional context
No response
StreamSend has a context pointer parameter that MsQuic passes back in the QUIC_STREAM_EVENT_SEND_COMPLETE event, is that insufficient for tracking the number of buffers in the send?
StreamSendhas a context pointer parameter that MsQuic passes back in theQUIC_STREAM_EVENT_SEND_COMPLETEevent, is that insufficient for tracking the number of buffers in the send?
For my specific use case, I’m utilizing the existing context by allocating an additional struct on the heap. This struct retains the count of buffers I’m sending and provides references to those buffers. This allows me to return them to my memory pool once the sending process is complete. If the event data contained the number of sent buffers, I could simply set my buffer array as the context and iterate with a known count, thereby avoiding the allocation of 16 bytes per send.
We’re running msquic in an environment where allocations are painfully slow so keeping them out of hot paths is ideal.
Well, it should be quite easy to do this, as the code that sends the completion event already has the request context which has this information:
QUIC_STREAM_EVENT Event;
Event.Type = QUIC_STREAM_EVENT_SEND_COMPLETE;
Event.SEND_COMPLETE.Canceled = FALSE;
Event.SEND_COMPLETE.ClientContext = Req->ClientContext; // TODO: Also pass the Req->BufferCount along
QuicTraceLogStreamVerbose(
IndicateSendComplete,
Stream,
"Indicating QUIC_STREAM_EVENT_SEND_COMPLETE [%p]",
Req);
(void)QuicStreamIndicateEvent(Stream, &Event);
@andrewmd5 if you are interested, we would welcome a contribution!