Question: Deferred Sense reporting priority

Jeff Stai stai at Brocade.COM
Mon May 4 11:03:16 PDT 1998


* From the T10 (formerly SCSI) Reflector (t10 at symbios.com), posted by:
* Jeff Stai <stai at Brocade.COM>
*


On Monday, May 04, 1998 10:28 AM, Joseph C. Nemeth
[SMTP:jnemeth at concentric.net] wrote:
> * From the T10 (formerly SCSI) Reflector (t10 at symbios.com), posted by:
> * "Joseph C. Nemeth" <jnemeth at concentric.net>
> *
> Like Terry, I'm in the process of implementing a high-level protocol,
and I
> have a question regarding Unit Attention in a fibre-channel fabric
> environment.
> 
> My understanding of the Unit Attention condition is that it is posted
on a
> per-initiator basis. That is, if there are multiple initiators on a
SCSI
> bus, and a device powers up, each initiator should see the PON Unit
> Attention condition (the first initiator to poll the device should not
clear
> Unit Attention for other initiators). In fact, some of the Unit
Attention
> conditions (Mode Page parameter changes, for example), are ONLY posted
for
> initiators other than the one which performed the Mode Select, which
is
> pretty useless if any initiator can clear the Unit Attention condition
for
> all the rest of the initiators.
> 
> In the SCSI-2 environment, implementation could be done simply: one
way I've
> done it is to simply have a 16-bit bit-mask for each separate Unit
Attention
> condition, one bit for each possible initiator on the (wide) SCSI bus.
When
> that initiator issues a command and the bit is set, the initiator
receives a
> Check Condition status, at which point I generate the appropriate
sense data
> and clear the bit.
> 
> In the fibre channel private loop environment, this kind of a strategy
> scales reasonably well, since there can be only 126 addresses on the
loop. A
> 128-bit bit-mask per Unit Attention condition is not unreasonable.
> 
> In a public loop environment, this strategy won't work at all, since
the
> number of potential initiator fabric addresses (through the FL port)
is
> astronomical. Plus, I'm puzzled how I'm supposed to manage this at
all. As I
> understand it, the FL port hides most of the initiator's full fabric
address
> from me anyway -- to me, as a loop device, it looks like the FL port
itself
> is doing all of the initiating, and it keeps track of everything based
on
> the exchange identifier and magically makes my responses go to the
right
> place. So as a loop target, I won't necessarily know whether I'm
getting two
> commands from one initiator on the fabric, or two commands from two
> different initiators.
> 
> Have I missed something?

um, yeah, but that's OK...;-)

The good news is one thing is simpler than you think: the FL_Port does
in fact allow you to see the full 24-bit address of each Initiator. The
FL_Port is just a conduit: it is not changing addresses nor is it
tracking Exchange IDs. The FL_Port *does* make your responses
"magically" go to the right place, but that is based on the 24-bit
destination ID of the Initiator. All you have to do is open AL_PA=0x00
and gives the frames to the FL_Port.

(There is a published T11 Technical Report that describes FL_Port and
public loop operation which I hope you already have. The title is FC-FLA
(Fabric Loop Attach) and the number is NCITS TR-20-1998.)

So, for purposes of this discussion, the only difference between public
and private operation is the size of the address space.

Switching from my fabric guy role to my former life of writing SCSI
target firmware, it occurs to me that you may already have decided how
many Initiators you can actively support at one time, based on memory
limitations in storing data structures for each Initiator. Within each
data structure you could keep some sort of unit attention info. Let's
try the following:

- An N_Port login (PLOGI) causes you to allocate an initiator data
structure to that port (or maybe WWN). You at that time set up the UA
info to indicate the appropriate condition. 

- Subsequent commands would cause the UA to be reported at the
appropriate time.

- If you ran out of initiator data structures, you would have to reject
additional PLOGIs because you have no place to keep the PLOGI
parameters. You would never get to the point where you would need to
report UA, and therefore would not need to keep 2^24 UA bits!

Hope this helps a little. I also hope someone makes any necessary
corrections regarding the target ramblings above. I *am* a little rusty
in that department...;-)

If you have any more questions about FL_Ports, please feel free to write
or call!

jeff

jeff stai
brocade communications systems inc.
15707 rockfield bl #215, irvine ca 92618
949-455-2908vm, 949-455-9287fx
stai at brocade.com  http://www.brocade.com/

> 
> -----Original Message-----
> From: Gerry_Houlder at notes.seagate.com
<Gerry_Houlder at notes.seagate.com>
> To: t10 at Symbios.COM <t10 at Symbios.COM>
> Date: Friday, April 24, 1998 4:42 PM
> Subject: Re: Question: Deferred Sense reporting priority
> 
> 
> >* From the T10 (formerly SCSI) Reflector (t10 at symbios.com), posted
by:
> >* Gerry_Houlder at notes.seagate.com
> >*
> >Most targets only retain the "latest" sense data rather than remember
the
> >last N events.
> 
> *
> * For T10 Reflector information, send a message with
> * 'info t10' (no quotes) in the message body to majordomo at symbios.com
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at symbios.com





More information about the T10 mailing list