On Wed, Oct 30, 2024 at 03:20:02PM -0600, Logan Gunthorpe wrote: > On 2024-10-30 12:46, Bjorn Helgaas wrote: > > On Fri, Oct 25, 2024 at 06:57:37AM +0000, Kasireddy, Vivek wrote: > > In the PCIe world, I don't think a TLP can "loop back" to another > > function on the same device. > > I'm not sure if the spec says anything that specifically denies this. I'm not a hardware guy and I don't know if there's a direct statement about it, but if a Downstream Port supports ACS, it must support ACS P2P Request Redirect (PCIe r6.0, sec 6.12.1.1), which specifically applies to peer-to-peer TLPs. If peer-to-peer TLPs appear on the link, the Downstream Port will see them and act on them, e.g., either route them upstream (if P2P Request Redirect is enabled) or back downstream. I don't think the VF could act on them directly via a loopback path because that would lead to duplicate writes and duplicate Completions for reads. > But it seems to me that it would be possible for a multifunction device > to handle a transfer to a neighbouring function internally and not > actually involve the PCIe fabric. This seems like something we'd want to > support if and when such a device were to be created. If peer-to-peer transactions are handled internally, an SR-IOV device other than an RCiEP is required to support ACS with P2P Egress Control (sec 7.7.11) and P2P Request Redirect (sec 7.7.11.2). Bjorn
