Chetan Loke wrote:
> --- On Fri, 2/12/10, Joe Eykholt <[email protected]> wrote:
>
>> If the remote initiator logs in before the target is
>> configured and
>> enabled for that initiator, it may need to be reset to
>> "see" the target
>> and probe the LUNs. I suppose there's a way to do
>> this nicer ...
>
> nicer == RSCN's,no? Let the switch take care of it.But the onus is really on
> the intiator side to regsiter SCN's.
Well the initiators all register for RSCNs, but RSCN only
gets sent by the fabric when there's a new N-port logged in,
not when an N port changes roles, as far as I know.
There's another registration, for FC-4 features (RFF), that may
trigger an RSCN, but I'm not sure. Anyway, its correct
that the lport send a new RFF when it's role chnages, so
I'll write code to do that, and we'll see if it generates
an RSCN (I doubt it).
>> by
>> resetting the local port, perhaps, or re-registering with
>> the name server.
> Reset? Why? Not practical.Look for RSCN's above.
Resetting the local port causes the target to logout and
re-login to the fabric, which will cause the RSCNs to be
sent, but maybe RFF can do the same thing. I'll check.
It sounds heavyweight but if the local port is only for
target use and not also an initiator, it's non-disruptive.
Even if it is an initiator, it's not *very* disruptive,
it wouldn't ruin any I/Os in progress.
>>> Would you like I commit it somewhere in trunk/fcoe? Or
>> trunk/fcst? Then
>>> I can grant you commit rights to it. We need the
>> driver can be compiled
>>> inside SCST SVN tree as a module. Don't worry how to
>> compile it inside
>>> kernel. We have script generate-kernel-patch, which
>> takes care of it.
>>
>> I think trunk/fcst is a good place. Let me fix these
>> issues and get it
>> a little more complete before we check it in.
> I'm not going to pretend that I know open-fcoe's plumbing. But(I agree with
> Vlad) a separate fcoe-st[or fcoe-foo] dir would be really nice primarily
> because you depend on open-fcoe plumbing,no?
fcst *is* the plumbing needed to take requests that libfc receives.
The rest is or should eventually become part of libfc, and
we can maintain the libfc patches until then.
Cheers,
Joe
_______________________________________________
devel mailing list
[email protected]
http://www.open-fcoe.org/mailman/listinfo/devel
