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 ?
There was a problem hiding this comment.
I'm not sure I fully understand your question. However, the intent here is that end_of_stream_without_message is relevant only if end_of_stream is true; if end_of_stream is false, then the ext_proc server shouldn't look at end_of_stream_without_message at all.
Implements ext_proc filter from [grfc A93](grpc/proposal#484) (internal [design doc](http://go/ext-proc-design-java)).
| - `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.
There was a problem hiding this comment.
We should also send client window updates eagerly if the sidesidestream's window just became 0 or negative, to avoid deadlocks.
There was a problem hiding this comment.
I've added a paragraph to the "Flow Control" section talking about options that implementations should consider, and I'm referring back to that here.
|
As per offline discussion, I've removed the backend_service label from the metrics, because the ext_proc filter will run above load balancing, which means that we don't actually know the leaf cluster in a reliable way. |
7 participants
No description provided.