Mike Christie wrote:
So what I am asking is we can do the setting of starget->can_queue from:
1. kernel devinfo table like in this patch.
2. udev rule.
3. userspace scsi daemon that handles lots of junk scsi-ml in the kernel
does not want to handle.
Sure. all can work.
My preferences:
- I prefer to set max's before we start to send i/o that checks against
them, meaning I like the kernel devinfo table better. But, I can't see a
scenario where any max would likely be exceeded (unless the max is
really really low) before a user-space thing could set it.
- Queue depth handling - giving the headaches, the closer to the
hardware the better. The ramp-down should be in the kernel/driver and
not userspace. Ramp-up can be in user-space. Note: queue depth should be
per lun, and thus never touch target can_queue limits. So queue_depths
and tgt can_queue shouldn't be discussed together. (Yes, even with jbods
where the tgt and lun are the same - there will be a relationship, but
I still wouldn't marry the two).
-- james
--
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
