Date: Wed, 05 Sep 2012 06:57:40 -0700 From: Matthew Jacob <mj@feral.com> To: freebsd-scsi@freebsd.org Subject: Re: isp 24xx target-mode SRR handling Message-ID: <50475A54.5000804@feral.com> In-Reply-To: <CAPvJ%2BQfSeY=OLbmTX2XuNAQN4DdW%2B8NTRXbEn2fcyK5ewCp%2BXQ@mail.gmail.com> References: <CAPvJ%2BQfSeY=OLbmTX2XuNAQN4DdW%2B8NTRXbEn2fcyK5ewCp%2BXQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?50475A54.5000804>