Subject: Re: CAP TODO: single threaded

From: [email-masked]
Date: Thu, 15 Nov 2001 12:09:40 -0500

Doug responded:
>                        I always said if the CUA
>does not want to wait, it can cancel the request.

This does not work if the CS does not read the 'cancel' request off the 
wire, your "(b)" case.  The CUA has no way to cancel the command in 
progress unless the CS does read the requests off the wire and 'queues' 
them up (a variant of your "(b.1)" which allows a command cancellation to 
have a higher priority than other commands that would be pended.)

Bruce
===========================================================================
Bruce Kahn                                INet: [email-masked]
Iris Associates                          Phone: 978.392.5335
Westford, MA, USA 01886                    FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...

---

From: Doug Royer <[email-masked]>
Date: Thu, 15 Nov 2001 14:10:53 -0700

[email-masked] wrote:
> wire, your "(b)" case.  The CUA has no way to cancel the command in > progress unless the CS does read the requests off the wire and 'queues'
> them up (a variant of your "(b.1)" which allows a command
> cancellation to have a higher
> priority than other commands that would be pended.)

I think we agree. If the CS has PIPELINE set to '1', then
the CS is telling the CUA it is not going to read the request
until the current command is completed.

Maybe we should say that in CAP: In order to support bound latency
then PIPELINE MUST BE set to '2' or higher. If the CS can not
support this, you can't use bound latency. This is not a new
restriction, it just describes the issue.

-Doug