Skip site navigation (1)Skip section navigation (2)
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>