Re: [PATCH 3/7] BNX2I: Optimized the bnx2i_stop connection clean up procedure

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Our test group has generated a case where a MTU change or an ifdown was
performed while having active sessions outstanding.  While the
disconnection effort works normally, but for the case where iscsid is
forced to stop, our driver was previously designed to dead wait for 240s
before resuming operation.  Once the wait is over, any leftover chip
resources allocated + previously active iscsi_endpoints would be
forfeited.  For this kind of destructive testing, we decided that it is
best to clean up our chip so that other operations such as L2 or FCoE
would not get affected.  

The 'slow' case mentioned is just a hypothetical case which we have not
encountered first hand.  But the code has been worked so that if iscsid
were to come back up and continue to call ep_disconnect again, only the
endpoints would get cleanup and will no longer attempt to clean up the
hardware.  We're not trying to work around a bug here...

For the case presented, bnx2i_stop was actually called from cnic's
ulp_stop due to the different test case described.  The hard 240s
timeout was there to wait for iscsid to cleanup all the active
connections.  If it were to be exceeded somehow, the same lost resource
+ endpoint condition would happen.

Eddie

On Tue, 2010-06-29 at 23:11 -0700, Mike Christie wrote:
> On 06/25/2010 08:39 PM, Eddie Wai wrote:
> > For cases where the iSCSI disconnection procedure times out due to
> > the iSCSI daemon being slow or unresponsive, the bnx2i_stop routine
> 
> Could you describe when iscsid is slow a little more? The unresponsive 
> case sounds like if iscsid is not running, right? For the slow case, it 
> sounds like you are trying to work around a bug in there.
> 
> I am also not sure how it helps exactly. iscsid still has to cleanup the 
> iscsi resources like the scsi commands running on the connection (conn 
> stop is called after ep disconnect), so I am not sure how this helps. 
> Does doing it this way skip some steps?
> 


--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [SCSI Target Devel]     [Linux SCSI Target Infrastructure]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Linux IIO]     [Samba]     [Device Mapper]
  Powered by Linux