Re: legality of interleaving untagged message segments
"Caitlin Bestler" <[email protected]>
| Newsgroups | gmane.ietf.rddp |
|---|---|
| Message-ID | <[email protected]> |
Michael Krause said: > > Within a given LLP stream, you are correct that the optimization benefits > may be minimal if I/O device is somewhat "distant" (read as relatively > high > latency) from the memory controller. However, as we see the industry move > towards PCI Express (PCIe) and with the potential to create more > integrated > memory controller chipsets, there may be greater benefit over time > (especially with some architectures moving to be more NUMA oriented). > > Given this may take time to occur and validate, would you be willing to > make this a SHOULD NOT instead of a MUST NOT thus allowing leeway for > future development while providing strong guidance that such interleaving > is strongly discouraged? > > Mike > There is already a SHOULD that segment SHOULD be submitted in ascending order. So no further SHOULD clause is required. Or for that matter useful. A "SHOULD NOT 'X'" clause does not truly allow the receiver to optimize on the assumption that senders will not do X. It just discourages testing of 'X', so in a sense it's worse than doing nothing. Receivers are not free to optimize, and senders are discouraged from whatever optimization there might be. My assumption is that the MUST NOT I am proposing will not preclude any achievable optimization on the sender side. If that assumption is correct then benefit to the receiver is clearly preferable. But if anyone had an algorithm that really would optimize across message boundaries and gain actual benefits from it then the tradeoff is indeed more complex. The benefit at the receiver side, for an implementation that defers placement processing of DDP segments until they can be processed in order, is that there would be at most one active untagged buffer per DDP Stream. This is a major benefit, which I believe outweighs the theoretical benefits that some unidentified sender algorithm *might* achieve in the future. Of course I am willing to be convinced to the contrary if someone were to present a contemplated optimization that this restriction would interfere with. Or for that matter, even assert that they are researching such an algorithm that they are unwilling to disclose.