Re: [PATCH] scsi : set target can_queue from devinfo flags

[James Smart <James.Smart@Emulex.Com>]

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