RE: [RFC PATCH 2.6.9-rc2] Add sysfs queue depth override to qla2xxx

RE: [RFC PATCH 2.6.9-rc2] Add sysfs queue depth override to qla2xxx

[Andrew Vasquez]

On Tuesday, September 28, 2004 12:54 AM, Jeremy Higdon wrote:
> +static ssize_t
> +qla2xxx_store_queue_depth(struct device *dev, const char *buf,
> size_t count) +{
> +	int			 depth;
> +	struct scsi_device	*sdev = to_scsi_device(dev);
> +
> +	if (sdev->tagged_supported) {
> +		depth = simple_strtoul(buf, NULL, 0);
> +		if (depth > ql2xmaxqdepth)
> +			depth = ql2xmaxqdepth;

Any particular reason why the ql2xmaxqdepth module-parameter is
being used as a high-water limit?  The module-param is (was) used 
as a global setting of queue-depth for all luns (quite inflexible).
By overriding:

	/sys/class/scsi_device/22:0:0:0/device/queue_depth

with a writable value, a user should be allowed to update the
value to something higher (max(unsigned short)?) based on the 
back-end storage.

--
Andrew

Re: [RFC PATCH 2.6.9-rc2] Add sysfs queue depth override to qla2xxx

[Jeremy Higdon]

On Tue, Sep 28, 2004 at 09:52:55AM -0700, Andrew Vasquez wrote:
> On Tuesday, September 28, 2004 12:54 AM, Jeremy Higdon wrote:
> > +static ssize_t
> > +qla2xxx_store_queue_depth(struct device *dev, const char *buf,
> > size_t count) +{
> > +	int			 depth;
> > +	struct scsi_device	*sdev = to_scsi_device(dev);
> > +
> > +	if (sdev->tagged_supported) {
> > +		depth = simple_strtoul(buf, NULL, 0);
> > +		if (depth > ql2xmaxqdepth)
> > +			depth = ql2xmaxqdepth;
> 
> Any particular reason why the ql2xmaxqdepth module-parameter is
> being used as a high-water limit?  The module-param is (was) used 
> as a global setting of queue-depth for all luns (quite inflexible).
> By overriding:
> 
> 	/sys/class/scsi_device/22:0:0:0/device/queue_depth
> 
> with a writable value, a user should be allowed to update the
> value to something higher (max(unsigned short)?) based on the 
> back-end storage.


I was trying to be conservative -- I didn't know the reason for
that limit.  By all means, let's remove it then.

Would you like me to regenerate the patch, or do you just want
to apply it to your internal source that will eventually be
fed back to us?

jeremy

Re: [RFC PATCH 2.6.9-rc2] Add sysfs queue depth override to qla2xxx

[James Bottomley]

On Tue, 2004-09-28 at 15:36, Jeremy Higdon wrote:
> I was trying to be conservative -- I didn't know the reason for
> that limit.  By all means, let's remove it then.
> 
> Would you like me to regenerate the patch, or do you just want
> to apply it to your internal source that will eventually be
> fed back to us?

Well, don't go overboard on this ... there is a limit to the number of
outstanding requests any queue can have at one time...there's not much
point going over that since the block layer will throttle you when you
reach it.  I think it's 128, but it might be 256 ... but anyway, not
much larger.

James

Re: [RFC PATCH 2.6.9-rc2] Add sysfs queue depth override to qla2xxx

[Jens Axboe]

On Tue, Sep 28 2004, James Bottomley wrote:
> On Tue, 2004-09-28 at 15:36, Jeremy Higdon wrote:
> > I was trying to be conservative -- I didn't know the reason for
> > that limit.  By all means, let's remove it then.
> > 
> > Would you like me to regenerate the patch, or do you just want
> > to apply it to your internal source that will eventually be
> > fed back to us?
> 
> Well, don't go overboard on this ... there is a limit to the number of
> outstanding requests any queue can have at one time...there's not much
> point going over that since the block layer will throttle you when you
> reach it.  I think it's 128, but it might be 256 ... but anyway, not
> much larger.

That depends on both the io scheduler and the nr_requests setting, I
don't think you should rely on any imposed block layer limit.

-- 
Jens Axboe

Re: [RFC PATCH 2.6.9-rc2] Add sysfs queue depth override to qla2xxx

[Andrew Vasquez]

On Tue, 28 Sep 2004, Jens Axboe wrote:
> On Tue, Sep 28 2004, James Bottomley wrote:
> > On Tue, 2004-09-28 at 15:36, Jeremy Higdon wrote:
> > > I was trying to be conservative -- I didn't know the reason for
> > > that limit.  By all means, let's remove it then.
> > > 
> > > Would you like me to regenerate the patch, or do you just want
> > > to apply it to your internal source that will eventually be
> > > fed back to us?
> > 
> > Well, don't go overboard on this ... there is a limit to the number of
> > outstanding requests any queue can have at one time...there's not much
> > point going over that since the block layer will throttle you when you
> > reach it.  I think it's 128, but it might be 256 ... but anyway, not
> > much larger.
> 
> That depends on both the io scheduler and the nr_requests setting, I
> don't think you should rely on any imposed block layer limit.
> 

So using scsi_device->request_queue->nr_requests as a highwater mark
is out of the question?  Looking through the call-chain during
queue-depth size manipulation:

	scsi_adjust_queue()
	  blk_queue_resize_tags()
	    init_tag_map()

there appears to be a restriction of (rq->nr_requests * 2) entries:

	if (depth > q->nr_requests * 2) {
		depth = q->nr_requests * 2;
		printk(KERN_ERR "%s: adjusted depth to %d\n",
				__FUNCTION__, depth);
	}

What's an acceptable compromise?

--
Andrew

Re: [RFC PATCH 2.6.9-rc2] Add sysfs queue depth override to qla2xxx

[Jens Axboe]

On Tue, Sep 28 2004, Andrew Vasquez wrote:
> On Tue, 28 Sep 2004, Jens Axboe wrote:
> > On Tue, Sep 28 2004, James Bottomley wrote:
> > > On Tue, 2004-09-28 at 15:36, Jeremy Higdon wrote:
> > > > I was trying to be conservative -- I didn't know the reason for
> > > > that limit.  By all means, let's remove it then.
> > > > 
> > > > Would you like me to regenerate the patch, or do you just want
> > > > to apply it to your internal source that will eventually be
> > > > fed back to us?
> > > 
> > > Well, don't go overboard on this ... there is a limit to the number of
> > > outstanding requests any queue can have at one time...there's not much
> > > point going over that since the block layer will throttle you when you
> > > reach it.  I think it's 128, but it might be 256 ... but anyway, not
> > > much larger.
> > 
> > That depends on both the io scheduler and the nr_requests setting, I
> > don't think you should rely on any imposed block layer limit.
> > 
> 
> So using scsi_device->request_queue->nr_requests as a highwater mark
> is out of the question?  Looking through the call-chain during

It can change anytime.

> queue-depth size manipulation:
> 
> 	scsi_adjust_queue()
> 	  blk_queue_resize_tags()
> 	    init_tag_map()
> 
> there appears to be a restriction of (rq->nr_requests * 2) entries:
> 
> 	if (depth > q->nr_requests * 2) {
> 		depth = q->nr_requests * 2;
> 		printk(KERN_ERR "%s: adjusted depth to %d\n",
> 				__FUNCTION__, depth);
> 	}
> 
> What's an acceptable compromise?

Yeah that logic isn't very nice. I think it's a good idea to keep the
tag depth at half the software depth, ie depth <= q->nr_requests. But
I'll remove the auto-adjust.

-- 
Jens Axboe

Re: [RFC PATCH 2.6.9-rc2] Add sysfs queue depth override to qla2xxx

[Jeremy Higdon]

On Wed, Sep 29, 2004 at 08:21:09AM +0200, Jens Axboe wrote:
> On Tue, Sep 28 2004, Andrew Vasquez wrote:
> > On Tue, 28 Sep 2004, Jens Axboe wrote:
> > > On Tue, Sep 28 2004, James Bottomley wrote:
> > > > 
> > > > Well, don't go overboard on this ... there is a limit to the number of
> > > > outstanding requests any queue can have at one time...there's not much
> > > > point going over that since the block layer will throttle you when you
> > > > reach it.  I think it's 128, but it might be 256 ... but anyway, not
> > > > much larger.
> > > 
> > > That depends on both the io scheduler and the nr_requests setting, I
> > > don't think you should rely on any imposed block layer limit.
> > > 
> > 
> > So using scsi_device->request_queue->nr_requests as a highwater mark
> > is out of the question?  Looking through the call-chain during
> 
> It can change anytime.
> 
> > queue-depth size manipulation:
> > 
> > 	scsi_adjust_queue()
> > 	  blk_queue_resize_tags()
> > 	    init_tag_map()
> > 
> > there appears to be a restriction of (rq->nr_requests * 2) entries:
> > 
> > 	if (depth > q->nr_requests * 2) {
> > 		depth = q->nr_requests * 2;
> > 		printk(KERN_ERR "%s: adjusted depth to %d\n",
> > 				__FUNCTION__, depth);
> > 	}
> > 
> > What's an acceptable compromise?
> 
> Yeah that logic isn't very nice. I think it's a good idea to keep the
> tag depth at half the software depth, ie depth <= q->nr_requests. But
> I'll remove the auto-adjust.


Jens, are you saying that the host driver should enforce this limit?
Which auto-adjust are you removing?

thanks

jeremy

Re: [RFC PATCH 2.6.9-rc2] Add sysfs queue depth override to qla2xxx

[Jens Axboe]

On Tue, Sep 28 2004, Jeremy Higdon wrote:
> On Wed, Sep 29, 2004 at 08:21:09AM +0200, Jens Axboe wrote:
> > On Tue, Sep 28 2004, Andrew Vasquez wrote:
> > > On Tue, 28 Sep 2004, Jens Axboe wrote:
> > > > On Tue, Sep 28 2004, James Bottomley wrote:
> > > > > 
> > > > > Well, don't go overboard on this ... there is a limit to the number of
> > > > > outstanding requests any queue can have at one time...there's not much
> > > > > point going over that since the block layer will throttle you when you
> > > > > reach it.  I think it's 128, but it might be 256 ... but anyway, not
> > > > > much larger.
> > > > 
> > > > That depends on both the io scheduler and the nr_requests setting, I
> > > > don't think you should rely on any imposed block layer limit.
> > > > 
> > > 
> > > So using scsi_device->request_queue->nr_requests as a highwater mark
> > > is out of the question?  Looking through the call-chain during
> > 
> > It can change anytime.
> > 
> > > queue-depth size manipulation:
> > > 
> > > 	scsi_adjust_queue()
> > > 	  blk_queue_resize_tags()
> > > 	    init_tag_map()
> > > 
> > > there appears to be a restriction of (rq->nr_requests * 2) entries:
> > > 
> > > 	if (depth > q->nr_requests * 2) {
> > > 		depth = q->nr_requests * 2;
> > > 		printk(KERN_ERR "%s: adjusted depth to %d\n",
> > > 				__FUNCTION__, depth);
> > > 	}
> > > 
> > > What's an acceptable compromise?
> > 
> > Yeah that logic isn't very nice. I think it's a good idea to keep the
> > tag depth at half the software depth, ie depth <= q->nr_requests. But
> > I'll remove the auto-adjust.
> 
> 
> Jens, are you saying that the host driver should enforce this limit?
> Which auto-adjust are you removing?

Sorry, I was not clear. The auto-adjust in the block layer should go
away. With a warning printed, the admin can increase the software queue
depth from user space by writing to the nr_requests sysfs file.

-- 
Jens Axboe

Re: [RFC PATCH 2.6.9-rc2] Add sysfs queue depth override to qla2xxx

[Jeremy Higdon]

So do we have a consensus on what the driver should limit queue
depth to?  Currently, it's 32 or ql2xmaxqdepth, if that was specified.
>From what I can see, ql2xmaxqdepth is effectively limited to 65535.

We don't want one lun to use host driver or host adapter resources
to the point that it starves other luns.  Ideally, the max would
depend on what else was attached, but I don't think we want to
make this too complicated.  Anyone changing the queue depth should
have a clue about what they're doing.

Andrew, how many command slots are there in the various adapters,
and do the continuation entries each eat a command slot?

jeremy

Re: [RFC PATCH 2.6.9-rc2] Add sysfs queue depth override to qla2xxx

[Andrew Vasquez]

On Tue, 2004-09-28 at 17:36, Jeremy Higdon wrote:
> So do we have a consensus on what the driver should limit queue
> depth to?  Currently, it's 32 or ql2xmaxqdepth, if that was specified.
> From what I can see, ql2xmaxqdepth is effectively limited to 65535.
> 
> We don't want one lun to use host driver or host adapter resources
> to the point that it starves other luns.  Ideally, the max would
> depend on what else was attached, but I don't think we want to
> make this too complicated.

I agree.

>   Anyone changing the queue depth should
> have a clue about what they're doing.
> 
> Andrew, how many command slots are there in the various adapters,
> and do the continuation entries each eat a command slot?
> 

Well, determining that can be complicated...

The request-queue size is based on the amount of SRAM available to the
ISP.   For most HBAs (qla2100, qla2200, qla2300, qla2310, qla2342) which
have an 128KB memory chip (per-port), the 8.x driver will allocate
2048-entry queue for requests.  

Many new(-er) boards (qla235x, qla236x) and embedded implementations
(fibre-down) have a 512KB or 1MB chip.  Not wanting to digress into
another layer of firmware resource-usage details, let's just say that
the extra memory allows for the firmware to manage a larger number of
requests.  The driver in these cases will allocate a 4096-entry
request-queue.

Now depending on the sizeof(dma_addr_t)
(qla2x00_config_dma_addressing()) a single (scsi_cmnd) command with 32
sg entries (assuming 4KB page size,  transferring 128KB of data) will
consume:

    sizeof(dma_addr_t) == 4 (32bit):

	 1	command IOCB (3 data segments)
	 5	continuation IOCBs (7 data segments per IOCB)
		- only one entry within the last continuation IOCB used
	--
	 6	request entries

and 

    sizeof(dma_addr_t) == 8 (64bit):

	 1	command IOCB (2 data segments)
	 6	continuation IOCBs (5 data segments per IOCB)
	--
	 7	request entries

Extending the basic formula, to transfer X KBs of data, you'll consume:

	         32bit    64bit
	      -----------------
	256KB -     10       14
	512KB -     19       27   request entries

As an example, taking the 512KB transfer consuming 27 request entries,
having an 2048 request-queue depth will support the transfer of 75 
(2048 / 27) concurrent 512KB transfer requests; ~150 concurrent requests
with an 4096 request-queue depth.

Here's another small table showing total requests per request's size
with an 2048 request-queue depth (multiply by 2 for an 4096 depth):

	         32bit    64bit
	      -----------------
	128KB -    341      292
	256KB -    204      146
	512KB -    107       75   concurrent requests

I hope this answers your request-queue usage question.  

I'm not sure if it brings us any closer to answering the question of
'what's the max queue-depth we support?'  Is it even possible, since as
you mentioned earlier, the admin will have to possess some outside
knowledge (backend-storage, I/O type, I/O patterns) while tuning the
queue-depth value.

--
Andrew








aTypically you'll find 128KB of memory available to the ISP, in
thoseMost implementations tend the request-queue can be , typically
there is a 128KiB for each 

> jeremy

Re: [RFC PATCH 2.6.9-rc2] Add sysfs queue depth override to qla2xxx

[Jeremy Higdon]

On Wed, Sep 29, 2004 at 09:41:33AM -0700, Andrew Vasquez wrote:
> On Tue, 2004-09-28 at 17:36, Jeremy Higdon wrote:
> > So do we have a consensus on what the driver should limit queue
> > depth to?  Currently, it's 32 or ql2xmaxqdepth, if that was specified.
> > From what I can see, ql2xmaxqdepth is effectively limited to 65535.
> > 
> > We don't want one lun to use host driver or host adapter resources
> > to the point that it starves other luns.  Ideally, the max would
> > depend on what else was attached, but I don't think we want to
> > make this too complicated.
> 
> I agree.
> 
> >   Anyone changing the queue depth should
> > have a clue about what they're doing.
> > 
> > Andrew, how many command slots are there in the various adapters,
> > and do the continuation entries each eat a command slot?
> > 
> 
> Well, determining that can be complicated...
> 
> The request-queue size is based on the amount of SRAM available to the
> ISP.   For most HBAs (qla2100, qla2200, qla2300, qla2310, qla2342) which
> have an 128KB memory chip (per-port), the 8.x driver will allocate
> 2048-entry queue for requests.  
> 
> Many new(-er) boards (qla235x, qla236x) and embedded implementations
> (fibre-down) have a 512KB or 1MB chip.  Not wanting to digress into
> another layer of firmware resource-usage details, let's just say that
> the extra memory allows for the firmware to manage a larger number of
> requests.  The driver in these cases will allocate a 4096-entry
> request-queue.

I thought that there was not a one to one mapping between the request
queue size and the number of commands the chip/board could hold.

Anyway, this is probably far enough down that rathole.

> I'm not sure if it brings us any closer to answering the question of
> 'what's the max queue-depth we support?'  Is it even possible, since as
> you mentioned earlier, the admin will have to possess some outside
> knowledge (backend-storage, I/O type, I/O patterns) while tuning the
> queue-depth value.

Since there's no obvious answer, let's not try to out think the admin.
Andrew, I think you can just choose a maximum.  I would suggest that
the maximum be the same as the maximum for ql2xmaxqdepth, just to be
consistent.  Is that indeed 65535?

jeremy

RE: [RFC PATCH 2.6.9-rc2] Add sysfs queue depth override to qla2xxx

[Andrew Vasquez]

On Tuesday, September 28, 2004 7:06 AM, James Bottomley wrote:
> On Tue, 2004-09-28 at 03:54, Jeremy Higdon wrote:
> > 
> > Found a bug in the patch.  It returned an incorrect count if
> > tagged_supported was not true.
> 
> I haven't had time to check yet, but I believe I remember queue depth
> being also a parameter that has to be communicated to the card's
> firmware for the sizing of an internal queue.

Not needed for the fibre-channel driver.  The only rate-limiter is the
size of the host request-queue.

--
Andrew

[RFC PATCH 2.6.9-rc2] Add sysfs queue depth override to qla2xxx

[Jeremy Higdon]

This patch is to QLA2xxx version 8.00.00b15-k, and it allows users
to override the default driver queue depth for a target by making
the queue_depth sysfs attribute writeable.

I based this on the code in the 53c700 driver.

Andrew, please apply if it looks correct to you and James.

Let me know if you'd like me to regenerate against a different qla2xxx
version.

thanks

Jeremy


===== drivers/scsi/qla2xxx/qla_os.c 1.41 vs edited =====
--- 1.41/drivers/scsi/qla2xxx/qla_os.c	2004-08-09 16:48:29 -07:00
+++ edited/drivers/scsi/qla2xxx/qla_os.c	2004-09-22 00:12:41 -07:00
@@ -159,6 +159,20 @@
 
 static int qla2x00_proc_info(struct Scsi_Host *, char *, char **,
     off_t, int, int);
+static ssize_t qla2xxx_store_queue_depth(struct device *dev, const char *buf, size_t count);
+
+static struct device_attribute qla2xxx_queue_depth_attr = {
+	.attr = {
+		.name =		"queue_depth",
+		.mode =		S_IWUSR,
+	},
+	.store = qla2xxx_store_queue_depth,
+};
+
+static struct device_attribute *qla2xxx_dev_attrs[] = {
+	&qla2xxx_queue_depth_attr,
+	NULL,
+};
 
 static struct scsi_host_template qla2x00_driver_template = {
 	.module			= THIS_MODULE,
@@ -184,6 +198,8 @@
 	 * which equates to 0x800000 sectors.
 	 */
 	.max_sectors		= 0xFFFF,
+
+	.sdev_attrs		= qla2xxx_dev_attrs,
 };
 
 static struct scsi_transport_template *qla2xxx_transport_template = NULL;
@@ -1797,6 +1813,22 @@
 	}
 
 	return (0);
+}
+
+static ssize_t
+qla2xxx_store_queue_depth(struct device *dev, const char *buf, size_t count)
+{
+	int			 depth;
+	struct scsi_device	*sdev = to_scsi_device(dev);
+
+	if (sdev->tagged_supported) {
+		depth = simple_strtoul(buf, NULL, 0);
+		if (depth > ql2xmaxqdepth)
+			return -EINVAL;
+		scsi_adjust_queue_depth(sdev, MSG_ORDERED_TAG, depth);
+		return count;
+	}
+	return 1;
 }
 
 /**

Re: [RFC PATCH 2.6.9-rc2] Add sysfs queue depth override to qla2xxx

[Jeremy Higdon]

On Sun, Sep 26, 2004 at 11:10:03PM -0700, Jeremy Higdon wrote:
> This patch is to QLA2xxx version 8.00.00b15-k, and it allows users
> to override the default driver queue depth for a target by making
> the queue_depth sysfs attribute writeable.
> 
> I based this on the code in the 53c700 driver.
> 
> Andrew, please apply if it looks correct to you and James.
> 
> Let me know if you'd like me to regenerate against a different qla2xxx
> version.
> 
> thanks
> 
> Jeremy

signed-off-by: Jeremy Higdon <jeremy@sgi.com>

Re: [RFC PATCH 2.6.9-rc2] Add sysfs queue depth override to qla2xxx

[Jeremy Higdon]

On Sun, Sep 26, 2004 at 11:10:03PM -0700, Jeremy Higdon wrote:
> This patch is to QLA2xxx version 8.00.00b15-k, and it allows users
> to override the default driver queue depth for a target by making
> the queue_depth sysfs attribute writeable.
> 
> I based this on the code in the 53c700 driver.
> 
> Andrew, please apply if it looks correct to you and James.
> 
> Let me know if you'd like me to regenerate against a different qla2xxx
> version.
> 
> thanks
> 
> Jeremy

Found a bug in the patch.  It returned an incorrect count if tagged_supported
was not true.

signed-off-by: Jeremy Higdon  <jeremy@sgi.com>


===== drivers/scsi/qla2xxx/qla_os.c 1.41 vs edited =====
--- 1.41/drivers/scsi/qla2xxx/qla_os.c	2004-08-09 16:48:29 -07:00
+++ edited/drivers/scsi/qla2xxx/qla_os.c	2004-09-28 00:34:50 -07:00
@@ -159,6 +159,20 @@
 
 static int qla2x00_proc_info(struct Scsi_Host *, char *, char **,
     off_t, int, int);
+static ssize_t qla2xxx_store_queue_depth(struct device *dev, const char *buf, size_t count);
+
+static struct device_attribute qla2xxx_queue_depth_attr = {
+	.attr = {
+		.name =		"queue_depth",
+		.mode =		S_IWUSR,
+	},
+	.store = qla2xxx_store_queue_depth,
+};
+
+static struct device_attribute *qla2xxx_dev_attrs[] = {
+	&qla2xxx_queue_depth_attr,
+	NULL,
+};
 
 static struct scsi_host_template qla2x00_driver_template = {
 	.module			= THIS_MODULE,
@@ -184,6 +198,8 @@
 	 * which equates to 0x800000 sectors.
 	 */
 	.max_sectors		= 0xFFFF,
+
+	.sdev_attrs		= qla2xxx_dev_attrs,
 };
 
 static struct scsi_transport_template *qla2xxx_transport_template = NULL;
@@ -1797,6 +1813,21 @@
 	}
 
 	return (0);
+}
+
+static ssize_t
+qla2xxx_store_queue_depth(struct device *dev, const char *buf, size_t count)
+{
+	int			 depth;
+	struct scsi_device	*sdev = to_scsi_device(dev);
+
+	if (sdev->tagged_supported) {
+		depth = simple_strtoul(buf, NULL, 0);
+		if (depth > ql2xmaxqdepth)
+			depth = ql2xmaxqdepth;
+		scsi_adjust_queue_depth(sdev, MSG_ORDERED_TAG, depth);
+	}
+	return count;
 }
 
 /**

Re: [RFC PATCH 2.6.9-rc2] Add sysfs queue depth override to qla2xxx

[James Bottomley]

On Tue, 2004-09-28 at 03:54, Jeremy Higdon wrote:
> On Sun, Sep 26, 2004 at 11:10:03PM -0700, Jeremy Higdon wrote:
> > This patch is to QLA2xxx version 8.00.00b15-k, and it allows users
> > to override the default driver queue depth for a target by making
> > the queue_depth sysfs attribute writeable.
> > 
> > I based this on the code in the 53c700 driver.
> > 
> > Andrew, please apply if it looks correct to you and James.
> > 
> > Let me know if you'd like me to regenerate against a different qla2xxx
> > version.
> > 
> > thanks
> > 
> > Jeremy
> 
> Found a bug in the patch.  It returned an incorrect count if tagged_supported
> was not true.

I haven't had time to check yet, but I believe I remember queue depth
being also a parameter that has to be communicated to the card's
firmware for the sizing of an internal queue.  Could you check ... and
if that is the case, we'll have to communicate this change to the card
as well.

James