Re: [RFC][PATCH 2/6] fnic: add fnic_scsi.c and fnic_io.h.

[Mike Christie <michaelc@cs.wisc.edu>]

Mike Christie wrote:
> Joe Eykholt wrote:
>> James Smart wrote:
>>>
>>> Mike Christie wrote:
>>>>> Well - what should be happening is - prior to the reset or as part of
>>>>> it, the fc transport fc_remote_port_delete() call should be made on 
>>>>> all
>>>>> those remote ports that connectivity is about to be terminated on.  
>>>>> This
>>>>> will place all the associated targets/luns on those rports into a
>>>>> blocked state, and start the devloss timer on them.  This will suspend
>>>>> the eh path as well.  Thus, things suspend until either the 
>>>>> driver/fcoe
>>>> What do you mean by that? For lpfc it will or for this driver? This
>>>> driver does not have that block call like lpfc_block_error_handler, so
>>>> if the rport event occurs after the scsi eh is running we do not 
>>>> suspend
>>>> the eh.
>>>>
>>>> So below I am saying we should make the lpfc_block_error_handler
>>>> functionality and the equivalent in the qla2xxx and mpfc common so
>>>> libfc/fcoe and fnic can use it.
>>> Well there's successive layers of the onion here. And your right, one of
>>> them is the block_error_handler.  Agreed, all of this should be common.
>>>
>>> -- james s
>>>
>>
>> I think you're both on the right track.  When we reset the local port, 
>> it should make all
>> remote ports non-ready ... we no longer have a PLOGI to them.  Until 
>> we redo FLOGI and
>> discovery, no SCSI ops will succeed.  fc_lport_reset() calls 
>> fc_lport_set_fid, which calls
>> lp_rport_reset_list() ... but that doesn't seem to do much to rports 
>> other than the
>> directory server.
>>
>> fc_rport_reset() puts the rport in state INIT, but I don't think 
>> that's enough.  Maybe
>> that's where the remote port should get blocked.  Sound right?
>>
> 
> Did you see the thread
> http://www.open-fcoe.org/pipermail/devel/2008-July/000394.html
> I think we basically said we need to overhaul the fc class 
> fc_remote_port and the libfc's use - some of the discussion went off 
> list into some call. James and Chris were going to work on it. I think 
> both got busy with other issues or are still working on it.

Hit send too soon.

We basically should be deleting the port for these scenarios, then that 
sets the dev_loss_tmo and blocks the rport. We should then wait in the 
eh for the rport to be added back or for the dev_loss_tmo to fire.