Michael,
Can u please clarify following things.
1) You are ok with scsi mid layer adjusting the queue depth as long as
the ramp-up code does not over shoot the user set threshold.
2) You want this to be controlled at device/LUN level. So the
threshold is per LUN rather than target.
3) From your previous mail, I understand that you don't require a
combined limit per target. Say the total queue depth for all LUN's on
a particular target should not exceed some threshold.
-- Giri
On Sep 24, 2009, at 2:02 PM, Michael Reed wrote:
The LSI fusion FC driver did not exhibit the problem. It doesn't
dynamically re-adjust the queue depth. I have limited experience
with Emulex and cannot comment.
Thank you for offering to do the work. I'll gladly review and test
anything you'd care to send my way.
Mike
Giridhar Malavali wrote:
I will be more than willing to do these changes. Just curious, was
this seen on non qla2xxx drivers too.
-- Giri
On Sep 24, 2009, at 12:15 PM, Michael Reed wrote:
To answer your query, yes. Ultimately, I believe the ml should be
modified to view a user space modification to a lun's queue depth
as an upper bound. I don't care, much, whether the system
dynamically
adjusts the queue depth or leaves it alone as long as it honors the
value programmed via user space.
Are you volunteering to do the work? :) How can I help?
Thanks,
Mike
Giridhar Malavali wrote:
Hi Michael,
Here are the patches..
http://marc.info/?a=119828370000006&r=1&w=2 .
http://marc.info/?l=linux-scsi&m=125201657106722&w=2
Thanks,
Giridhar.M.B
On Sep 24, 2009, at 7:42 AM, Michael Reed wrote:
Hello,
The purpose of the queue full tracking patch in qla2xxx is to
keep the driver from changing a user space override of the queue
depth back to what the driver believes is the "correct" value.
The raid devices that we use have per raid controller queue depth
limits and have at times demonstrated, uh, bad behavior when
their queues are full for sustained periods of time. SGI needs
to be able to set queue depth for a lun based upon access patterns
and performance requirements of the entire cluster and know that
it will be honored as an upper bound.
Might you provide a pointer to the recently submitted patches?
I haven't followed linux-scsi in a while.... I'll be quite
happy to take a look.
Thanks,
Mike
Giridhar Malavali wrote:
Hi Michael/James,
Patches were submitted to move queue ramp up/down code
recently to
scsi mid layer. With this change, I don't see a need for a module
parameter to disable queuefull tracking in qla2xxx driver.
Andrew,
mentioned that this got introduced to avoid wobbling behavior on
the
wire due to queue depth modifications. Just wanted to check
whether
the same need to be done in scsi mid layer too.
Thanks,
Giridhar.M.B
--
To unsubscribe from this list: send the line "unsubscribe linux-
scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-
info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
