As far as I understand, in Monterey, we have discussed to make the
range of sequence identifier fairly larger than the range of
MAX_TASK_SET_SIZE to make it possible for target to determine, from
the sign of distance between two sequence identifiers (target is
expecting and specified by initiator), whether initiator is
synchronized, behind by missing packet or ahead by Abort Task.
The fairly large range of sequence identifier may not be enough for
the target to handle the gap between sequence identifiers caused by
Abort Task because the gap may infinitely grow.
The initiator is already limiting the number of ORB's not to exceed
maximum reorderable number.
By making this condition a little severe, I think we can avoid
unrecoverable situation without retry interaction between initiator
The descriptive condition will be as follows;
The initiator limits
the number of ORB's not to exceed maximum reorderable number,
to append the ORB that has sequence identifier target can identify
as ahead from last completed one.
If there is no outstanding ORB for the queue, the initiator appends
ORB that has sequence identifier adjusted to the next number of last
The conditional expression will be as follows;
IF ((Number of outstanding ORB for the queue)
<= (MAX_TASK_SET_SIZE - n))
((((appending sequence id)-(last completed sequence id)) MOD (2^m))
THEN append ORB with (appending sequence id)
IF ((Number of outstanding ORB for the queue) = 0)
THEN adjust (appending sequence id) to (last completed sequence
id) + 1 and append ORB,
where "n" is room for another queue, and "m" is number of bit of
If the target finds initiator is ahead, target can simply update
recorded identifier with the new value specified by the initiator.
So, I do not think the following policy (and so on) is necessary.
> A) A target shall enforce sequential command tag values.
Am I missing something?
-- Akihiro Shimura (email@example.com) Office Imaging System Promotion Project CANON INC.