-
Notifications
You must be signed in to change notification settings - Fork 5.3k
stream info: propagate downstream filter state to upstream #19668
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -129,7 +129,7 @@ class CodecClient : protected Logger::Loggable<Logger::Id::client>, | |
| CodecType type() const { return type_; } | ||
|
|
||
| // Note this is the L4 stream info, not L7. | ||
| const StreamInfo::StreamInfo& streamInfo() { return connection_->streamInfo(); } | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Your PR description says Matching downstream L7 streams with upstream L4 connections seems like it's going to be problematic. Is that what you're intending to do? I would think that we'd want to match stream to stream, in case multiple L7 streams went out over one virtual connection.
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Hmmm, this is a very good point. I think this PR needs more thought actually. L4 connections from downstreams are not strictly one-to-one with L4 upstream connections so it's not right to use either L4 or L7 filter state here. I tend to think that the import of filter state must also be explicit like in #19435. That way the hash policy determines the grouping of downstream L4/L7 stream filter states. |
||
| StreamInfo::StreamInfo& streamInfo() { return connection_->streamInfo(); } | ||
|
|
||
| protected: | ||
| /** | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think if we end up going this route we're going to want to be awfully clear that this is downstream L7 filters and upstream L4 filters.
I also wonder if instead of adding another set of accessors, if there would be a way to tag information that's added as "information that should be communicated to upstream stream info" WDYT?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, this is more confusing than helpful. I think an explicit export is probably better (either in the filter state itself or in the transport socket).