Date: Thu, 6 Sep 2012 00:11:43 +0530 From: Penta <penta1998@gmail.com> To: freebsd-scsi@freebsd.org Subject: Re: isp 24xx target-mode SRR handling Message-ID: <CAPvJ%2BQfRL71Y1txg_ooADTb83UbQVEiCqXB0GQs2Cc-E1TOhnQ@mail.gmail.com> In-Reply-To: <50475A54.5000804@feral.com> References: <CAPvJ%2BQfSeY=OLbmTX2XuNAQN4DdW%2B8NTRXbEn2fcyK5ewCp%2BXQ@mail.gmail.com> <50475A54.5000804@feral.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi Matthew, Thanks, things are much more clear to me. I also came across your commit description at http://svnweb.freebsd.org/base?view=revision&revision=238869which helped. My sources were a bit outdated and didn't have the SRR/FC Tape changes. Now that i have them, i'm back to my reading :-) Thanks a lot once again. On Wed, Sep 5, 2012 at 7:27 PM, Matthew Jacob <mj@feral.com> wrote: > On 9/5/2012 2:45 AM, Penta wrote: > >> Hi Matthew, >> >> I'm trying to understand the target-mode implementation of the isp driver. >> My question is regarding SRR handling. On receiving a notify request >> IN24XX_SRR_RCVD, it seems that the target rejects the notify request >> (na_srr_flags = 1, na_srr_reject_flags = 1 etc.. which i dont understand) >> >> My question is that shouldn't the initiator send a SRR request only when >> data retransmission is supported by the target (in isp's case it isn't). >> The PRLI handling doesn't seem to do anything w.r.t to SRR. How does the >> target notify the initiator that retransmission isn't supported ? Also >> what >> happens next, does the initiator retry the entire command, or is it >> dependent on the initiator implementation ? >> >> Is an SRR implementation for target-mode vital moving forward (8GB cards >> etc.) or is it just a nice to have feature ? >> >> I am new with the FC protocol and the code. I might have asked something >> obvious, so please bear with me. >> >> Yes, the initiator is only going to send an SRR to devices that have set > in the PRLI word3 that they support that. Note also that isp(8) is > cognizant about this for it's initiator side as well. It's been supported > in the QLogic cards for quite some time, but not in isp(8). > > That setting is done in isp_fibre_init_2400 by looking at options gotten > from card NVRAM, looking at softer setting options and setting the value in > the ICB (init control block) and local softc appropriately: > > icbp->icb_fwoptions2 = fcp->isp_xfwoptions; > if (isp->isp_confopts & ISP_CFG_NOFCTAPE) { > icbp->icb_fwoptions2 &= ~ICB2400_OPT2_FCTAPE; > } > if (isp->isp_confopts & ISP_CFG_FCTAPE) { > icbp->icb_fwoptions2 |= ICB2400_OPT2_FCTAPE; > } > > if (icbp->icb_fwoptions2 & ICB2400_OPT2_FCTAPE) { > FCPARAM(isp, chan)->fctape_enabled = 1; > } else { > FCPARAM(isp, chan)->fctape_enabled = 0; > } > > and in isp_fiber_init (for 23XX cards); > > if (ISP_CAP_FCTAPE(isp)) { > if (isp->isp_confopts & ISP_CFG_NOFCTAPE) > icbp->icb_xfwoptions &= ~ICBXOPT_FCTAPE; > > if (isp->isp_confopts & ISP_CFG_FCTAPE) > icbp->icb_xfwoptions |= ICBXOPT_FCTAPE; > > if (icbp->icb_xfwoptions & ICBXOPT_FCTAPE) { > icbp->icb_fwoptions &= ~ICBOPT_FULL_LOGIN; > /* per documents */ > icbp->icb_xfwoptions |= > ICBXOPT_FCTAPE_CCQ|ICBXOPT_**FCTAPE_CONFIRM; > FCPARAM(isp, 0)->fctape_enabled = 1; > } else { > FCPARAM(isp, 0)->fctape_enabled = 0; > } > } else { > icbp->icb_xfwoptions &= ~ICBXOPT_FCTAPE; > FCPARAM(isp, 0)->fctape_enabled = 0; > } > > What the initiator does after the SRR depends on what the target does. The > idea of sending an SRR is to let the target know that you didn't quite get > what they were sending. In the case of lost data, the SRR causes a reset of > the SCSI protocol data pointer so that data retransmission begins again > from the reset data pointer offset. In the case of a lost RSPNS frame, the > response frame is just resent. > > There are some subtleties about the practical aspects of current > implementations that make things a little difficult. For example you're not > likely to know you've lost a frame until the RSPNS frame is sent (for reads > from the target), and as you may or may not have noticed this causes some > complications with the current CAM state machine notion- by the time you're > told that a frame was lost, the SIM has no idea what to do because that > relates to a CTIO that was done some time in the past (hence the current > CAM_RECV_MESSAGE hack). > > If you want to see all of the ins and outs of data recovery cases related > to SRR and other mechanisms, you should read FCP2 (probably not available > w/o being a t10 member) or FCP4 (available from www.t10.org I think > because it's still in draft form) which goes on at great length about > recovery mechanisms. > > > ______________________________**_________________ > freebsd-scsi@freebsd.org mailing list > http://lists.freebsd.org/**mailman/listinfo/freebsd-scsi<http://lists.freebsd.org/mailman/listinfo/freebsd-scsi>; > To unsubscribe, send any mail to "freebsd-scsi-unsubscribe@**freebsd.org<freebsd-scsi-unsubscribe@freebsd.org> > " >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAPvJ%2BQfRL71Y1txg_ooADTb83UbQVEiCqXB0GQs2Cc-E1TOhnQ>