FCP-2 resource recovery question

Howard Green green at prisa.com
Wed Jul 21 09:13:39 PDT 1999


* From the T10 Reflector (t10 at symbios.com), posted by:
* "Howard Green" <green at prisa.com>
*
OK, I think I've got it, but I'd like to run part of this back just to be
sure.

My thanks to Greg for separating the initiator login context and exchange
context resources: that's the key element I was missing. My original
questions were aimed at the issue of initiator login context recovery, which
I now understand as _not_ being addressed by FCP-2---or any previous spec,
for that matter. In particular, the fact that in a PLDA environment
initiator failure _tends_ (unreliably) to cause loop initialization that
leads to initiator login context recovery is pretty much just a fortuitous
side effect.

The corollary of all this is that a Target presumably needs to define and
provide mechanisms for dealing with initiator login context recovery (at
least, if the Target has finite resources :-)). Greg's scenario suggests
that RSCN use by Targets isn't a good basis for this (I've seen this
behavior in action and observed all of the problems he lists, and I'd
agree). Similarly, a Target in a Fabric environment can't just assume that
LIPs will drive the recovery process (I've experienced this, too...and the
sight of Initiators being rejected by an idle Target stuffed with disused
logins is not pretty).

I suppose that this begs the question of whether initiator login context
recovery behavior needs to be specified or standardized (for example, I'd
note that Greg's LRU mechanism is a perfectly reasonable policy, but that
it's just one of many possible policies). On the other hand, as long as a
Target chooses to do _something_ to recover disused resources, it's probably
good enough for the time being....and that's what I was after.

Howard Green


-----Original Message-----
From: Scherer, Greg <Greg.Scherer at emulex.com>
To: 'Howard Green' <green at prisa.com>; Bob.Snively at sun.com
<Bob.Snively at sun.com>
Cc: fc at nsco.network.com <fc at nsco.network.com>; t10 at symbios.com
<t10 at symbios.com>
Date: Monday, July 19, 1999 6:35 AM
Subject: RE: FCP-2 resource recovery question


>Howard,
>
>Since there is no specification or requirement that a Fabric send an RSCN
in
>real time, having a Target register for RSCN can (and does) cause many
other
>problems.  Each port that has registered for RSCN receives it asynchronous
>from the actual event, in fact there is even benefit for the Fabric to
>insert hysterysis in this notification, to avoid sending multiple RSCNs
when
>the link may "bounce" (many Fabric vendors have implemented this).
>
>Here is a failing scenario:
>
>1. An Initiator logs into the Fabric
>2. This Initiator then logs into the NameServer and gets a list of Targets
>3. The Initiator then Logs into the Target(s)
>4. Some time later (1-2 seconds in some cases) the Fabric sends RSCN
>5. The Target then goes to PDISC-Pending waiting for the Initiator to
>authenticate itself
>
>During this time the Initiator is oblivious to the fact that it "should"
>authenticate, and all I/O sent during this RRTOV window will be ignored.
>This can (and does) cause particular problems, especially during initial
>discovery, during which Hosts generally employs very small I/O time-outs.
>
>Since the Target takes on a Slave role in discovery/authentication (per
>PLDA/FLA, a Target does not initiate login, unlike FCA-IP), I contend that
>registering for RSCN is for Initiators ONLY, not slave devices.  The reason
>that current Private Loop behavior works, is that notification of a link
>event (LIP) is received by all N_Ports concurrently before I/O can be
>resumed.  This is not and can not be the case in a Fabric, which has
>different topology characteristics than a Private Loop.
>
>Regarding how a Target may recovery resources;  from my perspective (which
>is I'm sure not complete :-) ) there are two main kinds of resources to be
>recovered:
>
> - Initiator Login Contexts
>
>   . One way to recover these is to always accept a new login, by logging
>out an existing context in a least frequently used basis.
>
> - Exchange Contexts (most especially rcv buffers)
>
>   . There is already a recommended way to recover these resources, by
using
>an I/O timer to age out the I/O if the initiator has not sent write data in
>response to an XFER_RDY within this time-out.  All other transfers are
>controlled by the Target (send FCP_DATA and/or FCP_RSP).
>
>Thanks,
>Greg Scherer
>Emulex Fibre Channel Development
>
>
>-----Original Message-----
>From: owner-fc at nsg0.network.com [mailto:owner-fc at nsg0.network.com]On
>Behalf Of Howard Green
>Sent: Thursday, July 15, 1999 8:40 PM
>To: Bob.Snively at sun.com
>Cc: fc at nsco.network.com; t10 at symbios.com
>Subject: FCP-2 resource recovery question
>
>
>I've got a question regarding target resource recovery. FCP-2, in section
>10.3 on RR_TOV, specifies that a target can recover resources in use on
>behalf of an initiator if the initiator fails to authenticate itself within
>RR_TOV following completion of loop initialization.
>
>The FCP-2 text (and the corresponding FC-TAPE text, too) is pretty close to
>a verbatim inclusion from PLDA, which dealt with FibreChannel universes no
>larger than a single loop. In such an environment, one could reasonably
>expect the demise of an initiator to cause a loop initialization, which
>would provide targets with the event needed to trigger RR_TOV action, and
>ultimately, resource recovery.
>
>Times have changed, though, and Fabrics are a reality, and therein lies my
>question. In a Fabric environment, initiator and target may be on different
>Fabric ports---i.e., not on the same loop---and an initialization on one
>loop won't generally propagate to any other. Further, if either initiator
or
>target is attached to the Fabric via a link, loop initialization events
are,
>um, kind of problematic.
>
>So, suppose an initiator on one Fabric port is using a target on another.
If
>the initiator kicks the bucket, what event serves to inform the target that
>it ought to start its resource recovery process?
>
>One (obvious?) solution is to require targets to register for and monitor
>RSCNs (and indeed, there are targets that already do this). If a target
>receives an RSCN that pertains to a logged-in initiator, it suspends that
>initiator (and presumably only that initiator!) and starts its RR_TOV
timer.
>
>Am I missing something? It seems like there's got to be something more than
>loop initialization to trigger resource recovery in a Fabric environment.
>
>
>Howard Green
>Prisa Networks
>
>
>
>

*
* 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