Re: [PATCH 12/16] BNX2I: Added feature to silently drop NOPOUT request

[Mike Christie <michaelc-hcNo3dDEHLuVc3sceRu5cw@public.gmane.org>]

On 11/18/2010 01:55 PM, Mike Christie wrote:
> On 11/18/2010 01:25 PM, Eddie Wai wrote:
>>
>> On Wed, 2010-11-17 at 19:40 -0800, Mike Christie wrote:
>>> On 11/10/2010 05:04 PM, Eddie Wai wrote:
>>>> In the case the chip is undergoing different invasive operation
>>>> which requires a chip reset, all NOPOUT request during this period
>>>
>>> For these invasive operations that reset the chip, do we always end up
>>> having to relogin the connection/session or once the reset is done are
>>> we able to just go on happily like nothing ever happened?
>> Operations like mtu change/ifupdown/etc will require the chip to undergo
>> reset. Prior to this, the connections will be cleaned up via the
>> conn_failure->ep_disconnect path and eventually put into the reopen
>> recovery path. During this period, we must disallow any send pdu
>> requests to be queued to the chip for a more immediately connection tear
>> down time (so we don't have to wait for the pdu's completion).
>>
>> We had to treat NOPOUT requests differently as the routine in libiscsi
>> would continuously loop until the NOPOUT send request returns with
>> success. This is the why we added the NOPOUT workaround.
>
> At this time, have you already called iscsi_conn or session failure? If
> so then I think it sounds like there is bug in iscsi_send_nopout or
> __iscsi_conn_send_pdu. If the conn/session has been failed, I think we
> want to add a check in __iscsi_conn_send_pdu where if the conn/session
> is down then we do not send NOPs. There is no point iSCSI RFC wise and
> it screws up drivers.

We actually have a check in __iscsi_conn_send_pdu. There is the 
session->state == ISCSI_STATE_LOGGED_IN, so I guess you have not called 
one of the iscsi failure functions.

At this time, is just the apdater_state getting changed? What code path 
is that?

Maybe related... For bnx2i_get_link_state ADAPTER_STATE_LINK_DOWN, I 
think you will want to call the iscsi_suspend_queue function discussed 
in the other mail. When the link state comes back up though, do we 
always have to reconnect and relogin to the target or are their cases 
where we can just restart the queues?

-- 
You received this message because you are subscribed to the Google Groups "open-iscsi" group.
To post to this group, send email to open-iscsi-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To unsubscribe from this group, send email to open-iscsi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit this group at http://groups.google.com/group/open-iscsi?hl=en.