Hashing in xDS

[ohadvano]

Will appreciate help figuring out if I understand the hashing purpose of xDS correctly. IIUC, the idea of doing this hashing, is to optimize in cases where the remote xDS server may send the same configuration as already exists in Envoy. In that case, by hashing, we're able to guarantee that the config is the same, and skip the work of modifying the underlying resource. Are there other reasons to use hashing for xDS config consumption purposes?

cc @htuch, @adisuissa

[adisuissa]

For an xDS resource I think it is also being used to avoid re-ingesting that resource if it hasn't changed. Specifically this is useful for SotW.

[ohadvano]

If I can trust the xDS server I am communicating with, will never send config object unless there was indeed an update, does it make sense to optimize the flow by not doing the hashing operation? We observed that the hashing may take high percentage of the overall config update latency, and I'm thinking that we could have an option flag to optimize this by not hashing (if specified by xDS config, by default - do hash)

[ohadvano]

If the suggestion above makes sense as an optional consumer optimization, can we please mark this issue as "Help wanted"? I'll try to follow up on this

[kyessenov]

I think the idea makes sense, but making it work would require plumbing through the consumption sites of xDS. Some of this hashing/diffing happens later, e.g. during structural comparison of filter chains. My suggestion is to start small, and focus on the specific config that is causing too much CPU in hashing.