All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeff Garzik <jgarzik@pobox.com>
To: James Bottomley <James.Bottomley@steeleye.com>
Cc: Jens Axboe <axboe@suse.de>,
	Andrew Vasquez <andrew.vasquez@qlogic.com>,
	SCSI Mailing List <linux-scsi@vger.kernel.org>
Subject: Re: PATCH [5/15] qla2xxx:  SG tablesize update
Date: Mon, 15 Mar 2004 11:09:51 -0500	[thread overview]
Message-ID: <4055D54F.8010908@pobox.com> (raw)
In-Reply-To: <1079303516.2108.73.camel@mulgrave>

James Bottomley wrote:
> On Sun, 2004-03-14 at 15:36, Jeff Garzik wrote:
> 
>>On Sun, Mar 14, 2004 at 09:59:55AM -0500, James Bottomley wrote:
>>
>>>The Qla chips are rather weird in that they have a single issue queue
>>>(whose size you can vary) but whose entry formats are fixed.  If I
>>>remember correctly, an initial command can have 4 SG elements, but a
>>>follow on entry can have 7 (not sure of the figures).  But anyway, large
>>>SG commands end up having to find multiple entries in this queue (and
>>>being a single issue queue for the entire card, it has to be mutexed
>>>while you search).  The more resources you need, the more difficult the
>>>search and the more contention you generate on the resource mutex.
>>
>>The block layer can handle this type of hardware just fine ;-)
>>
>>In my SATA hacking I am finding several devices that one must constrain
>>based on hardware-global resources, rather than just TCQ (or lack
>>thereof).
> 
> 
> I'm sorry, I must have missed the multiple queues down to a single HBA
> queue API in the block layer, which one is it again?

Not saying the block layer provides this capability, simply that it is 
possible in any block driver.  It required < 20 LOC in carmel.c to do 
this in a hardware-specific fashion, so it seemed unnecessary to invent 
a new API...  I would like to see something similar in cciss.c, in fact...

	Jeff




  reply	other threads:[~2004-03-15 16:10 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-03-14  8:24 PATCH [5/15] qla2xxx: SG tablesize update Andrew Vasquez
2004-03-14 14:49 ` James Bottomley
2004-03-14 14:51   ` Jens Axboe
2004-03-14 14:59     ` James Bottomley
2004-03-14 15:15       ` Jens Axboe
2004-03-14 15:18       ` Anton Blanchard
2004-03-14 15:31         ` James Bottomley
2004-03-14 15:47           ` Anton Blanchard
2004-03-14 15:55             ` James Bottomley
2004-03-14 16:01               ` Anton Blanchard
2004-03-14 20:41             ` Jeff Garzik
2004-03-14 22:27               ` James Bottomley
2004-03-15 16:12                 ` Jeff Garzik
2004-03-14 20:36       ` Jeff Garzik
2004-03-14 22:31         ` James Bottomley
2004-03-15 16:09           ` Jeff Garzik [this message]
  -- strict thread matches above, loose matches on Subject: below --
2004-03-15 23:43 Andrew Vasquez
2004-03-16  3:37 ` James Bottomley
2004-03-16  6:40 ` Jeremy Higdon
2004-03-16 11:32 ` Anton Blanchard
2004-03-16 21:49 ` James Bottomley
2004-03-16 22:09 Andrew Vasquez

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=4055D54F.8010908@pobox.com \
    --to=jgarzik@pobox.com \
    --cc=James.Bottomley@steeleye.com \
    --cc=andrew.vasquez@qlogic.com \
    --cc=axboe@suse.de \
    --cc=linux-scsi@vger.kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.