isp 24xx target-mode SRR handling

[Penta]

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 at 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 at 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 at freebsd.org>
> "
>