Re: [PATCH] ibmvscsis: Fix max transfer length

2017-01-13 Thread Bart Van Assche
On Wed, 2017-01-11 at 13:52 -0600, Bryant G. Ly wrote:
> Current code incorrectly calculates the max transfer length, since
> it is assuming a 4k page table, but ppc64 all run on 64k page tables.

This patch has been queued for kernel v4.10. Thanks for the patch.

Bart.--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH] ibmvscsis: Fix max transfer length

2017-01-11 Thread Bryant G. Ly
Current code incorrectly calculates the max transfer length, since
it is assuming a 4k page table, but ppc64 all run on 64k page tables.

Cc: sta...@vger.kernel.org
Reported-by: Steven Royer 
Tested-by: Steven Royer 
Signed-off-by: Bryant G. Ly 
---
 drivers/scsi/ibmvscsi_tgt/ibmvscsi_tgt.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/scsi/ibmvscsi_tgt/ibmvscsi_tgt.c 
b/drivers/scsi/ibmvscsi_tgt/ibmvscsi_tgt.c
index 8fb5c54..9c91e75 100644
--- a/drivers/scsi/ibmvscsi_tgt/ibmvscsi_tgt.c
+++ b/drivers/scsi/ibmvscsi_tgt/ibmvscsi_tgt.c
@@ -46,6 +46,7 @@
 
 #defineINITIAL_SRP_LIMIT   800
 #defineDEFAULT_MAX_SECTORS 256
+#define MAX_TXU1024 * 1024
 
 static uint max_vdma_size = MAX_H_COPY_RDMA;
 
@@ -1443,7 +1444,7 @@ static long ibmvscsis_adapter_info(struct scsi_info 
*vscsi,
info->mad_version = cpu_to_be32(MAD_VERSION_1);
info->os_type = cpu_to_be32(LINUX);
memset(>port_max_txu[0], 0, sizeof(info->port_max_txu));
-   info->port_max_txu[0] = cpu_to_be32(128 * PAGE_SIZE);
+   info->port_max_txu[0] = cpu_to_be32(MAX_TXU);
 
dma_wmb();
rc = h_copy_rdma(sizeof(*info), vscsi->dds.window[LOCAL].liobn,
-- 
2.5.4 (Apple Git-61)

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH] ibmvscsis: Fix max transfer length

2017-01-11 Thread Bryant G. Ly
Current code incorrectly calculates the max transfer length, since
it is assuming a 4k page table, but ppc64 all run on 64k page tables.

Cc: sta...@vger.kernel.org
Reported-by: Steven Royer 
Tested-by: Steven Royer 
Signed-off-by: Bryant G. Ly 
---
 drivers/scsi/ibmvscsi_tgt/ibmvscsi_tgt.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/scsi/ibmvscsi_tgt/ibmvscsi_tgt.c 
b/drivers/scsi/ibmvscsi_tgt/ibmvscsi_tgt.c
index 8fb5c54..3b4d36b 100644
--- a/drivers/scsi/ibmvscsi_tgt/ibmvscsi_tgt.c
+++ b/drivers/scsi/ibmvscsi_tgt/ibmvscsi_tgt.c
@@ -46,6 +46,7 @@
 
 #defineINITIAL_SRP_LIMIT   800
 #defineDEFAULT_MAX_SECTORS 256
+#define MAX_TXU1024
 
 static uint max_vdma_size = MAX_H_COPY_RDMA;
 
@@ -1443,7 +1444,7 @@ static long ibmvscsis_adapter_info(struct scsi_info 
*vscsi,
info->mad_version = cpu_to_be32(MAD_VERSION_1);
info->os_type = cpu_to_be32(LINUX);
memset(>port_max_txu[0], 0, sizeof(info->port_max_txu));
-   info->port_max_txu[0] = cpu_to_be32(128 * PAGE_SIZE);
+   info->port_max_txu[0] = cpu_to_be32(MAX_TXU);
 
dma_wmb();
rc = h_copy_rdma(sizeof(*info), vscsi->dds.window[LOCAL].liobn,
-- 
2.5.4 (Apple Git-61)

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH] ibmvscsis: Fix max transfer length

2017-01-11 Thread Bryant G. Ly
Current code incorrectly calculates the max transfer length, since
it is assuming a 4k page table, but ppc64 all run on 64k page tables.

Cc: sta...@vger.kernel.org
Reported-by: Steven Royer 
Tested-by: Steven Royer 
Signed-off-by: Bryant G. Ly 
---
 drivers/scsi/ibmvscsi_tgt/ibmvscsi_tgt.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/scsi/ibmvscsi_tgt/ibmvscsi_tgt.c 
b/drivers/scsi/ibmvscsi_tgt/ibmvscsi_tgt.c
index 8fb5c54..3b4d36b 100644
--- a/drivers/scsi/ibmvscsi_tgt/ibmvscsi_tgt.c
+++ b/drivers/scsi/ibmvscsi_tgt/ibmvscsi_tgt.c
@@ -46,6 +46,7 @@
 
 #defineINITIAL_SRP_LIMIT   800
 #defineDEFAULT_MAX_SECTORS 256
+#define MAX_TXU1024
 
 static uint max_vdma_size = MAX_H_COPY_RDMA;
 
@@ -1443,7 +1444,7 @@ static long ibmvscsis_adapter_info(struct scsi_info 
*vscsi,
info->mad_version = cpu_to_be32(MAD_VERSION_1);
info->os_type = cpu_to_be32(LINUX);
memset(>port_max_txu[0], 0, sizeof(info->port_max_txu));
-   info->port_max_txu[0] = cpu_to_be32(128 * PAGE_SIZE);
+   info->port_max_txu[0] = cpu_to_be32(MAX_TXU);
 
dma_wmb();
rc = h_copy_rdma(sizeof(*info), vscsi->dds.window[LOCAL].liobn,
-- 
2.5.4 (Apple Git-61)

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] ibmvscsis: Fix max transfer length

2017-01-11 Thread Bryant G. Ly

On 1/11/17 12:57 PM, Bart Van Assche wrote:


On Wed, 2017-01-11 at 12:02 -0600, Bryant G. Ly wrote:

Current code incorrectly calculates the max transfer length, since
it is assuming a 4k page table, but ppc64 all run on 64k page tables.

Cc: sta...@vger.kernel.org
Reported-by: Steven Royer 
Tested-by: Steven Royer 
Signed-off-by: Bryant G. Ly 
---
  drivers/scsi/ibmvscsi_tgt/ibmvscsi_tgt.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/scsi/ibmvscsi_tgt/ibmvscsi_tgt.c
b/drivers/scsi/ibmvscsi_tgt/ibmvscsi_tgt.c
index 8fb5c54..792a8bd 100644
--- a/drivers/scsi/ibmvscsi_tgt/ibmvscsi_tgt.c
+++ b/drivers/scsi/ibmvscsi_tgt/ibmvscsi_tgt.c
@@ -1443,7 +1443,7 @@ static long ibmvscsis_adapter_info(struct scsi_info
*vscsi,
info->mad_version = cpu_to_be32(MAD_VERSION_1);
info->os_type = cpu_to_be32(LINUX);
memset(>port_max_txu[0], 0, sizeof(info->port_max_txu));
-   info->port_max_txu[0] = cpu_to_be32(128 * PAGE_SIZE);
+   info->port_max_txu[0] = cpu_to_be32(16 * PAGE_SIZE);
  
  	dma_wmb();

rc = h_copy_rdma(sizeof(*info), vscsi->dds.window[LOCAL].liobn,

Hello Bryant,

The old limit was intended to be 128 * 4 KB = 512 KB. The new limit is 16 *
64 KB = 1024 KB. Is that intended?

Do I understand correctly that the max_txu value is independent of the page
size? If so, have you considered to introduce a #define for the max_mtu
value that specifies max_mtu as a number instead of as a multiple of the
page size? At least in the SLES 10 SP3 ibmvscsis.c code max_mtu was not
defined as a multiple of the page size.


Hi Bart,

Thanks for the review. You are correct, max_txu is independent of the 
page size.

A define is probably best.

The reason for this is people who are using tcmu-runner, they have a max 
transfer
length of 1024KB, so if you exceed this value, then commands will fail. 
Thus to prevent
people from experiencing this issue, we are going to limit our driver to 
that cap.


The "allowed values" from a typical AIX disk can go all the way up to 
16MB. Typically

the max values do default at 512KB though.

-Bryant.

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] ibmvscsis: Fix max transfer length

2017-01-11 Thread Bart Van Assche
On Wed, 2017-01-11 at 12:02 -0600, Bryant G. Ly wrote:
> Current code incorrectly calculates the max transfer length, since
> it is assuming a 4k page table, but ppc64 all run on 64k page tables.
> 
> Cc: sta...@vger.kernel.org
> Reported-by: Steven Royer 
> Tested-by: Steven Royer 
> Signed-off-by: Bryant G. Ly 
> ---
>  drivers/scsi/ibmvscsi_tgt/ibmvscsi_tgt.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/scsi/ibmvscsi_tgt/ibmvscsi_tgt.c
> b/drivers/scsi/ibmvscsi_tgt/ibmvscsi_tgt.c
> index 8fb5c54..792a8bd 100644
> --- a/drivers/scsi/ibmvscsi_tgt/ibmvscsi_tgt.c
> +++ b/drivers/scsi/ibmvscsi_tgt/ibmvscsi_tgt.c
> @@ -1443,7 +1443,7 @@ static long ibmvscsis_adapter_info(struct scsi_info
> *vscsi,
>   info->mad_version = cpu_to_be32(MAD_VERSION_1);
>   info->os_type = cpu_to_be32(LINUX);
>   memset(>port_max_txu[0], 0, sizeof(info->port_max_txu));
> - info->port_max_txu[0] = cpu_to_be32(128 * PAGE_SIZE);
> + info->port_max_txu[0] = cpu_to_be32(16 * PAGE_SIZE);
>  
>   dma_wmb();
>   rc = h_copy_rdma(sizeof(*info), vscsi->dds.window[LOCAL].liobn,

Hello Bryant,

The old limit was intended to be 128 * 4 KB = 512 KB. The new limit is 16 *
64 KB = 1024 KB. Is that intended?

Do I understand correctly that the max_txu value is independent of the page
size? If so, have you considered to introduce a #define for the max_mtu
value that specifies max_mtu as a number instead of as a multiple of the
page size? At least in the SLES 10 SP3 ibmvscsis.c code max_mtu was not
defined as a multiple of the page size.

Thanks,

Bart.--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH] ibmvscsis: Fix max transfer length

2017-01-11 Thread Bryant G. Ly
Current code incorrectly calculates the max transfer length, since
it is assuming a 4k page table, but ppc64 all run on 64k page tables.

Cc: sta...@vger.kernel.org
Reported-by: Steven Royer 
Tested-by: Steven Royer 
Signed-off-by: Bryant G. Ly 
---
 drivers/scsi/ibmvscsi_tgt/ibmvscsi_tgt.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/scsi/ibmvscsi_tgt/ibmvscsi_tgt.c 
b/drivers/scsi/ibmvscsi_tgt/ibmvscsi_tgt.c
index 8fb5c54..792a8bd 100644
--- a/drivers/scsi/ibmvscsi_tgt/ibmvscsi_tgt.c
+++ b/drivers/scsi/ibmvscsi_tgt/ibmvscsi_tgt.c
@@ -1443,7 +1443,7 @@ static long ibmvscsis_adapter_info(struct scsi_info 
*vscsi,
info->mad_version = cpu_to_be32(MAD_VERSION_1);
info->os_type = cpu_to_be32(LINUX);
memset(>port_max_txu[0], 0, sizeof(info->port_max_txu));
-   info->port_max_txu[0] = cpu_to_be32(128 * PAGE_SIZE);
+   info->port_max_txu[0] = cpu_to_be32(16 * PAGE_SIZE);
 
dma_wmb();
rc = h_copy_rdma(sizeof(*info), vscsi->dds.window[LOCAL].liobn,
-- 
2.5.4 (Apple Git-61)

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html