Network::FilterChain: derived interfaces for upstream and downstream

[lambdai]

@kyessenov is adding filter chain to upstream in #7503
I am adding the functionality to drain certain downstream filter chain as improvement to LDS (also required by future FCDS).

I prefer to add a tag to downstream filter chain as is in listener I don't see this is required by upstream filter chain.

@kyessenov should we split UpstreamFilterChain and DownstreamFilterChain since now?

@mattklein123 WDYT?

[mattklein123]

@silentdai sorry I don't think I grok what you are asking. Can you rephrase?

[lambdai]

Sorry for the unclear and the late reply.
The background is that I am adding the functionality to drain connections owned by a subset of filter chains, instead drain all the filter chains of a listener. This functionality is the fundamental of FCDS. It can be utilized by LDS as well.

I will use LDS as example. The flow is

• A new listener config is published.
• On master thread, ListenerManager determines the filter chains need to be drained. On master thread, the filterchain is identified by FilterChain proto object
• The worker threads execute the drain. The worker has only Envoy::Network::FilterChain which wraps the context and now the worker cannot find which Envoy::Network::FilterChain need to be drained.

I am proposing add a tag() to Envoy::Network::FilterChain. The tag should return a int created by listener. It could be a incremental id or a hash on Filterchain proto.

I doubt if upstream FilterChain need it so I am proposing

• Network::FilterChain as now
• Network::DownstreamFilterChain : Network::FilterChain { int64_t tag(); }
• Network::upstreamFilterChain : Network::FilterChain { /nothing to add at this moment unless Kuat has plan/ }

[lambdai]

lambdai#4 is the example that how I would group connections by FilterChains

As the tag() is missing findGroupByFilterChain is using the address of Network::FilterChain. This highly restricted how Listener/FCDS updates the FilterChain set.

[mattklein123]

I think we can cover this in code review and can move forward in parallel with what @kyessenov is doing if that lands first.

[stale]

This issue has been automatically marked as stale because it has not had activity in the last 30 days. It will be closed in the next 7 days unless it is tagged "help wanted" or other activity occurs. Thank you for your contributions.

[stale]

This issue has been automatically closed because it has not had activity in the last 37 days. If this issue is still valid, please ping a maintainer and ask them to label it as "help wanted". Thank you for your contributions.