On Wed, May 27, 2026 at 5:53 AM Christian König <[email protected]> wrote: > > > > On 5/27/26 14:36, Jason Gunthorpe wrote: > > On Wed, May 27, 2026 at 02:23:46PM +0200, Christian König wrote: > > > >> Yeah that's a good point, I should probably rephrase the question. > >> > >> I'm aware of how TPH works by adding the extra ST to the TLP. > >> > >> But my question is how is that useful to a PCIe endpoint? What is the > >> effect of the ST here? > > > > TBH I've never heard Meta explain what their device is doing with > > it. At least it seems to be super important to their device.. > > Yeah I think at least a brief description of what is going on here would be > necessary for the review. > > Otherwise we have only the info that the exporter wants to give an opaque ST > for the importer to use and no technical description what that is good for, > how to test it etc... > > Regards, > Christian. > > > > > Jason >
Fair point — I'll add a couple of paragraphs to the v6 cover letter and the patch's changelog as well. The short version: in this series the vfio-pci device is the completer of the P2P writes and mlx5 is the requester. As Jason noted, ST semantics on the completer are implementation-defined, so only the driver that owns the completer (here, vfio-pci on behalf of its userspace owner) can hand out a meaningful ST; the importer treats it as opaque and just places it on the TLP. Validation occurs at two levels: PCIe analyzer captures on P2P TLPs, and the end-to-end P2P workload yields only expected results. Thanks, Zhiping
