Re: [LSF/MM TOPIC] Reducing the SRP initiator failover time

[Vu Pham <vu-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>]

>
>
> It is known that it takes about two to three minutes before the 
> upstream SRP initiator fails over from a failed path to a working 
> path. This is not only considered longer than acceptable but is also 
> longer than other Linux SCSI initiators (e.g. iSCSI and FC). Progress 
> so far with improving the fail-over SRP initiator has been slow. This 
> is because the discussion about candidate patches occurred at two 
> different levels: not only the patches itself were discussed but also 
> the approach that should be followed. That last aspect is easier to 
> discuss in a meeting than over a mailing list. Hence the proposal to 
> discuss SRP initiator failover behavior during the LSF/MM summit. The 
> topics that need further discussion are:
> * If a path fails, remove the entire SCSI host or preserve the SCSI
>   host and only remove the SCSI devices associated with that host ?
> * Which software component should test the state of a path and should
>   reconnect to an SRP target if a path is restored ? Should that be
>   done by the user space process srp_daemon or by the SRP initiator
>   kernel module ?
> * How should the SRP initiator behave after a path failure has been
>   detected ? Should the behavior be similar to the FC initiator with
>   its fast_io_fail_tmo and dev_loss_tmo parameters ?
>
> Dave, if this topic gets accepted, I really hope you will be able to 
> attend the LSF/MM summit.
>
> Bart.
>
Hello Bart,

Thank you for taking the initiative.
Mellanox think that this should be discussed. We'd be happy to attend.

We also would like to discuss:
* How and how fast does SRP detect a path failure besides RC error?
* Role of srp_daemon, how often srp_daemon scan fabric for new/old 
targets, how-to scale srp_daemon discovery, traps.

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