Raised by review on #891; split out as the known scope cut it was.
In thread-per-core mode the standard dispatch path uses a per-worker client (worker_client()), but a provider key with a tls override resolves through the process-wide PK_CLIENTS cache (crates/aisix-gateway/src/upstream_tls.rs, client_for_provider_key). Requests using such keys share one upstream pool across workers, so their upstream responses can land on a foreign thread and pay the cross-thread wakeup this mode exists to remove. Correctness is unaffected; custom-TLS keys just do not get the locality win.
Why it shipped this way: a per-worker x per-TLS-config client matrix multiplies connection pools (N workers x M configs), and custom-TLS provider keys are the rare path. If this gets picked up: a worker-local cache keyed by ProviderKeyTls for tpc-* threads with the shared cache kept for everything else, plus a bound or eviction so the matrix cannot grow unbounded.
Raised by review on #891; split out as the known scope cut it was.
In thread-per-core mode the standard dispatch path uses a per-worker client (
worker_client()), but a provider key with atlsoverride resolves through the process-widePK_CLIENTScache (crates/aisix-gateway/src/upstream_tls.rs,client_for_provider_key). Requests using such keys share one upstream pool across workers, so their upstream responses can land on a foreign thread and pay the cross-thread wakeup this mode exists to remove. Correctness is unaffected; custom-TLS keys just do not get the locality win.Why it shipped this way: a per-worker x per-TLS-config client matrix multiplies connection pools (N workers x M configs), and custom-TLS provider keys are the rare path. If this gets picked up: a worker-local cache keyed by
ProviderKeyTlsfortpc-*threads with the shared cache kept for everything else, plus a bound or eviction so the matrix cannot grow unbounded.