From owner-freebsd-scsi@FreeBSD.ORG Wed Sep 5 18:41:45 2012 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9928D106564A for ; Wed, 5 Sep 2012 18:41:45 +0000 (UTC) (envelope-from penta1998@gmail.com) Received: from mail-lpp01m010-f54.google.com (mail-lpp01m010-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 0141F8FC12 for ; Wed, 5 Sep 2012 18:41:44 +0000 (UTC) Received: by lage12 with SMTP id e12so731442lag.13 for ; Wed, 05 Sep 2012 11:41:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=6D1RG3nyrcbV5SXKM+TCL5b3Io2Li4kQdGN/8JsNEr8=; b=C6CN0WZdniiVEHTbKY/0rvs5yHg85quWWPkto4EA/jyqr5F+OmeTvwafHFzHoqjn4L uQ5TKUQFOiwO9iA8hatvGY1dXj2WoornGwxhnNVZ0/ZY9AkdNSgdrdyWE8iiI386V2wD Q/GoisjUcjQBMs2Mk3+z5R4i/kxr/YeqeZBFWwbcm6vHyWkOt6d+N2bMQpdNsMkscBnQ h3NriRmqkq1MA3PGQXlwPXZJt2ZRq3ygwB+YXmJ5VDsPpoY3rw0oy25xKey4wqBWEjsU rHSvo6UaRGNTCFiQ+t7KyfwYls/Y/R2Q2Ocg9Hu3eUETMHh8wpYHiIidXGZFBlkRtDBN 60ZA== MIME-Version: 1.0 Received: by 10.152.132.133 with SMTP id ou5mr21066652lab.45.1346870503598; Wed, 05 Sep 2012 11:41:43 -0700 (PDT) Received: by 10.114.21.135 with HTTP; Wed, 5 Sep 2012 11:41:43 -0700 (PDT) In-Reply-To: <50475A54.5000804@feral.com> References: <50475A54.5000804@feral.com> Date: Thu, 6 Sep 2012 00:11:43 +0530 Message-ID: From: Penta To: freebsd-scsi@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: isp 24xx target-mode SRR handling X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 18:41:45 -0000 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 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 > To unsubscribe, send any mail to "freebsd-scsi-unsubscribe@**freebsd.org > " >