passstart() and immediate CCBs

[Jack]

On Wed, Oct 17, 2012 at 1:22 AM, Kenneth D. Merry <ken at freebsd.org> wrote:
> On Mon, Oct 15, 2012 at 08:27:23 +0530, Jack wrote:

>
>> 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.
>


This means that immediate CCBs are created only for those CCBs, that deal in
kernel CAM subsystem infrastructure(or, data structures, locks, etc.),
rather than
being an actual SCSI / ATA cmd CCBs, or instructions to HBA itself -
e.g. HBA reset, bus reset, etc.

In other words, if I need to send a scsi/ata command to a device, or
need to reset
the scsi bus, or change any  HBA setting, then we MUST create non-immediate
CCBs, there is no way to by-pass   struct cam_ed queue, in this case.

Please correct me if I am wrong.



If immediate CCBs, are not allocated any struct cam_ed queue slots,
then why do cam pass driver(scsi_pass.c)  calls  xpt_setup_ccb( )
inside passioctl( ), with priority field. set to, as specified by user.
Instead, it should set the priority field to CAM_PRIORITY_NONE, explicitly,
because the meaning of priority is only for non-immediate CCBs.  Isn't it?

It seems I'm missing something about cam priority concept.
What exactly is the difference between CAM_RL_XXX
and CAM_PRIORITY_XXX constants?

I guess former indicates the category of queue to which a priority level
is associated e.g. in case of CAM_RL_HOST, it means that
this priority level is for HBA queue, while latter seems the priority levels
themselves.



Regards

-- 
Jack