On 14/03/18 06:16 AM, David Laight wrote: > That surprises me (unless I missed something last time I read the spec). > While P2P writes are relatively easy to handle, reads and any other TLP that > require acks are a completely different proposition. > There are no additional fields that can be set in the read TLP and will be > reflected back in the ack(s) than can be used to route the acks back to the > correct initiator. > > I'm pretty sure that to support P2P reads a switch would have to save > the received read TLP and (possibly later on) issue read TLP of its own > for the required data. > I'm not even sure it is easy to interleave the P2P reads with those > coming from the root. > That requires a potentially infinite queue of pending requests. This is wrong. A completion is a TLP just like any other and makes use of the Destination ID field in the header to route it back to the original requester. > Some x86 root ports support P2P writes (maybe with a bios option). > It would be a shame not to be able to do P2P writes on such systems > even though P2P reads won't work. Yes, and this has been discussed many times. It won't be changing in the near term. Logan -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
