Michael Reed wrote: > Hi Giri, > > Giridhar Malavali wrote: >> 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. > > Yes. This was the problem we had with qla2xxx. Sites would tune > their cluster to avoid most queue fulls and qla2xxx would merrily > ramp queue depths back up to 32. > >> 2) You want this to be controlled at device/LUN level. So the >> threshold is per LUN rather than target. > > That's the way it is today and we're okay with this arrangement. > This allows for static "performance" balancing. Luns designated > for high throughput can receive more outstanding commands than those > only lightly used. > >> 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. > > Require, no. This is the way it is today. Desirable, YES. > > This would be useful in both single system and cluster environments > allowing the administrator to not have to be so conservative with > their per-lun queue depth calculations. On the raids we use, a > "target" corresponds to a fibre cable entering a raid > controller. Every storage entity presented is a "lun". The max > number of outstanding commands is per raid controller. I think this > is a good idea and would support its implementation. :) I don't > believe it eliminates the need for the ability to set a queue depth > "per lun" but I could be talked into that belief. In general, handling of queue full in a multi-initiator environment is tricky in that a queue full status may be returned when the initiator sending the command has no outstanding commands.... Mike > > Mike > >> -- 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 -- 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
