[ofa-general] Fwd: ipath-23-srp-limit-queued-commands.patch,

[Michael S. Tsirkin]

> ----- Forwarded message from Vu Pham <vuhuong at mellanox.com> -----
> 
> Subject: ipath-23-srp-limit-queued-commands.patch,
> Date: Tue, 1 May 2007 19:30:48 +0300
> From: Vu Pham <vuhuong at mellanox.com>
> 
> Hi,
>    This patch 
> kernel_patches/fixes/ipath-23-srp-limit-queued-commands.patch 
> which change .can_queue = SRP_SQ_SIZE   to   .can_queue = 1
> hurts our srp performance. It limits our srp performance at 
> ~210 MB/s - without it our srp performance can reach 1.35 
> GB/s using the same configuration
> 
> Please remove it or apply it for whoever choose ipath as 
> their hw
> 
> thanks,
> -vu
> 
> ----- End forwarded message -----

I missed the fact that the patch with ipath- prefix actually
changed SRP for all devices. How come?

The comment says:

	Limit the number of queued SCSI commands (over SRP) to one.

	This patch works around a limitation that requires the number of SRP
	requests in progress to one. Further investigation of this limitation
	continues.

	From: Jeremy Brown <jeremy.brown at qlogic.com>

And this was queued at Feb 7, apparently with no progress in the investigation.
So not only is this not doing the right thing, AFAIK no problem was reported
publically and no one seems to be likely to find out why is it somehow helpful
either.

At this point I'm inclined to think the right thing is to remove this hack.
We can add a module parameter to limit the number of commands if
that's the only thing that makes qlogic hardware tick.

Bryan, are there other such hacks? I really expect the ipath-XX series to
only touch the ipath driver.

-- 
MST