On 01/13/2016 02:25 PM, Sheng Yang wrote:
What's bothered me is what would happen if the speed of block layer sending command is faster than TCMU userspace can handle, e.g. due to temporarily network interrupt or network downgrade. Then it may result in command TIMEDOUT, thus result in upper layer error as well. Since block layer would only send queue_depth mount a command, so they won't try more command in the case of ring can hold all of them, and wait for userspace to handle, which is more gracefully way of handling things.
Yes, good point, true. I wonder how existing hardware and software handles this.
Sure, and I would like to check the possibility of zero-copy as well. There are many things we could potentially improve TCMU.
Sure. Did you want to get into talking about zero copy now? Are there any ways to do this that don't involve page flipping or Infiniband?
As I said, I am worrying about ring buffer result in kernel reports hardware error, at least that can be prevented by use a buffer adjusted according to queue_depth and max_sectors.
What values relative to the TCMU ring buffer's size would you propose for those two values?
Regards -- Andy -- To unsubscribe from this list: send the line "unsubscribe target-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
