Re: legality of interleaving untagged message segments

At 11:24 PM 5/17/2004, Caitlin Bestler wrote:

>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.

I willing to make this a MUST NOT and address this in a future version of 
the spec should the optimizations be publicized.

Mike