Question: Deferred Sense reporting priority
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,
> have a question regarding Unit Attention in a fibre-channel fabric
> My understanding of the Unit Attention condition is that it is posted
> per-initiator basis. That is, if there are multiple initiators on a
> bus, and a device powers up, each initiator should see the PON Unit
> Attention condition (the first initiator to poll the device should not
> Unit Attention for other initiators). In fact, some of the Unit
> conditions (Mode Page parameter changes, for example), are ONLY posted
> initiators other than the one which performed the Mode Select, which
> pretty useless if any initiator can clear the Unit Attention condition
> all the rest of the initiators.
> In the SCSI-2 environment, implementation could be done simply: one
> done it is to simply have a 16-bit bit-mask for each separate Unit
> condition, one bit for each possible initiator on the (wide) SCSI bus.
> that initiator issues a command and the bit is set, the initiator
> Check Condition status, at which point I generate the appropriate
> 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
> 128-bit bit-mask per Unit Attention condition is not unreasonable.
> In a public loop environment, this strategy won't work at all, since
> number of potential initiator fabric addresses (through the FL port)
> 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
> from me anyway -- to me, as a loop device, it looks like the FL port
> is doing all of the initiating, and it keeps track of everything based
> the exchange identifier and magically makes my responses go to the
> place. So as a loop target, I won't necessarily know whether I'm
> 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
- 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
brocade communications systems inc.
15707 rockfield bl #215, irvine ca 92618
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
> >* Gerry_Houlder at notes.seagate.com
> >Most targets only retain the "latest" sense data rather than remember
> >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