gRFC L1: C++ streaming coalescing API's

[Craig Tiller]

I've opened a gRFC allowing for coalescing of writes for streaming RPC's from our C++ API here: https://github.com/grpc/proposal/pull/2

Please keep any discussion on this thread.

[Louis Ryan]

How is this logically different from per-stream 'corking' ? We want the ability to coalesce the writes for groups of messages on a stream, not just the head and tail of a stream, it seems like a generic cork mechanism can cover headers and trailers too

On Fri, Jan 13, 2017 at 5:19 PM, 'Craig Tiller' via grpc.io <grp...@googlegroups.com> wrote:

I've opened a gRFC allowing for coalescing of writes for streaming RPC's from our C++ API here: https://github.com/grpc/proposal/pull/2

Please keep any discussion on this thread.

--
You received this message because you are subscribed to the Google Groups "grpc.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email to grpc-io+unsubscribe@googlegroups.com.
To post to this group, send email to grp...@googlegroups.com.
Visit this group at https://groups.google.com/group/grpc-io.
To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/CAAvp3oOjheoTeibLGs8GapupvM_gjDJPu9Oq0dTMbzGbJ0mRiw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Craig Tiller]

We don't currently have a cork for initial metadata, but we could get one by just adding a WriteOptions to the stub stream constructors: that would be the minimal change.

Most of the rest of this could be seen as syntactic sugar to help guide developers into doing the cheaper thing vs the more expensive thing.

Implementation wise, this also gives us the ability to traverse the core stack once instead of twice for a corked write. Likely only a win for very high qps applications (the win is measured in low numbers of microseconds), but we're starting to see some that would appreciate it.

On Fri, Jan 13, 2017, 5:29 PM Louis Ryan <lr...@google.com> wrote:

How is this logically different from per-stream 'corking' ? We want the ability to coalesce the writes for groups of messages on a stream, not just the head and tail of a stream, it seems like a generic cork mechanism can cover headers and trailers too

On Fri, Jan 13, 2017 at 5:19 PM, 'Craig Tiller' via grpc.io <grp...@googlegroups.com> wrote:

I've opened a gRFC allowing for coalescing of writes for streaming RPC's from our C++ API here: https://github.com/grpc/proposal/pull/2

Please keep any discussion on this thread.

--
You received this message because you are subscribed to the Google Groups "grpc.io" group.

To unsubscribe from this group and stop receiving emails from it, send an email to grpc-io+u...@googlegroups.com.

[Craig Tiller]

Proposal was moved to https://github.com/grpc/proposal/pull/3 (due to some github forking issues).

[Craig Tiller]

+Abhishek Kumar 

Responding to Abhishek's review comments in the comment thread:

> I am not sure we want all these additional convenience methods. The pro of course is that it these concepts are elevated to the top level in the API. But the con is that the API loses more orthogonality and there are to many ways of accomplishing the same thing. This applies to all the convenience methods in this proposal.

For WriteLast at least we also gain the ability to send down a single batch (SEND_MESSAGE + SEND_CLOSE_ON_CLIENT). Without such, implementation options become:

• elevate WRITE_BUFFER_HINT to C++ (and lose the ability to write opportunistically if we're writing anyway)
• force two round trips through the core stack

Both imply some penalty *and* are a harder to discover API.

> Per previous discussion, I would recommend adding an option either to the context or the initial metadata send that signals the same buffer-hint that we have in the write options.

I've added such overloads to head.

[Craig Tiller]

Abhishek and I spoke, and decided to simplify the initial message path.

I've updated the PR with https://github.com/grpc/proposal/pull/3/commits/98f50fe1bde9e8209d08c2afd4317c6f609d823a.