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. Thanks, Zhiping
