From owner-freebsd-scsi@FreeBSD.ORG Wed Oct 17 08:26:45 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 F17C1112 for ; Wed, 17 Oct 2012 08:26:44 +0000 (UTC) (envelope-from jacks.1785@gmail.com) Received: from mail-ia0-f182.google.com (mail-ia0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id B53BB8FC0A for ; Wed, 17 Oct 2012 08:26:44 +0000 (UTC) Received: by mail-ia0-f182.google.com with SMTP id k10so6909515iag.13 for ; Wed, 17 Oct 2012 01:26:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=WvNk/N6zAeIDphYMHlJKFS8t0yZn6RHfuo5pULghOXU=; b=zyLTQ31t7Wc7Us4TlNpB+NpO8AXEja9kvnyINcX6a7S08TYAteQT4sr4Z2TDvrZYPa 6sbUd7t7bbqYa48KPhzHPA9tJXZyhoaNKcx5yHs6BMcyaPxOfkWtBWwHnKxN4kTgLTPY AOEszajwGiYPRAIQdxqbkZeoJZ4IicCcPMs3inGmkDu/Fl8mmYS+Mx3Jj6KleORKPK9n ZNetmt2wwDfry8DePxOnLL7iVMp7+DIIxPF2Vz7DzpMAo6EIipcPNXeMyIcqxqXkjpx1 dtX52nu0b4wBqfmqfqOeL1yqziGGvatJx6EI4wboicMRKpfs/dkSgn/gcbcK3YsB7dUk t00w== MIME-Version: 1.0 Received: by 10.50.46.134 with SMTP id v6mr789640igm.55.1350462404005; Wed, 17 Oct 2012 01:26:44 -0700 (PDT) Received: by 10.64.11.166 with HTTP; Wed, 17 Oct 2012 01:26:43 -0700 (PDT) In-Reply-To: <20121016195252.GA28291@nargothrond.kdm.org> References: <20121012223203.GA68975@nargothrond.kdm.org> <20121016195252.GA28291@nargothrond.kdm.org> Date: Wed, 17 Oct 2012 13:56:43 +0530 Message-ID: Subject: Re: passstart() and immediate CCBs From: Jack To: freebsd-scsi@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 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: Wed, 17 Oct 2012 08:26:45 -0000 On Wed, Oct 17, 2012 at 1:22 AM, Kenneth D. Merry 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