On 7/17/2026 4:08 AM, Zhiping Zhang wrote: > On Wed, Jul 15, 2026 at 6:07 PM fengchengwen <[email protected]> wrote: >> >>> >> Hi Zhiping, >> >> One concern I'd like to raise is the implicit topology constraint of the >> TPH P2P path. TPH Steering Tag only works reliably when both importer and >> exporter devices sit under the same Root Port (or same TPH-aware switch). >> >> For cross-Root-Port P2P traffic (e.g. P2P devices located in different >> RC or even socket), most server-grade Root Complexes do not forward TPH >> prefixes through their internal routing. The ST field gets silently >> stripped before reaching the target device, so all TPH setup becomes >> ineffective with no error reported to user. >> >> Because cross-Root-Port P2P traffic with ST does not affect the host, but >> merely the completer may experience some performance degradation because >> it lacks the TPH hint. In this case, I suggest adding restrictions in the >> uAPI. >> >> A further step is to check whether the importer and exporter are under >> the same root port. However, this verification will cause the P2P TPH >> to be unsupported in the case of multi-host or multi-root PCIe switch. >> >> Thanks > > Hi Fengcheng, > > Agreed the RC may not preserve TPH across Root Ports (PCIe Base Spec > r6.4 §6.17.4 requires all intermediate routing elements to support > TPH, and cross-RP forwarding is optional/implementation-dependent, cf. > §2.2.10.4.2). But the uAPI can't gate it: there's no discoverable "TPH > routing" capability -- DevCap2[13:12] (r6.4 §7.5.3.15) describes the > completer, not P2P forwarding -- and a same-Root-Port check would > wrongly reject switch and multi-root topologies where ST does forward. > > And it's harmless anyway: per r6.4 §2.2.7.1 an element without TPH > support ignores the TH bit and completes as if unhinted, so a stripped > ST just degrades to the non-TPH baseline.
Thank you for your detailed explanation. I agree to maintain the current implementation. Thanks > > Thanks, > Zhiping >
