Date: Wed, 17 Oct 2012 13:56:43 +0530 From: Jack <jacks.1785@gmail.com> To: freebsd-scsi@freebsd.org Subject: Re: passstart() and immediate CCBs Message-ID: <CACmXQA1miPh0mp0T4fKCcvt52iw5ViSC1t7TcKY%2BzdBZ%2BfvgHQ@mail.gmail.com> In-Reply-To: <20121016195252.GA28291@nargothrond.kdm.org> References: <CACmXQA141ZTRDd7DxfM41hd4idDg_uQ7%2BsWc4cZ8E%2B3aLoDJRg@mail.gmail.com> <20121012223203.GA68975@nargothrond.kdm.org> <CACmXQA3DxafwiCp4CzaFvxnvOG4=yqj0aVmODDTb8gV0jXEknw@mail.gmail.com> <20121016195252.GA28291@nargothrond.kdm.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Oct 17, 2012 at 1:22 AM, Kenneth D. Merry <ken@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CACmXQA1miPh0mp0T4fKCcvt52iw5ViSC1t7TcKY%2BzdBZ%2BfvgHQ>