public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Doug Ledford <dledford@redhat.com>
To: Mark Haverkamp <markh@osdl.org>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>,
	dougg@torque.net, Christoffer Hall-Frederiksen <hall@jiffies.dk>,
	linux-scsi@vger.kernel.org,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	linux aacraid devel <linux-aacraid-devel@dell.com>
Subject: Re: Problem with aacraid driver in 2.5.63-bk-latest
Date: Thu, 13 Mar 2003 18:17:40 -0500	[thread overview]
Message-ID: <3E711194.9010505@redhat.com> (raw)
In-Reply-To: <1047570132.30105.7.camel@markh1.pdx.osdl.net>

Mark Haverkamp wrote:

> Does the cmd_per_lun element of the Scsi_Host_Template structure serve
> more than one purpose? 

Only when inappropriately abused by LLDD authors.  The cmd_per_lun value 
is suppossed to be for untagged devices only!  If you have a tape drive 
that doesn't support tagged commands but you want to be able to 
internally have the next command queued up and ready to go when the 
current command completes (in order to keep it streaming better), then 
you can set cmd_per_lun to 2 and you will get two outstanding commands 
for this device at a time.  I used that so that in my interrupt handler 
I could send the next command to the device before I passed the 
completed command up to the SCSI layer.

> In scsi_alloc_sdev it is passed into
> scsi_adjust_queue_depth.  In the aacraid case this is 512.  Later the
> aacraid driver (in aac_slave_configure) sets the queue depth to either
> 128 for tagged or 1 if not.

That's where you are suppossed to set the queue depth on tagged devices.


-- 
   Doug Ledford <dledford@redhat.com>     919-754-3700 x44233
          Red Hat, Inc.
          1801 Varsity Dr.
          Raleigh, NC 27606



  reply	other threads:[~2003-03-13 23:07 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20030228133037.GB7473@jiffies.dk>
2003-03-12 23:06 ` Problem with aacraid driver in 2.5.63-bk-latest Mark Haverkamp
2003-03-13  0:18   ` Alan Cox
2003-03-12 23:55     ` Douglas Gilbert
2003-03-13  1:06       ` Alan Cox
2003-03-13  0:50         ` Mike Anderson
2003-03-13 23:13           ` Mark Haverkamp
2003-03-14  7:05           ` Denis Vlasenko
2003-03-14 10:18             ` Mike Anderson
2003-03-13  1:31         ` Douglas Gilbert
2003-03-13 23:27           ` Doug Ledford
2003-03-13 15:42         ` Mark Haverkamp
2003-03-13 23:17           ` Doug Ledford [this message]
2003-03-13 23:22             ` Mark Haverkamp
2003-03-13 23:25               ` Doug Ledford
2003-03-14 14:57                 ` Alan Cox
2003-03-14 15:34                   ` Mark Haverkamp
2003-03-14 16:48                     ` Alan Cox
2003-03-03 10:05 Christoffer Hall-Frederiksen
2003-03-03 13:40 ` Alan Cox
2003-03-03 14:46   ` Christoffer Hall-Frederiksen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3E711194.9010505@redhat.com \
    --to=dledford@redhat.com \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=dougg@torque.net \
    --cc=hall@jiffies.dk \
    --cc=linux-aacraid-devel@dell.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=markh@osdl.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox