Re: proposal to fix ordering problem in PCI 2.1

["McDonald, Ed" <mcd@msgate.ColumbiaSC.NCR.COM>]

 ----------
> From: Francisco Corella
> To: McDonald, Ed
> Cc: pci-sig-request@znyx.com; larry_shintaku@hp-santaclara-om3.om.hp.com;
> roberts@rosemail.rose.hp.com; zhangc@ecs.ecs.csus.edu;
> ac@rosemail.rose.hp.com; linn@rosemail.rose.hp.com;
> rb@rosemail.rose.hp.com; fcorella@rosemail.rose.hp.com
> Subject: Re: proposal to fix ordering problem in PCI 2.1
> Date: Wednesday, October 30, 1996 8:55PM
>

[my previous comments deleted]

> I'm not quite sure what you mean by "reservation algorithms", but,

I was intentionally being non-specific because system
logic can also use this "information" to have a more
optimized I/O subsystem (re: performance, latency characteristics,
etc.) depending on system designers goals/efforts, etc.

> yes, we were actually planning on addressing the forward progress
> issues later, as a second step.  It is possible to guarantee absence
> of deadlock without master-id, but the rules for ensuring this are not
> quite right in the current spec (completions must be allowed to pass
> requests...), and they could be made more precise.  It is *impossible*
> to guarantee absence of starvation without master-id lines, because a
> target does not know who the master of the transaction is.  With
> master-id lines, the target knows who the master is, and can be fair
> among the masters, making sure that none of them gets starved by the
> others.  It is possible to state precise "fairness constraints" that
> guarantee absence of starvation.

I agree with above comments.

>
> However, we thought it would be easier to deal with one problem at a
> time...

I understand.  I wasn't aware of your plan to later tackle the forward
progress issue.  I'd suggest that keeping the forward progress
problem in mind while addressing the ordering problem could
make easier buy-in, easier implementation efforts, more optimum
performance, etc. of a later forward progress solution.  If the time
between availability of both solutions was short enough, I'd think
most people would prefer to make silicon/system changes once.

Ed McDonald

>
> Francisco
> 
Ü