A93: xDS ExtProc Support#484
Conversation
| control back to the sender) until its corresponding write has passed | ||
| flow control. For example, for path (1) above, when reading client | ||
| messages from downstream, the filter will not release flow control back | ||
| to the downstream until its write to the ext_proc sidestream has cleared |
There was a problem hiding this comment.
What does until its write to the ext_proc sidestream has cleared flow control. mean? Does it mean until we have written that message to side stream or does it mean until we have received window update for that message?
There was a problem hiding this comment.
We don't actually have to have it fully written to the sidestream, but we do have to have allocated enough flow control to send it at both the ext_proc layer and the HTTP/2 layer.
I've attempted to clarify the wording here.
| DATA frames as HTTP/2 does, which would allow making incremental | ||
| progress. | ||
|
|
||
| The initial window sizes for all four paths are set by the filter in |
There was a problem hiding this comment.
Where are FlowControlInit initial window sizes to be set by the filter taken from? Should we add them to GrpcService config?
There was a problem hiding this comment.
I think each data plane implementation needs to figure this out on its own. A simple implementation would be to just use hard-coded values. But data planes may ultimately want some mechanism to dynamically tune these values when they are under memory pressure. In C-core, we plan to eventually use our ResourceQuota mechanism to do that.
I don't think it's appropriate to set these values from the control plane, because the control plane cannot know how much memory pressure a given data plane is under.
| For client messages, may be true if the client sent a half-close at | ||
| the same time as the last message. For server messages, will always | ||
| be false. | ||
| - end_of_stream_without_message (new field being added in |
There was a problem hiding this comment.
Is there a restriction here too similar to response received by the proc server that EOS without message should be set to true along with EOS and EOS should not be false if EOS without message is true ?
Implements ext_proc filter from [grfc A93](grpc/proposal#484) (internal [design doc](http://go/ext-proc-design-java)).
| will first wait until it has allocated enough ext_proc flow control to | ||
| send the message on the sidestream and then wait for the write to the | ||
| sidestream to clear flow control at the HTTP/2 layer for the sidestream, | ||
| and only then will it release flow control back to the downstream. |
There was a problem hiding this comment.
For path (1) it is clear how the flow control for the downstream application should be held back until the write to the side stream has completed. What about path (4)? There seems to be 2 ways of doing this - either at the transport level by accumulating request(int) messages until there are no outstanding ProcessingResponses for response bodies yet to be delivered to the downstream application, or by deferring sending the ClientWindowUpdate for path (4) to ext-proc. Which one should we implement? The first approach has deadlock risk.
| - `client_window_update` (new field being added in | ||
| https://github.com/envoyproxy/envoy/pull/45509): Normally, whenever the | ||
| filter reads a request body chunk from the ext_proc side-stream, it will | ||
| send a window update setting the |
There was a problem hiding this comment.
We probably want to accumulate window updates and only send eagerly when at least half the initial window can be returned. That allows batching of the window update and greatly extends the amount of time available to piggy-back on an already-being-sent processing request.
7 participants
No description provided.