Date: Tue, 16 Oct 2012 13:52:52 -0600 From: "Kenneth D. Merry" <ken@freebsd.org> To: Jack <jacks.1785@gmail.com> Cc: freebsd-scsi@freebsd.org Subject: Re: passstart() and immediate CCBs Message-ID: <20121016195252.GA28291@nargothrond.kdm.org> In-Reply-To: <CACmXQA3DxafwiCp4CzaFvxnvOG4=yqj0aVmODDTb8gV0jXEknw@mail.gmail.com> References: <CACmXQA141ZTRDd7DxfM41hd4idDg_uQ7%2BsWc4cZ8E%2B3aLoDJRg@mail.gmail.com> <20121012223203.GA68975@nargothrond.kdm.org> <CACmXQA3DxafwiCp4CzaFvxnvOG4=yqj0aVmODDTb8gV0jXEknw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Oct 15, 2012 at 08:27:23 +0530, Jack wrote: > On Sat, Oct 13, 2012 at 4:02 AM, Kenneth D. Merry <ken@freebsd.org> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20121016195252.GA28291>