Origin and underlying sense of the term "Posted" in PCIe

Question

When PCI Express replaced the operation of reading directly from a PCI peripheral card over a bus, directly addressing its I/O ports, or performing a configuration cycle on it directly, with instead a so-called split-transaction protocol allowing a variable delay as the details of the requested operation and its outcome progressed from point to point to point through various instances of flow control, it introduced some terminology for these concepts:

• "posted" requests, which simply propagate and carry their effective imprint on the computational universe along with them as they go, and
• "non-posted" requests that are known to have had any effect only somewhere between the sending of the request and the ultimate receipt of a return reply (bounded by any posted requests traveling ahead of them).

Whenever I'm looking at an operation to be implemented as either a posted or a non-posted transaction, I often find myself trying to mentally link the concept to its underlying physical metaphor. And that's the point where I always realize I'm not entirely sure what the metaphor was that led to the choice of the term "posted" (and consequently "non-posted") or what I really ought to be envisioning.

Obviously it's either (a) the idea of, say, putting something up on a signpost, message board, etc., where once it's up everyone can see it, or (b) dropping a letter into a letterbox, where once you've dropped it off it's in someone else's trusted hands and out of yours. Either metaphor seems roughly equally viable to me for various reasons, without either one being at all a clear slam dunk.

So I was wondering, is there anyone who was present at the creation of the then "next generation I/O", i.e. PCIe 1.0, who has some knowledge, awareness, or evidence of what was in the minds of the spec writers when this terminology was introduced?

Or was it adopted from some other source (and if so, from where)?

It would genuinely ease my thought processes (if only a little) to know if one of these two metaphors should be considered "cannon". :)

I see that this question was essentially asked here, as the author of that question went so far as to articulate that they were asking for an etymology for the term, but the only responses mostly just contained the usual 'splaining of what the OP had explicitly said they already understood, with one responder musing on one of the two viable etymologies I mentioned above. Here I'm being very explicit that a choice between two specific potential etymologies is in my view obvious, and that I'm specifically asking about first-, second-, or third-hand evidence of PCI-SIG members' motivation or intent at the time.

Answer 1

Having previously worked on embedded systems using hardware designed in the late '90s with PowerPC processors which uses a mixture of PCI and VME buses, I remember the concept of posted writes existed for such systems. I.e. one example which pre-dates PCI Express.

Looking for a sample of documentation for products of that vintage:

1. The MCP750 Series Single Board Computer Programmer’s Reference Guide shows mention of posted writes PCI and PowerPC buses:

   • PPC Write Posting

     The PPC write FIFO stores up to eight data beats in any combination of single and burst transactions. If write posting is enabled, Raven stores the data necessary to complete an PPC write transfer to the PCI bus and immediately acknowledges the transaction on the PPC bus. This frees the PPC bus from waiting for the potentially long PCI arbitration and transfer.

   • PCI Write Posting

     If write posting is enabled, the Raven stores the target address, attributes, and up to 128 bytes of data from one PCI write transaction and immediately acknowledges the transaction on the PCI bus. This allows the slower PCI to continue to transfer data at its maximum bandwidth, and the faster PPC bus to accept data in high performance cache-line burst transfers. The PPC bus may be used for more useful work while the Raven manages the completion of the write posted transaction on PCI.

2. From GE Fanuc’s Tundra Universe II™ Based VMEbus Interface User’s Manual:

   PCI/VMEbus Deadlock

   There is a deadlock scenario which is inherent to systems containing a PCI/VME interface. The PCI specification allows for and defines devices called bridges. A bridge could be a host bridge which interfaces a host CPU to the system PCI bus. Another type of bridge is the PCI-to-PCI bridge which bridges two different PCI buses.

   In order to optimize system performance, PCI specification allows bridges to provide buffering. Almost all host bridges and PCI-PCI bridges contain write-posting buffers. These buffers allow writes from one side of the bridge to be acknowledged before the data is actually written to the other side of the bridge.

   Without write posting, the CPU or PCI initiator would have to wait for the device that is receiving the data to acknowledge the data transfer before it could proceed to the next bus transaction. In addition to allowing for write posting, the PCI bridge specification imposes transaction ordering rules on the bridge design to ensure data consistency in the system. These ordering rules are imposed on host bridges and on PCI-to-PCI bridges. One ordering rule is that reads cannot traverse across a bridge until all write-posted data has been flushed. In a PCI/VME system, this ordering rule coupled with the lack of retry on the VMEbus create the potential for system deadlocks.

I wasn't involved in the creation of PCI Express, but given the above shows write posting was previously defined for PCI, that is probably the original for PCI Express. I haven't looked for the source of the terminology for the PCI specification.