IB/srp: Add 64-bit LUN support
Subsystems (5)
PATCH 1/1 IB/srp: Add 64-bit LUN support
The largest LUN number that has been tested is 0xd2003fff00000000.
Checked the following structure sizes with gdb:
* sizeof(struct srp_cmd) = 48
* sizeof(struct srp_tsk_mgmt) = 48
* sizeof(struct srp_aer_req) = 36
The ibmvscsi changes have been compile tested only (on a PPC system).
--- drivers/infiniband/ulp/srp/ib_srp.c | 8 ++++---- drivers/scsi/ibmvscsi/ibmvscsi.c | 6 +++--- include/scsi/srp.h | 7 ++++--- 3 files changed, 11 insertions(+), 10 deletions(-)
drivers/infiniband/ulp/srp/ib_srp.c +4 -4
@@ -1841,7 +1841,7 @@ static void srp_process_aer_req(struct srp_rdma_ch *ch,s32 delta =be32_to_cpu (req->req_lim_delta);shost_printk (KERN_ERR , target->scsi_host,PFX -"ignoring AER for LUN %llu\n" ,be64_to_cpu (req->lun)); +"ignoring AER for LUN %llu\n" ,scsilun_to_int (&req->lun));if (srp_response_common (ch, delta, &rsp,sizeof (rsp))) shost_printk(KERN_ERR, target->scsi_host, PFX
@@ -2033,7 +2033,7 @@ static int srp_queuecommand(struct Scsi_Host *shost, struct scsi_cmnd *scmnd)memset (cmd,0 ,sizeof *cmd); cmd->opcode =SRP_CMD ; - cmd->lun =cpu_to_be64 ((u64 ) scmnd->device->lun <<48 ); +int_to_scsilun (scmnd->device->lun, &cmd->lun); cmd->tag = tag;memcpy (cmd->cdb, scmnd->cmnd, scmnd->cmd_len);
@@ -2448,7 +2448,7 @@ static int srp_send_tsk_mgmt(struct srp_rdma_ch *ch, u64 req_tag,memset (tsk_mgmt,0 ,sizeof *tsk_mgmt); tsk_mgmt->opcode =SRP_TSK_MGMT ; - tsk_mgmt->lun =cpu_to_be64 ((u64 ) lun <<48 ); +int_to_scsilun (lun, &tsk_mgmt->lun); tsk_mgmt->tag = req_tag |SRP_TAG_TSK_MGMT ; tsk_mgmt->tsk_mgmt_func = func; tsk_mgmt->task_tag = req_tag;
@@ -3145,7 +3145,7 @@ static ssize_t srp_create_target(struct device *dev, target_host->transportt = ib_srp_transport_template; target_host->max_channel =0 ; target_host->max_id =1 ; - target_host->max_lun =SRP_MAX_LUN ; + target_host->max_lun =-1LL ; target_host->max_cmd_len =sizeof ((struct srp_cmd *) (void *)0L )->cdb; target =host_to_target (target_host);
drivers/scsi/ibmvscsi/ibmvscsi.c +3 -3
@@ -1053,7 +1053,7 @@ static int ibmvscsi_queuecommand_lck(struct scsi_cmnd *cmnd,memset (srp_cmd,0x00 ,SRP_MAX_IU_LEN ); srp_cmd->opcode =SRP_CMD ;memcpy (srp_cmd->cdb, cmnd->cmnd,sizeof (srp_cmd->cdb)); - srp_cmd->lun =cpu_to_be64 (((u64 )lun) <<48 ); +int_to_scsilun (lun, &srp_cmd->lun);if (!map_data_for_srp_cmd (cmnd, evt_struct, srp_cmd, hostdata->dev)) {if (!firmware_has_feature (FW_FEATURE_CMO ))
@@ -1529,7 +1529,7 @@ static int ibmvscsi_eh_abort_handler(struct scsi_cmnd *cmd)/* Set up an abort SRP command */ memset (tsk_mgmt,0x00 ,sizeof (*tsk_mgmt)); tsk_mgmt->opcode =SRP_TSK_MGMT ; - tsk_mgmt->lun =cpu_to_be64 (((u64 ) lun) <<48 ); +int_to_scsilun (lun, &tsk_mgmt->lun); tsk_mgmt->tsk_mgmt_func =SRP_TSK_ABORT_TASK ; tsk_mgmt->task_tag = (u64 ) found_evt;
@@ -1652,7 +1652,7 @@ static int ibmvscsi_eh_device_reset_handler(struct scsi_cmnd *cmd)/* Set up a lun reset SRP command */ memset (tsk_mgmt,0x00 ,sizeof (*tsk_mgmt)); tsk_mgmt->opcode =SRP_TSK_MGMT ; - tsk_mgmt->lun =cpu_to_be64 (((u64 ) lun) <<48 ); +int_to_scsilun (lun, &tsk_mgmt->lun); tsk_mgmt->tsk_mgmt_func =SRP_TSK_LUN_RESET ; evt->sync_srp = &srp_rsp;
include/scsi/srp.h +4 -3
@@ -42,6 +42,7 @@*/ #include <linux/types.h> +#include <scsi/scsi.h> enum {SRP_LOGIN_REQ =0x00 ,
@@ -179,7 +180,7 @@ struct srp_tsk_mgmt {u8 reserved1[6 ];u64 tag;u8 reserved2[4 ]; - __be64 lun __attribute__((packed)); +struct scsi_lun lun;u8 reserved3[2 ];u8 tsk_mgmt_func;u8 reserved4;
@@ -200,7 +201,7 @@ struct srp_cmd {u8 data_in_desc_cnt;u64 tag;u8 reserved2[4 ]; - __be64 lun __attribute__((packed)); +struct scsi_lun lun;u8 reserved3;u8 task_attr;u8 reserved4;
@@ -265,7 +266,7 @@ struct srp_aer_req {__be32 req_lim_delta;u64 tag;u32 reserved2; -__be64 lun; +struct scsi_lun lun;__be32 sense_data_len;u32 reserved3;u8 sense_data[0 ];
Signature · 1 line
2.1.4
A message that is not in the archive (sent off-list or not yet received): [email protected]
Hannes Reinecke
Reviewed-byQuoted 7 lines · Bart Van Assche
The largest LUN number that has been tested is
0xd2003fff00000000.Checked the following structure sizes with gdb:
*sizeof(struct srp_cmd)= 48
*sizeof(struct srp_tsk_mgmt)= 48
*sizeof(struct srp_aer_req)= 36
Quoted 8 lines
The ibmvscsi changes have been compile tested only (on a PPC system).
Signed-off-by Bart Van Assche <[email protected]>Cc Sagi Grimberg <sagig-VPRAkNaXOzVWk0Htik3J/[email protected]>Cc Sebastian Parschauer <[email protected]>Cc Brian King <[email protected]>Cc Nathan Fontenot <[email protected]>Cc Tyrel Datwyler <[email protected]>
Looks good.
Cheers,
Hannes
Signature · 8 lines
Dr. Hannes Reinecke zSeries & Storage [email protected] +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi,
Quoted 7 lines · Bart Van Assche
The largest LUN number that has been tested is
0xd2003fff00000000.Checked the following structure sizes with gdb:
*sizeof(struct srp_cmd)= 48
*sizeof(struct srp_tsk_mgmt)= 48
*sizeof(struct srp_aer_req)= 36
You can use 'pahole' tool to retrieve the size (and layout) of any data structure from a .o object file.
Quoted 2 lines
The ibmvscsi changes have been compile tested only (on a PPC system).
The changelog lack of any information about the purpose of 64bit LUNs. Please detail a bit why and how.
Quoted 114 lines
Signed-off-by Bart Van Assche <[email protected]>Cc Sagi Grimberg <[email protected]>Cc Sebastian Parschauer <[email protected]>Cc Brian King <[email protected]>Cc Nathan Fontenot <[email protected]>Cc Tyrel Datwyler <[email protected]>--- drivers/infiniband/ulp/srp/ib_srp.c | 8 ++++---- drivers/scsi/ibmvscsi/ibmvscsi.c | 6 +++--- include/scsi/srp.h | 7 ++++--- 3 files changed, 11 insertions(+), 10 deletions(-)drivers/infiniband/ulp/srp/ib_srp.c +4
-4@@ -1841,7 +1841,7 @@ static void srp_process_aer_req(struct srp_rdma_ch *ch,s32 delta =be32_to_cpu (req->req_lim_delta);shost_printk (KERN_ERR , target->scsi_host,PFX -"ignoring AER for LUN %llu\n" ,be64_to_cpu (req->lun)); +"ignoring AER for LUN %llu\n" ,scsilun_to_int (&req->lun));if (srp_response_common (ch, delta, &rsp,sizeof (rsp))) shost_printk(KERN_ERR, target->scsi_host, PFX@@ -2033,7 +2033,7 @@ static int srp_queuecommand(struct Scsi_Host *shost, struct scsi_cmnd *scmnd)memset (cmd,0 ,sizeof *cmd); cmd->opcode =SRP_CMD ; - cmd->lun =cpu_to_be64 ((u64 ) scmnd->device->lun <<48 ); +int_to_scsilun (scmnd->device->lun, &cmd->lun); cmd->tag = tag;memcpy (cmd->cdb, scmnd->cmnd, scmnd->cmd_len);@@ -2448,7 +2448,7 @@ static int srp_send_tsk_mgmt(struct srp_rdma_ch *ch, u64 req_tag,memset (tsk_mgmt,0 ,sizeof *tsk_mgmt); tsk_mgmt->opcode =SRP_TSK_MGMT ; - tsk_mgmt->lun =cpu_to_be64 ((u64 ) lun <<48 ); +int_to_scsilun (lun, &tsk_mgmt->lun); tsk_mgmt->tag = req_tag |SRP_TAG_TSK_MGMT ; tsk_mgmt->tsk_mgmt_func = func; tsk_mgmt->task_tag = req_tag;@@ -3145,7 +3145,7 @@ static ssize_t srp_create_target(struct device *dev, target_host->transportt = ib_srp_transport_template; target_host->max_channel =0 ; target_host->max_id =1 ; - target_host->max_lun =SRP_MAX_LUN ; + target_host->max_lun =-1LL ; target_host->max_cmd_len =sizeof ((struct srp_cmd *) (void *)0L )->cdb; target =host_to_target (target_host);drivers/scsi/ibmvscsi/ibmvscsi.c +3
-3@@ -1053,7 +1053,7 @@ static int ibmvscsi_queuecommand_lck(struct scsi_cmnd *cmnd,memset (srp_cmd,0x00 ,SRP_MAX_IU_LEN ); srp_cmd->opcode =SRP_CMD ;memcpy (srp_cmd->cdb, cmnd->cmnd,sizeof (srp_cmd->cdb)); - srp_cmd->lun =cpu_to_be64 (((u64 )lun) <<48 ); +int_to_scsilun (lun, &srp_cmd->lun);if (!map_data_for_srp_cmd (cmnd, evt_struct, srp_cmd, hostdata->dev)) {if (!firmware_has_feature (FW_FEATURE_CMO ))@@ -1529,7 +1529,7 @@ static int ibmvscsi_eh_abort_handler(struct scsi_cmnd *cmd)/* Set up an abort SRP command */ memset (tsk_mgmt,0x00 ,sizeof (*tsk_mgmt)); tsk_mgmt->opcode =SRP_TSK_MGMT ; - tsk_mgmt->lun =cpu_to_be64 (((u64 ) lun) <<48 ); +int_to_scsilun (lun, &tsk_mgmt->lun); tsk_mgmt->tsk_mgmt_func =SRP_TSK_ABORT_TASK ; tsk_mgmt->task_tag = (u64 ) found_evt;@@ -1652,7 +1652,7 @@ static int ibmvscsi_eh_device_reset_handler(struct scsi_cmnd *cmd)/* Set up a lun reset SRP command */ memset (tsk_mgmt,0x00 ,sizeof (*tsk_mgmt)); tsk_mgmt->opcode =SRP_TSK_MGMT ; - tsk_mgmt->lun =cpu_to_be64 (((u64 ) lun) <<48 ); +int_to_scsilun (lun, &tsk_mgmt->lun); tsk_mgmt->tsk_mgmt_func =SRP_TSK_LUN_RESET ; evt->sync_srp = &srp_rsp;include/scsi/srp.h +3
-2@@ -42,6 +42,7 @@*/ #include <linux/types.h> +#include <scsi/scsi.h> enum {SRP_LOGIN_REQ =0x00 ,@@ -179,7 +180,7 @@ struct srp_tsk_mgmt {u8 reserved1[6 ];u64 tag;u8 reserved2[4 ]; - __be64 lun __attribute__((packed)); +struct scsi_lun lun;u8 reserved3[2 ];u8 tsk_mgmt_func;u8 reserved4;@@ -200,7 +201,7 @@ struct srp_cmd {u8 data_in_desc_cnt;u64 tag;u8 reserved2[4 ]; - __be64 lun __attribute__((packed)); +struct scsi_lun lun;u8 reserved3;u8 task_attr;u8 reserved4;
include/scsi/srp.h struct srp_aer_req { · line 272
Quoted 8 lines
include/scsi/srp.h +1
-1@@ -265,7 +266,7 @@ struct srp_aer_req {__be32 req_lim_delta;u64 tag;u32 reserved2; -__be64 lun; +struct scsi_lun lun;__be32 sense_data_len;u32 reserved3;u8 sense_data[0 ];
Regards.
Signature · 8 lines
Yann Droneaud OPTEYA -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Hello Yann,
Quoted 10 lines · Yann Droneaud
Quoted 6 lines · Bart Van Assche
The largest LUN number that has been tested is
0xd2003fff00000000.Checked the following structure sizes with gdb:
*sizeof(struct srp_cmd)= 48
*sizeof(struct srp_tsk_mgmt)= 48
*sizeof(struct srp_aer_req)= 36You can use 'pahole' tool to retrieve the size (and layout) of any data structure from a .o object file.
Thanks, I will have a look at that tool.
Quoted 4 lines
Quoted 1 line
The ibmvscsi changes have been compile tested only (on a PPC system).
The changelog lack of any information about the purpose of 64bit LUNs. Please detail a bit why and how.
You might have missed Hannes' patch series through which 64-bit LUN support was added in the SCSI core and in most SCSI LLD drivers. The description of one of the patches in that series reads as follows:
"The SCSI standard defines 64-bit values for LUNs, and large arrays
employing large or hierarchical LUN numbers become more and more common.
So update the linux SCSI stack to use 64-bit LUN numbers."
Is it OK for you if I resend this patch with that text added in the patch description ?
Bart.
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
A message that is not in the archive (sent off-list or not yet received): [email protected]
Hi Bart,
Quoted 14 lines · Bart Van Assche
Quoted 10 lines · Yann Droneaud
Quoted 6 lines · Bart Van Assche
The largest LUN number that has been tested is
0xd2003fff00000000.Checked the following structure sizes with gdb:
*sizeof(struct srp_cmd)= 48
*sizeof(struct srp_tsk_mgmt)= 48
*sizeof(struct srp_aer_req)= 36You can use 'pahole' tool to retrieve the size (and layout) of any data structure from a .o object file.
Thanks, I will have a look at that tool.
Quoted 7 lines
Quoted 4 lines
Quoted 1 line
The ibmvscsi changes have been compile tested only (on a PPC system).
The changelog lack of any information about the purpose of 64bit LUNs. Please detail a bit why and how.
You might have missed Hannes' patch series through which 64-bit LUN support was added in the SCSI core and in most SCSI LLD drivers.
Yes I've missed this thread, and, as this commit doesn't have a clear reference to it, I feel I might not be alone wondering about it.
Quoted 12 lines
The
description of one of the patches in that series reads as follows:"The SCSI standard defines 64-bit values for LUNs, and large arrays
employing large or hierarchical LUN numbers become more and more common.So update the linux SCSI stack to use 64-bit LUN numbers."
Is it OK for you if I resend this patch with that text added in the patch description ?
That's would be perfect: it makes a lot more sense with these information added. Additionally, you could add a link to the patch series.
Thanks a lot.
Regards.
Signature · 8 lines
Yann Droneaud OPTEYA -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html