On 09/12/2013 06:30 PM, Bart Van Assche wrote: > On 09/12/13 18:16, Jack Wang wrote: >> On 09/12/2013 12:16 AM, David Dillow wrote: >>> On Tue, 2013-09-10 at 19:44 +0200, Bart Van Assche wrote: >>>> If this name was not yet in use in any interface that is visible in >>>> user >>>> space, I would agree that we should come up with a better name. >>>> However, >>>> the SCSI mid-layer already uses that name today to export the queue >>>> size. To me this looks like a good reason to use the name "can_queue" ? >>>> An example: >>>> >>>> $ cat /sys/class/scsi_host/host93/can_queue >>>> 62 >>> >>> Yes, I know it has been used before, but I'm torn between not furthering >>> a bad naming choice and consistency. Foolish consistency and all that... >>> >>> I really don't like "can_queue", but I'll not complain if Roland decides >>> to take it as-is. >> >> What the allow range for this queue size? >> Default cmd_per_lun and can_queue with same value makes no sense to me. >> Could we bump can_queue to bigger value like 512? > > Increasing the default value is only necessary when using a hard disk > array at the target side. When using a single hard disk or an SSD at the > target side the default value is fine. > > Bart. > Agree, from another side increasing default can_queue value is harmless for single harddisk/SSD, but will boot performance for multiple LUN attached to same host, so why not?
Jack -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
