It is still not clear for me what is specified for initiator and/or
target by these parameters.
Size of the "buffer" referred by data_descriptor field of an ORB will
be determined along with requesting client of the initiator. Once the
ORB is appended to task list, access right to the "buffer" is granted
to the target, and the "buffer" looks like (remote) receiving/sending
buffer of the target. The target can access any part of the "buffer"
within the address range of the "buffer" in arbitrary size unit the
target wants to handle.
I think the size of the "buffer" referred by the ORB and the size
unit that target processes the "buffer" are independent of each other.
Could you explain why these parameters need to go across the wire?
Akihiro Shimura
On Mon, 20 Jul 1998 10:05:11 -0700 (PDT)
Greg Shue <gregs@sdd.hp.com> wrote:
>
> Grettings all,
>
> As I have thought about many of the issues and simplifications
> discussed at the July PWG 1394 meeting, I have tried to create
> an overview of the resulting command set. Before I start modifying
> the Command Set proposal, I would like to hear any concerns you have
> with the revisions. The overview follows. Please respond with
> any feedback before Friday 7/24/98. I will try to have the
> revised Command Set proposal ready by 8/5/98. (I cannot have
> it ready a full 2 weeks before the August meeting.) Thank you
> for your feedback.
>
>
> PWG SBP-2-based Transport Command Set
> 7/20/98
>
> With:
> - the restrictions imposed by the Microsoft SBP-2 implementation
> - the desire from Randy Turner (Sharp) for Open & Close commands
> - the removal of Vendor-specific extension mechanisms
> - the relabeling of commands with more descriptive names
>
> the command set transforms into:
>
> TRANSPORT_STATUS {GET_PARAMETER w/ all params tags}
>
> Only valid on T2I data queue, only valid
> when in an Unopened Connection state.
>
> TRANSPORT_OPEN {SET PARAMETER LIST w/ all settable parameters}
>
> Contains all "Negotiated" parameter values.
> Only valid on I2T data queue, only valid
> when in an Unopened Connection state.
>
> TRANSPORT_CLOSE {SET PARAMETER LSIT w/ only Mode parameter}
>
> Closed direction inferred from queue_id bit.
> Valid on both queues. Invalid only in the
> UnOpened Connection state.
>
> TRANSPORT_I2T_DATA {FETCH_DATA}
>
> Valid only on I2T data queue. Valid only
> in the Opened Connection state. Valid only
> while the queue is open.
>
> TRANSPORT_T2I_DATA {STORE_DATA}
>
> Valid only on T2I data queue. Valid only
> in the Opened Connection state. Valid only
> while the queue is open.
>
> the Command Set Model of Use becomes:
>
> Login event ----> UnOpened Conn [ TRANSPORT_STATUS is OK
> | TRANSPORT_OPEN is OK
> | All other cmds is ERROR ]
> _______________________|
> |
> +-- TRANSPORT_OPEN -> Opened Conn [ TRANSPORT_STATUS is ERROR
> | ^ ^ TRANSPORT_CLOSE is OK
> | | | TRANSPORT_I2T_DATA is OK if
> | | | I2T direction is Open
> | | | TRANSPORT_T2I_DATA is OK if
> | | | T2I direction is Open
> | | | TRANSPORT_OPEN is ERROR
> _______________________| | |
> ||| | |
> ||+- TRANSPORT_CLOSE (I2T) + |
> || && T2I still open |
> || |
> |+-- TRANSPORT_CLOSE (T2I) --+
> | && I2T still open
> |
> +- TRANSPORT_CLOSE -> Closed Conn [ TRANSPORT_STATUS is ERROR
> | I2T & T2I closed TRANSPORT_CLOSE is OK
> | TRANSPORT_I2T_DATA is ERROR
> | TRANSPORT_T2I_DATA is ERROR
> +---> Logout TRANSPORT_OPEN is ERROR
>
> The variables associated with TRANSPORT_STATUS become:
>
> A) MAX_TASK_SET_SIZE (16 bits unsigned int,
> 2 is minimum;
> 2^14-1 is maximum)
> B) MAX_I2T_DATA_SIZE (31 bits unsigned int)
> C) MAX_T2I_DATA_SIZE (31 bits unsigned int)
> D) STREAM_COMPLETION ( 8 bits unsigned int)
> E) CONNECTION_STATE ( 2 bits unsigned int
> 0 => I2T CLOSED, T2I CLOSED;
> 1 => I2T OPEN, T2I CLOSED;
> 2 => I2T CLOSED, T2I OPEN;
> 3 => I2T OPEN, T2I OPEN;)
>
> The target needs to communicate the following specific events
> to the initiator even in the case that no commands are queued.
>
> - UNIT ATTENTION: logical unit was reset outside of this Login
>
> - Target has closed a communication direction and will reject
> further TRANSPORT_?2?_DATA commands for that direction.
> When all directions are closed, then target is should
> Logout ASAP. (The target shall only successfully execute
> TRANSPORT_STATUS commands.)
>
> Since an initiator can not leave a TRANSPORT_T2I_DATA command
> enqueued when the T2I direction is closed, this data must be
> communicated via the Unsolicited Status mechanism. Also, since
> an Initiator may not even exist on the bus (due to a transient
> link interruption) when either of these events happens, they
> must be buffered.
>
>
> Now, error recovery for when a target detects an ACK Timeout on a
> Status FIFO write requires some special considerations. When
> this condition happens the initiator and target may be
> out-of-sync with each other, and the SBP-2 protocol does not
> provide a mechanism for the initiator to determine that the
> condition exists. The problem breaks down to two issues:
>
> Initiator Detection:
> Because this condition is expected to happen _extremely_
> infrequently, it is expected that a Bus Reset mechanism
> is a reasonable way of forcing the initiator to resynchronize
> with the target.
>
> Recovery:
> To recover from this condition, the target needs to infer
> whether or not the initiator received the completion notification(s).
>
> If the initiator did, the target may release the resources
> or take the appropriate action assocaited with the command(s).
>
> If the initiator did not, the target must determine whether
> or not the same command (sequence, and associated data) is
> restored to the execution queue.
>
> If the same sequence is not restored to the front of the
> queue, then the target should ignore all previous commands
> and re-execute them.
>
> If the same sequence is restored, then the target need
> not reprocess the entire command and data block. It
> simply needs to know where it left off within the
> transfers.
>
> This makes it reasonable to employ a command tag, used to
> uniquely identify each previously active command within the
> implicilty aborted task set, and new commands which were not
> in the previously active task set.
>
> Unfortunately, SBP-2 requires targets to support the ABORT TASK
> function, and the process described for aborting tasks causes
> previously valid commands to be turned into Dummy ORBs. This
> effectively removes the command tag from the ORB, so the
> queue's Execution Agent no longer sees command tags as
> sequential even if they were assigned sequentially.
>
> It may be reasonable for a target to enforce seeing
> sequential command tags in order to recover from this
> situation. If the queue's Execution Agent completed
> all commands in that queue with a status of "ABORTED -
> UNEXPECTED COMMAND TAG VALUE", then the initiator has
> a chance to recover from the situation. This also means
> that an ABORT TASK function causes all successive commands
> on the associated queue to be aborted without affecting
> the other queue.
>
> This brings us to the following policies:
>
> A) A target shall enforce sequential command tag values.
> B) Initial command tag values shall be established by the
> first command placed on each queue.
> C) ABORT TASK shall indirectly cause the rest of the
> command queue to be aborted without affecting
> the other command queue.
> D) Initiators shall retire a command tag until
> it receives a successful completion notification
> for a following command on the associated queue.
> Once that following successful notification has
> been received, the command tag may be reused.
> E) Targets shall invalidate a command tag when
> the completion notification for the associated
> ORB has been succesfully acknowledged.
>
> These policies allow the target to use the algorithm below
> to recover synchronization:
>
> If the target is not in a missing status FIFO ACK error
> recovery situation, it shall examine the command at the
> head of the queue and:
>
> process it if it is either the first command enqueued
> on this queue since Login, or has a command tag immediately
> following the one of the last successfully completed command.
>
> otherwise, abort it.
>
> If the target is in a missing status FIFO ACK error
> recovery situation, it shall examine the command at the
> head of the queue and:
>
> If the command tag matches the one of the unacknowledged
> command, it shall make sure the command is processed and
> resend the completion notification.
>
> Else if the command tag follows the one of the
> unacknowledged command, it shall ASSUME the completion
> notification was successfully received by the initiator
> and that the ACK transmission was lost. The pending
> command shall be implicilty acknowledged by the new
> command, and completed by the target.
>
> Else the target shall abort it.
> --
> Greg Shue
> Hewlett-Packard Company
> All-in-One Division gregs@sdd.hp.com
> ----------------------------------------------------------------
>
-- Akihiro Shimura (shimura@pure.cpdc.canon.co.jp) Office Imaging System Promotion Project CANON INC.