From owner-freebsd-scsi@FreeBSD.ORG Tue Oct 16 19:52:58 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 E01AEA8C for ; Tue, 16 Oct 2012 19:52:58 +0000 (UTC) (envelope-from ken@kdm.org) Received: from nargothrond.kdm.org (nargothrond.kdm.org [70.56.43.81]) by mx1.freebsd.org (Postfix) with ESMTP id 8811A8FC0C for ; Tue, 16 Oct 2012 19:52:58 +0000 (UTC) Received: from nargothrond.kdm.org (localhost [127.0.0.1]) by nargothrond.kdm.org (8.14.2/8.14.2) with ESMTP id q9GJqqiL028406; Tue, 16 Oct 2012 13:52:52 -0600 (MDT) (envelope-from ken@nargothrond.kdm.org) Received: (from ken@localhost) by nargothrond.kdm.org (8.14.2/8.14.2/Submit) id q9GJqq2T028405; Tue, 16 Oct 2012 13:52:52 -0600 (MDT) (envelope-from ken) Date: Tue, 16 Oct 2012 13:52:52 -0600 From: "Kenneth D. Merry" To: Jack Subject: Re: passstart() and immediate CCBs Message-ID: <20121016195252.GA28291@nargothrond.kdm.org> References: <20121012223203.GA68975@nargothrond.kdm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2i Cc: freebsd-scsi@freebsd.org X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2012 19:52:59 -0000 On Mon, Oct 15, 2012 at 08:27:23 +0530, Jack wrote: > On Sat, Oct 13, 2012 at 4:02 AM, Kenneth D. Merry wrote: > > > Immediate CCBs are complete when xpt_action() returns, so no callback is > > needed. > > > > Does Immediate CCB transaction is similar to polling? I mean xpt_action() is > called, xfer is done and then HBA asserts interrupt, the control is transfered > back to xpt_action(), then it returns. Immediate CCBs are not polled. They are completed when xpt_action() is called, and no callback is needed. There is no data transfer, and there is no interrupt, because immediate CCBs are never sent to the controller. They may be sent to the SIM driver, depending on the CCB, but they never involve a callback. > Then what is the purpose of cam_periph_ccbwait(), inside > cam_periph_runccb(), just after xpt_action(). To wait for a queued CCB to complete. For an immediate CCB, the status will not be CAM_REQ_INPROG, and cam_periph_ccbwait() won't actually wait. > > Immediate CCBs never go down to the hardware. The priority mechanism is > > used to help determine who gets queue slots, and those are only > > needed for queued CCBs. > > > > queued CCBs means non-immediate CCBs. right? Yes. > Sorry, I didn't get what do you mean by: > " Immediate CCBs never go down to the hardware." Take a look at the CCB opcodes in sys/cam/cam_ccb.h. The function codes that are marked with XPT_FC_QUEUED are things like XPT_SCSI_IO, XPT_RESET_BUS and XPT_SCAN_BUS. All of those generally require sending a command to a controller to perform the requested operation. They are queued CCBs, not immediate CCBs. Immediate CCBs like XPT_GDEV_TYPE, XPT_DEV_MATCH and XPT_DEBUG do not go down to the hardware. As soon as xpt_action() completes, the CCBs have a status of CAM_REQ_CMP or a suitable error status. No callback is needed. > I guess immediate CCBs are preferred over non-immediate CCBs, in the > sense that they bypass struct cam_ed queue completely, and directly > sent to HBA driver, via xpt_action(). Is it? Neither type is better than the other. Immediate CCBs don't need to go through the queueing infrastructure because they don't take up any hardware resources. Conversely, queued CCBs take up hardware resources, and therefore have to go through the queueing infrastructure. Ken -- Kenneth Merry ken@FreeBSD.ORG