On 11/12/2010 09:40 PM, Zou, Yi wrote: > Hi, > I have noticed that in one of my testing where the target > supports REC but does not support RETRY in PRLI reply. > In this case, fc_fcp_srr() is never really sending SRR but > just goes to fc_fcp_retry_cmd() directly since > FC_RP_FLAGS_RETRY of the rport is not set. I understand > that no RETRY does not mean no REC from FCP-3 spec, > so we can't disable REC because of no RETRY, but for us, > in this case, we got REC accepted, but we are not > able to send SRR, does that mean we want to fail the I/O > at that point already? Currently we're using REC + SRR for error recovery (ie command retry). So from the implementation side it simply doesn't make any sense to send a REC and _then_ fail the I/O; we're not gaining any additional information here. Sending a REC would just enable us to detect if the exchange has completed, but we won't get any details of the transaction.
So from my POV we could just short-circuit the logic here and _not_ send a REC if SRR is found not to be supported. Cheers, Hannes -- Dr. Hannes Reinecke zSeries & Storage [email protected] +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Markus Rex, HRB 16746 (AG Nürnberg) _______________________________________________ devel mailing list [email protected] http://www.open-fcoe.org/mailman/listinfo/devel
