Chelsio iSCSI target offload driver
Subsystems (4)
v3 cover Chelsio iSCSI target offload driver
This is v3 patch series for Chelsio iSCSI target offload driver(cxgbit.ko).
cxgbit.ko registers with iSCSI target transport and offloads multiple CPU intensive tasks to Chelsio T5 adapters.
T5 adapters has following offload features for
iSCSI
-TCP/IP offload
-iSCSI PDU recovery by reassembling TCP segments.
-Header and Data Digest offload.
-iSCSI segmentation offload(ISO).
-Direct Data Placement(DDP).
-v3
- updated commit messages (Sagi).
- dropped alloc/free pdu patch (Sagi).
- added single callback to transmit iscsi pdus (Sagi).
- replaced conn->network_transport by conn_transport->transport_type in text rsp patch(8/13).
-v2
- added hw offload transport type (Nicholas).
- added PDU alloc, free, xmit callbacks (Nicholas).
- created single patch for all cxgbit.ko files (Nicholas).
- merged definition and usage of int (*iscsit_validate_params)() in a single patch (Christoph).
- merged definition and usage of void (*iscsit_release_cmd)() in a single patch (Christoph).
- renamed void (*iscsit_rx_pdu)() to void (*iscsit_get_rx_pdu)() (Sagi).
- added dependency on INET in Kconfig (Arnd).
- added check for NULL sg in cxgbit_set_one_ppod() (Dan Carpenter).
Please review.
Thanks
Varun Prakash (13):
iscsi-target: add int (*iscsit_xmit_pdu)()
iscsi-target: add void (*iscsit_release_cmd)()
iscsi-target: add void (*iscsit_get_rx_pdu)()
iscsi-target: split iscsi_target_rx_thread()
iscsi-target: add int (*iscsit_validate_params)()
iscsi-target: add void (*iscsit_get_r2t_ttt)()
iscsi-target: move iscsit_thread_check_cpumask()
iscsi-target: use conn_transport->transport_type in text rsp
iscsi-target: add new offload transport type
iscsi-target: clear tx_thread_active
iscsi-target: call complete on conn_logout_comp
iscsi-target: export symbols
cxgbit: add files for cxgbit.ko
drivers/infiniband/ulp/isert/ib_isert.c | 10 + drivers/target/iscsi/Kconfig | 2 + drivers/target/iscsi/Makefile | 1 + drivers/target/iscsi/cxgbit/Kconfig | 7 + drivers/target/iscsi/cxgbit/Makefile | 6 + drivers/target/iscsi/cxgbit/cxgbit.h | 353 ++++ drivers/target/iscsi/cxgbit/cxgbit_cm.c | 2086 +++++++++++++++++++++ drivers/target/iscsi/cxgbit/cxgbit_ddp.c | 325 ++++ drivers/target/iscsi/cxgbit/cxgbit_lro.h | 72 + drivers/target/iscsi/cxgbit/cxgbit_main.c | 701 +++++++ drivers/target/iscsi/cxgbit/cxgbit_target.c | 1561 +++++++++++++++ drivers/target/iscsi/iscsi_target.c | 684 +++---- drivers/target/iscsi/iscsi_target_configfs.c | 76 + drivers/target/iscsi/iscsi_target_datain_values.c | 1 + drivers/target/iscsi/iscsi_target_login.c | 13 +- drivers/target/iscsi/iscsi_target_nego.c | 1 + drivers/target/iscsi/iscsi_target_parameters.c | 1 + drivers/target/iscsi/iscsi_target_util.c | 5 + include/target/iscsi/iscsi_target_core.h | 27 + include/target/iscsi/iscsi_transport.h | 40 + 20 files changed, 5546 insertions(+), 426 deletions(-) create mode 100644 drivers/target/iscsi/cxgbit/Kconfig create mode 100644 drivers/target/iscsi/cxgbit/Makefile create mode 100644 drivers/target/iscsi/cxgbit/cxgbit.h create mode 100644 drivers/target/iscsi/cxgbit/cxgbit_cm.c create mode 100644 drivers/target/iscsi/cxgbit/cxgbit_ddp.c create mode 100644 drivers/target/iscsi/cxgbit/cxgbit_lro.h create mode 100644 drivers/target/iscsi/cxgbit/cxgbit_main.c create mode 100644 drivers/target/iscsi/cxgbit/cxgbit_target.c
Signature · 1 line
2.0.2
PATCH v3 1/13 iscsi-target: add int (*iscsit_xmit_pdu)()
Add int (*iscsit_xmit_pdu)() to
struct iscsit_transport, iscsi-target
uses this callback to transmit an
iSCSI PDU.
cxgbit.ko needs this callback to
avoid duplicating iscsit_immediate_queue()
and iscsit_response_queue() code.
--- drivers/target/iscsi/iscsi_target.c | 546 ++++++++++++--------------------- include/target/iscsi/iscsi_transport.h | 2 + 2 files changed, 197 insertions(+), 351 deletions(-)
drivers/target/iscsi/iscsi_target.c +195 -351
@@ -499,6 +499,168 @@ static void iscsit_aborted_task(struct iscsi_conn *conn, struct iscsi_cmd *cmd)__iscsit_free_cmd (cmd, scsi_cmd, true); } +static void iscsit_do_crypto_hash_buf (struct ahash_request *,const void *, +u32 ,u32 ,u8 *,u8 *); +static void iscsit_tx_thread_wait_for_tcp (struct iscsi_conn *); + +static int +iscsit_xmit_nondatain_pdu (struct iscsi_conn *conn,struct iscsi_cmd *cmd, +const void *data_buf,u32 data_buf_len) +{ +struct iscsi_hdr *hdr = (struct iscsi_hdr *)cmd->pdu; +struct kvec *iov; +u32 niov =0 , tx_size =ISCSI_HDR_LEN ; +int ret; + + iov = &cmd->iov_misc[0 ]; + iov[niov].iov_base = cmd->pdu; + iov[niov++].iov_len =ISCSI_HDR_LEN ; + +if (conn->conn_ops->HeaderDigest) { +u32 *header_digest = (u32 *)&cmd->pdu[ISCSI_HDR_LEN ]; + +iscsit_do_crypto_hash_buf (conn->conn_tx_hash, hdr, +ISCSI_HDR_LEN ,0 ,NULL , + (u8 *)header_digest); + + iov[0 ].iov_len +=ISCSI_CRC_LEN ; + tx_size +=ISCSI_CRC_LEN ; +pr_debug ("Attaching CRC32C HeaderDigest" +" to opcode 0x%x 0x%08x\n" , + hdr->opcode, *header_digest); + } + +if (data_buf_len) { +u32 padding = ((-data_buf_len) &3 ); + + iov[niov].iov_base = (void *)data_buf; + iov[niov++].iov_len = data_buf_len; + tx_size += data_buf_len; + +if (padding !=0 ) { + iov[niov].iov_base = &cmd->pad_bytes; + iov[niov++].iov_len = padding; + tx_size += padding; +pr_debug ("Attaching %u additional" +" padding bytes.\n" , padding); + } + +if (conn->conn_ops->DataDigest) { +iscsit_do_crypto_hash_buf (conn->conn_tx_hash, + data_buf, data_buf_len, + padding, + (u8 *)&cmd->pad_bytes, + (u8 *)&cmd->data_crc); + + iov[niov].iov_base = &cmd->data_crc; + iov[niov++].iov_len =ISCSI_CRC_LEN ; + tx_size +=ISCSI_CRC_LEN ; +pr_debug ("Attached DataDigest for %u" +" bytes opcode 0x%x, CRC 0x%08x\n" , + data_buf_len, hdr->opcode, cmd->data_crc); + } + } + + cmd->iov_misc_count = niov; + cmd->tx_size = tx_size; + + ret =iscsit_send_tx_data (cmd, conn,1 ); +if (ret <0 ) { +iscsit_tx_thread_wait_for_tcp (conn); +return ret; + } + +return 0 ; +} + +static int iscsit_map_iovec (struct iscsi_cmd *,struct kvec *,u32 ,u32 ); +static void iscsit_unmap_iovec (struct iscsi_cmd *); +static u32 iscsit_do_crypto_hash_sg (struct ahash_request *,struct iscsi_cmd *, +u32 ,u32 ,u32 ,u8 *); +static int +iscsit_xmit_datain_pdu (struct iscsi_conn *conn,struct iscsi_cmd *cmd, +const struct iscsi_datain *datain) +{ +struct kvec *iov; +u32 iov_count =0 , tx_size =0 ; +int ret, iov_ret; + + iov = &cmd->iov_data[0 ]; + iov[iov_count].iov_base = cmd->pdu; + iov[iov_count++].iov_len =ISCSI_HDR_LEN ; + tx_size +=ISCSI_HDR_LEN ; + +if (conn->conn_ops->HeaderDigest) { +u32 *header_digest = (u32 *)&cmd->pdu[ISCSI_HDR_LEN ]; + +iscsit_do_crypto_hash_buf (conn->conn_tx_hash, cmd->pdu, +ISCSI_HDR_LEN ,0 ,NULL , + (u8 *)header_digest); + + iov[0 ].iov_len +=ISCSI_CRC_LEN ; + tx_size +=ISCSI_CRC_LEN ; + +pr_debug ("Attaching CRC32 HeaderDigest for DataIN PDU 0x%08x\n" , + *header_digest); + } + + iov_ret =iscsit_map_iovec (cmd, &cmd->iov_data[1 ], + datain->offset, datain->length); +if (iov_ret <0 ) +return -1 ; + + iov_count += iov_ret; + tx_size += datain->length; + + cmd->padding = ((-datain->length) &3 ); +if (cmd->padding) { + iov[iov_count].iov_base = cmd->pad_bytes; + iov[iov_count++].iov_len = cmd->padding; + tx_size += cmd->padding; + +pr_debug ("Attaching %u padding bytes\n" , cmd->padding); + } + +if (conn->conn_ops->DataDigest) { + cmd->data_crc =iscsit_do_crypto_hash_sg (conn->conn_tx_hash, + cmd, datain->offset, + datain->length, + cmd->padding, + cmd->pad_bytes); + + iov[iov_count].iov_base = &cmd->data_crc; + iov[iov_count++].iov_len =ISCSI_CRC_LEN ; + tx_size +=ISCSI_CRC_LEN ; + +pr_debug ("Attached CRC32C DataDigest %d bytes, crc 0x%08x\n" , + datain->length + cmd->padding, cmd->data_crc); + } + + cmd->iov_data_count = iov_count; + cmd->tx_size = tx_size; + + ret =iscsit_fe_sendpage_sg (cmd, conn); + +iscsit_unmap_iovec (cmd); + +if (ret <0 ) { +iscsit_tx_thread_wait_for_tcp (conn); +return ret; + } + +return 0 ; +} + +static int iscsit_xmit_pdu (struct iscsi_conn *conn,struct iscsi_cmd *cmd, +struct iscsi_datain_req *dr,const void *buf, +u32 buf_len) +{ +if (dr) +return iscsit_xmit_datain_pdu (conn, cmd, buf); +else +return iscsit_xmit_nondatain_pdu (conn, cmd, buf, buf_len); +} +static enum target_prot_op iscsit_get_sup_prot_ops (struct iscsi_conn *conn) {return TARGET_PROT_NORMAL ;
@@ -519,6 +681,7 @@ static struct iscsit_transport iscsi_target_transport = { .iscsit_queue_data_in = iscsit_queue_rsp, .iscsit_queue_status = iscsit_queue_rsp, .iscsit_aborted_task = iscsit_aborted_task, + .iscsit_xmit_pdu = iscsit_xmit_pdu, .iscsit_get_sup_prot_ops = iscsit_get_sup_prot_ops, };
@@ -2534,7 +2697,6 @@ static int iscsit_send_conn_drop_async_message( {struct iscsi_async *hdr; - cmd->tx_size =ISCSI_HDR_LEN ; cmd->iscsi_opcode =ISCSI_OP_ASYNC_EVENT ; hdr = (struct iscsi_async *) cmd->pdu;
@@ -2552,25 +2714,11 @@ static int iscsit_send_conn_drop_async_message( hdr->param2 =cpu_to_be16 (conn->sess->sess_ops->DefaultTime2Wait); hdr->param3 =cpu_to_be16 (conn->sess->sess_ops->DefaultTime2Retain); -if (conn->conn_ops->HeaderDigest) { -u32 *header_digest = (u32 *)&cmd->pdu[ISCSI_HDR_LEN ]; - -iscsit_do_crypto_hash_buf (conn->conn_tx_hash, hdr, -ISCSI_HDR_LEN ,0 ,NULL , (u8 *)header_digest); - - cmd->tx_size +=ISCSI_CRC_LEN ; -pr_debug ("Attaching CRC32C HeaderDigest to" -" Async Message 0x%08x\n" , *header_digest); - } - - cmd->iov_misc[0 ].iov_base = cmd->pdu; - cmd->iov_misc[0 ].iov_len = cmd->tx_size; - cmd->iov_misc_count =1 ; -pr_debug ("Sending Connection Dropped Async Message StatSN:" " 0x%08x, for CID: %hu on CID: %hu\n" , cmd->stat_sn, cmd->logout_cid, conn->cid); -return 0 ; + +return conn->conn_transport->iscsit_xmit_pdu (conn, cmd,NULL ,NULL ,0 ); }static void iscsit_tx_thread_wait_for_tcp (struct iscsi_conn *conn)
@@ -2633,9 +2781,7 @@ static int iscsit_send_datain(struct iscsi_cmd *cmd, struct iscsi_conn *conn)struct iscsi_data_rsp *hdr = (struct iscsi_data_rsp *)&cmd->pdu[0 ];struct iscsi_datain datain;struct iscsi_datain_req *dr; -struct kvec *iov; -u32 iov_count =0 , tx_size =0 ; -int eodr =0 , ret, iov_ret; +int eodr =0 , ret;bool set_statsn = false;memset (&datain,0 ,sizeof (struct iscsi_datain ));
@@ -2677,64 +2823,9 @@ static int iscsit_send_datain(struct iscsi_cmd *cmd, struct iscsi_conn *conn)iscsit_build_datain_pdu (cmd, conn, &datain, hdr, set_statsn); - iov = &cmd->iov_data[0 ]; - iov[iov_count].iov_base = cmd->pdu; - iov[iov_count++].iov_len =ISCSI_HDR_LEN ; - tx_size +=ISCSI_HDR_LEN ; - -if (conn->conn_ops->HeaderDigest) { -u32 *header_digest = (u32 *)&cmd->pdu[ISCSI_HDR_LEN ]; - -iscsit_do_crypto_hash_buf (conn->conn_tx_hash, cmd->pdu, -ISCSI_HDR_LEN ,0 ,NULL , (u8 *)header_digest); - - iov[0 ].iov_len +=ISCSI_CRC_LEN ; - tx_size +=ISCSI_CRC_LEN ; - -pr_debug ("Attaching CRC32 HeaderDigest" -" for DataIN PDU 0x%08x\n" , *header_digest); - } - - iov_ret =iscsit_map_iovec (cmd, &cmd->iov_data[1 ], - datain.offset, datain.length); -if (iov_ret <0 ) -return -1 ; - - iov_count += iov_ret; - tx_size += datain.length; - - cmd->padding = ((-datain.length) &3 ); -if (cmd->padding) { - iov[iov_count].iov_base = cmd->pad_bytes; - iov[iov_count++].iov_len = cmd->padding; - tx_size += cmd->padding; - -pr_debug ("Attaching %u padding bytes\n" , - cmd->padding); - } -if (conn->conn_ops->DataDigest) { - cmd->data_crc =iscsit_do_crypto_hash_sg (conn->conn_tx_hash, cmd, - datain.offset, datain.length, cmd->padding, cmd->pad_bytes); - - iov[iov_count].iov_base = &cmd->data_crc; - iov[iov_count++].iov_len =ISCSI_CRC_LEN ; - tx_size +=ISCSI_CRC_LEN ; - -pr_debug ("Attached CRC32C DataDigest %d bytes, crc" -" 0x%08x\n" , datain.length+cmd->padding, cmd->data_crc); - } - - cmd->iov_data_count = iov_count; - cmd->tx_size = tx_size; - - ret =iscsit_fe_sendpage_sg (cmd, conn); - -iscsit_unmap_iovec (cmd); - -if (ret <0 ) { -iscsit_tx_thread_wait_for_tcp (conn); + ret = conn->conn_transport->iscsit_xmit_pdu (conn, cmd, dr, &datain,0 ); +if (ret <0 )return ret; - }if (dr->dr_complete) { eodr = (cmd->se_cmd.se_cmd_flags & SCF_TRANSPORT_TASK_SENSE) ?
@@ -2843,34 +2934,14 @@ EXPORT_SYMBOL(iscsit_build_logout_rsp);static int iscsit_send_logout (struct iscsi_cmd *cmd,struct iscsi_conn *conn) { -struct kvec *iov; -int niov =0 , tx_size, rc; +int rc; rc =iscsit_build_logout_rsp (cmd, conn, (struct iscsi_logout_rsp *)&cmd->pdu[0 ]);if (rc <0 )return rc; - tx_size =ISCSI_HDR_LEN ; - iov = &cmd->iov_misc[0 ]; - iov[niov].iov_base = cmd->pdu; - iov[niov++].iov_len =ISCSI_HDR_LEN ; - -if (conn->conn_ops->HeaderDigest) { -u32 *header_digest = (u32 *)&cmd->pdu[ISCSI_HDR_LEN ]; - -iscsit_do_crypto_hash_buf (conn->conn_tx_hash, &cmd->pdu[0 ], -ISCSI_HDR_LEN ,0 ,NULL , (u8 *)header_digest); - - iov[0 ].iov_len +=ISCSI_CRC_LEN ; - tx_size +=ISCSI_CRC_LEN ; -pr_debug ("Attaching CRC32C HeaderDigest to" -" Logout Response 0x%08x\n" , *header_digest); - } - cmd->iov_misc_count = niov; - cmd->tx_size = tx_size; - -return 0 ; +return conn->conn_transport->iscsit_xmit_pdu (conn, cmd,NULL ,NULL ,0 ); }void
@@ -2910,34 +2981,16 @@ static int iscsit_send_unsolicited_nopin( int want_response) {struct iscsi_nopin *hdr = (struct iscsi_nopin *)&cmd->pdu[0 ]; -int tx_size =ISCSI_HDR_LEN , ret; +int ret;iscsit_build_nopin_rsp (cmd, conn, hdr, false); -if (conn->conn_ops->HeaderDigest) { -u32 *header_digest = (u32 *)&cmd->pdu[ISCSI_HDR_LEN ]; - -iscsit_do_crypto_hash_buf (conn->conn_tx_hash, hdr, -ISCSI_HDR_LEN ,0 ,NULL , (u8 *)header_digest); - - tx_size +=ISCSI_CRC_LEN ; -pr_debug ("Attaching CRC32C HeaderDigest to" -" NopIN 0x%08x\n" , *header_digest); - } - - cmd->iov_misc[0 ].iov_base = cmd->pdu; - cmd->iov_misc[0 ].iov_len = tx_size; - cmd->iov_misc_count =1 ; - cmd->tx_size = tx_size; -pr_debug ("Sending Unsolicited NOPIN TTT: 0x%08x StatSN:" " 0x%08x CID: %hu\n" , hdr->ttt, cmd->stat_sn, conn->cid); - ret =iscsit_send_tx_data (cmd, conn,1 ); -if (ret <0 ) { -iscsit_tx_thread_wait_for_tcp (conn); + ret = conn->conn_transport->iscsit_xmit_pdu (conn, cmd,NULL ,NULL ,0 ); +if (ret <0 )return ret; - }spin_lock_bh (&cmd->istate_lock); cmd->i_state = want_response ?
@@ -2951,75 +3004,24 @@ static int iscsit_send_nopin(struct iscsi_cmd *cmd, struct iscsi_conn *conn) { struct iscsi_nopin *hdr = (struct iscsi_nopin *)&cmd->pdu[0]; -struct kvec *iov; -u32 padding =0 ; -int niov =0 , tx_size;iscsit_build_nopin_rsp (cmd, conn, hdr, true); - tx_size =ISCSI_HDR_LEN ; - iov = &cmd->iov_misc[0 ]; - iov[niov].iov_base = cmd->pdu; - iov[niov++].iov_len =ISCSI_HDR_LEN ; - -if (conn->conn_ops->HeaderDigest) { -u32 *header_digest = (u32 *)&cmd->pdu[ISCSI_HDR_LEN ]; - -iscsit_do_crypto_hash_buf (conn->conn_tx_hash, hdr, -ISCSI_HDR_LEN ,0 ,NULL , (u8 *)header_digest); - - iov[0 ].iov_len +=ISCSI_CRC_LEN ; - tx_size +=ISCSI_CRC_LEN ; -pr_debug ("Attaching CRC32C HeaderDigest" -" to NopIn 0x%08x\n" , *header_digest); - } -/* * NOPOUT Ping Data is attached to struct iscsi_cmd->buf_ptr. * NOPOUT DataSegmentLength is at struct iscsi_cmd->buf_ptr_size. */ -if (cmd->buf_ptr_size) { - iov[niov].iov_base = cmd->buf_ptr; - iov[niov++].iov_len = cmd->buf_ptr_size; - tx_size += cmd->buf_ptr_size; - -pr_debug ("Echoing back %u bytes of ping" -" data.\n" , cmd->buf_ptr_size); +pr_debug ("Echoing back %u bytes of ping data.\n" , cmd->buf_ptr_size); - padding = ((-cmd->buf_ptr_size) &3 ); -if (padding !=0 ) { - iov[niov].iov_base = &cmd->pad_bytes; - iov[niov++].iov_len = padding; - tx_size += padding; -pr_debug ("Attaching %u additional" -" padding bytes.\n" , padding); - } -if (conn->conn_ops->DataDigest) { -iscsit_do_crypto_hash_buf (conn->conn_tx_hash, - cmd->buf_ptr, cmd->buf_ptr_size, - padding, (u8 *)&cmd->pad_bytes, - (u8 *)&cmd->data_crc); - - iov[niov].iov_base = &cmd->data_crc; - iov[niov++].iov_len =ISCSI_CRC_LEN ; - tx_size +=ISCSI_CRC_LEN ; -pr_debug ("Attached DataDigest for %u" -" bytes of ping data, CRC 0x%08x\n" , - cmd->buf_ptr_size, cmd->data_crc); - } - } - - cmd->iov_misc_count = niov; - cmd->tx_size = tx_size; - -return 0 ; +return conn->conn_transport->iscsit_xmit_pdu (conn, cmd,NULL , + cmd->buf_ptr, + cmd->buf_ptr_size); }static int iscsit_send_r2t (struct iscsi_cmd *cmd,struct iscsi_conn *conn) { -int tx_size =0 ;struct iscsi_r2t *r2t;struct iscsi_r2t_rsp *hdr;int ret;
@@ -3044,38 +3046,18 @@ static int iscsit_send_r2t( hdr->data_offset =cpu_to_be32 (r2t->offset); hdr->data_length =cpu_to_be32 (r2t->xfer_len); - cmd->iov_misc[0 ].iov_base = cmd->pdu; - cmd->iov_misc[0 ].iov_len =ISCSI_HDR_LEN ; - tx_size +=ISCSI_HDR_LEN ; - -if (conn->conn_ops->HeaderDigest) { -u32 *header_digest = (u32 *)&cmd->pdu[ISCSI_HDR_LEN ]; - -iscsit_do_crypto_hash_buf (conn->conn_tx_hash, hdr, -ISCSI_HDR_LEN ,0 ,NULL , (u8 *)header_digest); - - cmd->iov_misc[0 ].iov_len +=ISCSI_CRC_LEN ; - tx_size +=ISCSI_CRC_LEN ; -pr_debug ("Attaching CRC32 HeaderDigest for R2T" -" PDU 0x%08x\n" , *header_digest); - } -pr_debug ("Built %sR2T, ITT: 0x%08x, TTT: 0x%08x, StatSN:" " 0x%08x, R2TSN: 0x%08x, Offset: %u, DDTL: %u, CID: %hu\n" , (!r2t->recovery_r2t) ?"" :"Recovery " , cmd->init_task_tag, r2t->targ_xfer_tag,ntohl (hdr->statsn), r2t->r2t_sn, r2t->offset, r2t->xfer_len, conn->cid); - cmd->iov_misc_count =1 ; - cmd->tx_size = tx_size; -spin_lock_bh (&cmd->r2t_lock); r2t->sent_r2t =1 ;spin_unlock_bh (&cmd->r2t_lock); - ret =iscsit_send_tx_data (cmd, conn,1 ); + ret = conn->conn_transport->iscsit_xmit_pdu (conn, cmd,NULL ,NULL ,0 );if (ret <0 ) { -iscsit_tx_thread_wait_for_tcp (conn);return ret; }
@@ -3204,18 +3186,12 @@ EXPORT_SYMBOL(iscsit_build_rsp_pdu);static int iscsit_send_response (struct iscsi_cmd *cmd,struct iscsi_conn *conn) {struct iscsi_scsi_rsp *hdr = (struct iscsi_scsi_rsp *)&cmd->pdu[0 ]; -struct kvec *iov; -u32 padding =0 , tx_size =0 ; -int iov_count =0 ;bool inc_stat_sn = (cmd->i_state ==ISTATE_SEND_STATUS ); +void *data_buf =NULL ; +u32 padding =0 , data_buf_len =0 ;iscsit_build_rsp_pdu (cmd, conn, inc_stat_sn, hdr); - iov = &cmd->iov_misc[0 ]; - iov[iov_count].iov_base = cmd->pdu; - iov[iov_count++].iov_len =ISCSI_HDR_LEN ; - tx_size +=ISCSI_HDR_LEN ; -/* * Attach SENSE DATA payload to iSCSI Response PDU */
@@ -3227,56 +3203,23 @@ static int iscsit_send_response(struct iscsi_cmd *cmd, struct iscsi_conn *conn) padding = -(cmd->se_cmd.scsi_sense_length) &3 ;hton24 (hdr->dlength, (u32 )cmd->se_cmd.scsi_sense_length); - iov[iov_count].iov_base = cmd->sense_buffer; - iov[iov_count++].iov_len = - (cmd->se_cmd.scsi_sense_length + padding); - tx_size += cmd->se_cmd.scsi_sense_length; + data_buf = cmd->sense_buffer; + data_buf_len = cmd->se_cmd.scsi_sense_length + padding;if (padding) {memset (cmd->sense_buffer + cmd->se_cmd.scsi_sense_length,0 , padding); - tx_size += padding;pr_debug ("Adding %u bytes of padding to" " SENSE.\n" , padding); } -if (conn->conn_ops->DataDigest) { -iscsit_do_crypto_hash_buf (conn->conn_tx_hash, - cmd->sense_buffer, - (cmd->se_cmd.scsi_sense_length + padding), -0 ,NULL , (u8 *)&cmd->data_crc); - - iov[iov_count].iov_base = &cmd->data_crc; - iov[iov_count++].iov_len =ISCSI_CRC_LEN ; - tx_size +=ISCSI_CRC_LEN ; - -pr_debug ("Attaching CRC32 DataDigest for" -" SENSE, %u bytes CRC 0x%08x\n" , - (cmd->se_cmd.scsi_sense_length + padding), - cmd->data_crc); - } -pr_debug ("Attaching SENSE DATA: %u bytes to iSCSI" " Response PDU\n" , cmd->se_cmd.scsi_sense_length); } -if (conn->conn_ops->HeaderDigest) { -u32 *header_digest = (u32 *)&cmd->pdu[ISCSI_HDR_LEN ]; - -iscsit_do_crypto_hash_buf (conn->conn_tx_hash, cmd->pdu, -ISCSI_HDR_LEN ,0 ,NULL , (u8 *)header_digest); - - iov[0 ].iov_len +=ISCSI_CRC_LEN ; - tx_size +=ISCSI_CRC_LEN ; -pr_debug ("Attaching CRC32 HeaderDigest for Response" -" PDU 0x%08x\n" , *header_digest); - } - - cmd->iov_misc_count = iov_count; - cmd->tx_size = tx_size; - -return 0 ; +return conn->conn_transport->iscsit_xmit_pdu (conn, cmd,NULL , data_buf, + data_buf_len); }static u8 iscsit_convert_tcm_tmr_rsp (struct se_tmr_req *se_tmr)
@@ -3323,30 +3266,10 @@ static int iscsit_send_task_mgt_rsp(struct iscsi_cmd *cmd, struct iscsi_conn *conn) { struct iscsi_tm_rsp *hdr = (struct iscsi_tm_rsp *)&cmd->pdu[0]; -u32 tx_size =0 ;iscsit_build_task_mgt_rsp (cmd, conn, hdr); - cmd->iov_misc[0 ].iov_base = cmd->pdu; - cmd->iov_misc[0 ].iov_len =ISCSI_HDR_LEN ; - tx_size +=ISCSI_HDR_LEN ; - -if (conn->conn_ops->HeaderDigest) { -u32 *header_digest = (u32 *)&cmd->pdu[ISCSI_HDR_LEN ]; - -iscsit_do_crypto_hash_buf (conn->conn_tx_hash, hdr, -ISCSI_HDR_LEN ,0 ,NULL , (u8 *)header_digest); - - cmd->iov_misc[0 ].iov_len +=ISCSI_CRC_LEN ; - tx_size +=ISCSI_CRC_LEN ; -pr_debug ("Attaching CRC32 HeaderDigest for Task" -" Mgmt Response PDU 0x%08x\n" , *header_digest); - } - - cmd->iov_misc_count =1 ; - cmd->tx_size = tx_size; - -return 0 ; +return conn->conn_transport->iscsit_xmit_pdu (conn, cmd,NULL ,NULL ,0 ); }static bool iscsit_check_inaddr_any (struct iscsi_np *np)
@@ -3583,53 +3506,15 @@ static int iscsit_send_text_rsp( struct iscsi_conn *conn) {struct iscsi_text_rsp *hdr = (struct iscsi_text_rsp *)cmd->pdu; -struct kvec *iov; -u32 tx_size =0 ; -int text_length, iov_count =0 , rc; - - rc =iscsit_build_text_rsp (cmd, conn, hdr,ISCSI_TCP ); -if (rc <0 ) -return rc; - - text_length = rc; - iov = &cmd->iov_misc[0 ]; - iov[iov_count].iov_base = cmd->pdu; - iov[iov_count++].iov_len =ISCSI_HDR_LEN ; - iov[iov_count].iov_base = cmd->buf_ptr; - iov[iov_count++].iov_len = text_length; - - tx_size += (ISCSI_HDR_LEN + text_length); - -if (conn->conn_ops->HeaderDigest) { -u32 *header_digest = (u32 *)&cmd->pdu[ISCSI_HDR_LEN ]; - -iscsit_do_crypto_hash_buf (conn->conn_tx_hash, hdr, -ISCSI_HDR_LEN ,0 ,NULL , (u8 *)header_digest); +int text_length; - iov[0 ].iov_len +=ISCSI_CRC_LEN ; - tx_size +=ISCSI_CRC_LEN ; -pr_debug ("Attaching CRC32 HeaderDigest for" -" Text Response PDU 0x%08x\n" , *header_digest); - } - -if (conn->conn_ops->DataDigest) { -iscsit_do_crypto_hash_buf (conn->conn_tx_hash, - cmd->buf_ptr, text_length, -0 ,NULL , (u8 *)&cmd->data_crc); - - iov[iov_count].iov_base = &cmd->data_crc; - iov[iov_count++].iov_len =ISCSI_CRC_LEN ; - tx_size +=ISCSI_CRC_LEN ; - -pr_debug ("Attaching DataDigest for %u bytes of text" -" data, CRC 0x%08x\n" , text_length, - cmd->data_crc); - } - - cmd->iov_misc_count = iov_count; - cmd->tx_size = tx_size; + text_length =iscsit_build_text_rsp (cmd, conn, hdr,ISCSI_TCP ); +if (text_length <0 ) +return text_length; -return 0 ; +return conn->conn_transport->iscsit_xmit_pdu (conn, cmd,NULL , + cmd->buf_ptr, + text_length); }void
@@ -3654,49 +3539,15 @@ static int iscsit_send_reject( struct iscsi_conn *conn) {struct iscsi_reject *hdr = (struct iscsi_reject *)&cmd->pdu[0 ]; -struct kvec *iov; -u32 iov_count =0 , tx_size;iscsit_build_reject (cmd, conn, hdr); - iov = &cmd->iov_misc[0 ]; - iov[iov_count].iov_base = cmd->pdu; - iov[iov_count++].iov_len =ISCSI_HDR_LEN ; - iov[iov_count].iov_base = cmd->buf_ptr; - iov[iov_count++].iov_len =ISCSI_HDR_LEN ; - - tx_size = (ISCSI_HDR_LEN +ISCSI_HDR_LEN ); - -if (conn->conn_ops->HeaderDigest) { -u32 *header_digest = (u32 *)&cmd->pdu[ISCSI_HDR_LEN ]; - -iscsit_do_crypto_hash_buf (conn->conn_tx_hash, hdr, -ISCSI_HDR_LEN ,0 ,NULL , (u8 *)header_digest); - - iov[0 ].iov_len +=ISCSI_CRC_LEN ; - tx_size +=ISCSI_CRC_LEN ; -pr_debug ("Attaching CRC32 HeaderDigest for" -" REJECT PDU 0x%08x\n" , *header_digest); - } - -if (conn->conn_ops->DataDigest) { -iscsit_do_crypto_hash_buf (conn->conn_tx_hash, cmd->buf_ptr, -ISCSI_HDR_LEN ,0 ,NULL , (u8 *)&cmd->data_crc); - - iov[iov_count].iov_base = &cmd->data_crc; - iov[iov_count++].iov_len =ISCSI_CRC_LEN ; - tx_size +=ISCSI_CRC_LEN ; -pr_debug ("Attaching CRC32 DataDigest for REJECT" -" PDU 0x%08x\n" , cmd->data_crc); - } - - cmd->iov_misc_count = iov_count; - cmd->tx_size = tx_size; -pr_debug ("Built Reject PDU StatSN: 0x%08x, Reason: 0x%02x," " CID: %hu\n" ,ntohl (hdr->statsn), hdr->reason, conn->cid); -return 0 ; +return conn->conn_transport->iscsit_xmit_pdu (conn, cmd,NULL , + cmd->buf_ptr, +ISCSI_HDR_LEN ); }void iscsit_thread_get_cpumask (struct iscsi_conn *conn)
@@ -3889,13 +3740,6 @@ check_rsp_state:if (ret <0 ) goto err; -if (iscsit_send_tx_data (cmd, conn,1 ) <0 ) { -iscsit_tx_thread_wait_for_tcp (conn); -iscsit_unmap_iovec (cmd); - goto err; - } -iscsit_unmap_iovec (cmd); -switch (state) {case ISTATE_SEND_LOGOUTRSP :if (!iscsit_logout_post_handler (cmd, conn))
include/target/iscsi/iscsi_transport.h +2 -0
@@ -22,6 +22,8 @@ struct iscsit_transport {int (*iscsit_queue_data_in)(struct iscsi_conn *,struct iscsi_cmd *);int (*iscsit_queue_status)(struct iscsi_conn *,struct iscsi_cmd *);void (*iscsit_aborted_task)(struct iscsi_conn *,struct iscsi_cmd *); +int (*iscsit_xmit_pdu)(struct iscsi_conn *,struct iscsi_cmd *, +struct iscsi_datain_req *,const void *,u32 );enum target_prot_op (*iscsit_get_sup_prot_ops)(struct iscsi_conn *); };
Signature · 1 line
2.0.2
PATCH v3 2/13 iscsi-target: add void (*iscsit_release_cmd)()
In reply to Varun PrakashAdd void (*iscsit_release_cmd)() to
struct iscsit_transport, iscsi-target
uses this callback to release transport
driver resources associated with an iSCSI cmd.
cxgbit.ko needs this callback to release DDP
resource and sg page in case ofPASSTHROUGH_SG_TO_MEM_NOALLOC.
--- drivers/target/iscsi/iscsi_target_util.c | 3 +++ include/target/iscsi/iscsi_transport.h | 1 + 2 files changed, 4 insertions(+)
drivers/target/iscsi/iscsi_target_util.c +3 -0
@@ -725,6 +725,9 @@ void __iscsit_free_cmd(struct iscsi_cmd *cmd, bool scsi_cmd,iscsit_remove_cmd_from_immediate_queue (cmd, conn);iscsit_remove_cmd_from_response_queue (cmd, conn); } + +if (conn && conn->conn_transport->iscsit_release_cmd) + conn->conn_transport->iscsit_release_cmd (conn, cmd); }void iscsit_free_cmd (struct iscsi_cmd *cmd,bool shutdown)
include/target/iscsi/iscsi_transport.h +1 -0
@@ -24,6 +24,7 @@ struct iscsit_transport {void (*iscsit_aborted_task)(struct iscsi_conn *,struct iscsi_cmd *);int (*iscsit_xmit_pdu)(struct iscsi_conn *,struct iscsi_cmd *,struct iscsi_datain_req *,const void *,u32 ); +void (*iscsit_release_cmd)(struct iscsi_conn *,struct iscsi_cmd *);enum target_prot_op (*iscsit_get_sup_prot_ops)(struct iscsi_conn *); };
Signature · 1 line
2.0.2
PATCH v3 3/13 iscsi-target: add void (*iscsit_get_rx_pdu)()
In reply to Varun PrakashAdd void (*iscsit_get_rx_pdu)() to
struct iscsit_transport, iscsi-target
uses this callback to receive and
process Rx iSCSI PDUs.
cxgbit.ko needs this callback to
reuse iscsi-target Rx thread.
--- drivers/infiniband/ulp/isert/ib_isert.c | 10 ++++++++++ drivers/target/iscsi/iscsi_target.c | 10 ++-------- include/target/iscsi/iscsi_transport.h | 1 + 3 files changed, 13 insertions(+), 8 deletions(-)
drivers/infiniband/ulp/isert/ib_isert.c +10 -0
@@ -3273,6 +3273,15 @@ static void isert_free_conn(struct iscsi_conn *conn)isert_put_conn (isert_conn); } +static void isert_get_rx_pdu (struct iscsi_conn *conn) +{ +struct completion comp; + +init_completion (&comp); + +wait_for_completion_interruptible (&comp); +} +static struct iscsit_transport iser_target_transport = { .name ="IB/iSER" , .transport_type =ISCSI_INFINIBAND ,
@@ -3291,6 +3300,7 @@ static struct iscsit_transport iser_target_transport = { .iscsit_queue_data_in = isert_put_datain, .iscsit_queue_status = isert_put_response, .iscsit_aborted_task = isert_aborted_task, + .iscsit_get_rx_pdu = isert_get_rx_pdu, .iscsit_get_sup_prot_ops = isert_get_sup_prot_ops, };
drivers/target/iscsi/iscsi_target.c +2 -8
@@ -3951,14 +3951,8 @@ int iscsi_target_rx_thread(void *arg)if (rc <0 ||iscsi_target_check_conn_state (conn))return 0 ; -if (conn->conn_transport->transport_type ==ISCSI_INFINIBAND ) { -struct completion comp; - -init_completion (&comp); - rc =wait_for_completion_interruptible (&comp); -if (rc <0 ) - goto transport_err; - +if (conn->conn_transport->iscsit_get_rx_pdu) { + conn->conn_transport->iscsit_get_rx_pdu (conn); goto transport_err; }
include/target/iscsi/iscsi_transport.h +1 -0
@@ -25,6 +25,7 @@ struct iscsit_transport {int (*iscsit_xmit_pdu)(struct iscsi_conn *,struct iscsi_cmd *,struct iscsi_datain_req *,const void *,u32 );void (*iscsit_release_cmd)(struct iscsi_conn *,struct iscsi_cmd *); +void (*iscsit_get_rx_pdu)(struct iscsi_conn *);enum target_prot_op (*iscsit_get_sup_prot_ops)(struct iscsi_conn *); };
Signature · 1 line
2.0.2
Re: [PATCH v3 03/13] iscsi-target: add void (*iscsit_get_rx_pdu)()
Hi Varun,
Quoted 23 lines · Varun Prakash
Add void (*iscsit_get_rx_pdu)() to
structiscsit_transport, iscsi-target
uses this callback to receive and
process Rx iSCSI PDUs.cxgbit.ko needs this callback to
reuse iscsi-target Rx thread.Signed-off-by Varun Prakash <[email protected]>Acked-by Sagi Grimberg <[email protected]>--- drivers/infiniband/ulp/isert/ib_isert.c | 10 ++++++++++ drivers/target/iscsi/iscsi_target.c | 10 ++-------- include/target/iscsi/iscsi_transport.h | 1 + 3 files changed, 13 insertions(+), 8 deletions(-)drivers/infiniband/ulp/isert/ib_isert.c +0
-0@@ -3273,6 +3273,15 @@ static void isert_free_conn(struct iscsi_conn *conn)isert_put_conn (isert_conn); }
drivers/infiniband/ulp/isert/ib_isert.c static void isert_free_conn(struct iscsi_conn *conn) · line 3284
Quoted 10 lines
drivers/infiniband/ulp/isert/ib_isert.c +9
-0+static void isert_get_rx_pdu (struct iscsi_conn *conn) +{ +struct completion comp; + +init_completion (&comp); + +wait_for_completion_interruptible (&comp); +} +
Does this mean that the iser rx thread just does nothing and waits to receive a signal to exit?
If we don't set *iscsit_get_rx_pdu for iser, so the thread exits immediately from iscsi_target_rx_thread, would that be an ok change?
Thanks -- Regards -- Andy
Quoted 45 lines
drivers/infiniband/ulp/isert/ib_isert.c +1
-0static struct iscsit_transport iser_target_transport = { .name ="IB/iSER" , .transport_type =ISCSI_INFINIBAND ,@@ -3291,6 +3300,7 @@ static struct iscsit_transport iser_target_transport = { .iscsit_queue_data_in = isert_put_datain, .iscsit_queue_status = isert_put_response, .iscsit_aborted_task = isert_aborted_task, + .iscsit_get_rx_pdu = isert_get_rx_pdu, .iscsit_get_sup_prot_ops = isert_get_sup_prot_ops, };drivers/target/iscsi/iscsi_target.c +2
-8@@ -3951,14 +3951,8 @@ int iscsi_target_rx_thread(void *arg)if (rc <0 ||iscsi_target_check_conn_state (conn))return 0 ; -if (conn->conn_transport->transport_type ==ISCSI_INFINIBAND ) { -struct completion comp; - -init_completion (&comp); - rc =wait_for_completion_interruptible (&comp); -if (rc <0 ) - goto transport_err; - +if (conn->conn_transport->iscsit_get_rx_pdu) { + conn->conn_transport->iscsit_get_rx_pdu (conn); goto transport_err; }include/target/iscsi/iscsi_transport.h +1
-0@@ -25,6 +25,7 @@ struct iscsit_transport {int (*iscsit_xmit_pdu)(struct iscsi_conn *,struct iscsi_cmd *,struct iscsi_datain_req *,const void *,u32 );void (*iscsit_release_cmd)(struct iscsi_conn *,struct iscsi_cmd *); +void (*iscsit_get_rx_pdu)(struct iscsi_conn *);enum target_prot_op (*iscsit_get_sup_prot_ops)(struct iscsi_conn *); };
Re: [PATCH v3 03/13] iscsi-target: add void (*iscsit_get_rx_pdu)()
Hi Andy,
Quoted 27 lines · Andy Grover
Hi Varun,
Quoted 24 lines · Varun Prakash
Add void (*iscsit_get_rx_pdu)() to
structiscsit_transport, iscsi-target
uses this callback to receive and
process Rx iSCSI PDUs.cxgbit.ko needs this callback to
reuse iscsi-target Rx thread.Signed-off-by Varun Prakash <[email protected]>Acked-by Sagi Grimberg <[email protected]>--- drivers/infiniband/ulp/isert/ib_isert.c | 10 ++++++++++ drivers/target/iscsi/iscsi_target.c | 10 ++-------- include/target/iscsi/iscsi_transport.h | 1 + 3 files changed, 13 insertions(+), 8 deletions(-)drivers/infiniband/ulp/isert/ib_isert.c +0
-0@@ -3273,6 +3273,15 @@ static void isert_free_conn(struct iscsi_conn *conn)isert_put_conn (isert_conn); }
Quoted 12 lines
drivers/infiniband/ulp/isert/ib_isert.c static void isert_free_conn(struct iscsi_conn *conn) · line 3284
Quoted 9 lines
drivers/infiniband/ulp/isert/ib_isert.c +9
-0+static void isert_get_rx_pdu (struct iscsi_conn *conn) +{ +struct completion comp; + +init_completion (&comp); + +wait_for_completion_interruptible (&comp); +} +Does this mean that the iser rx thread just does nothing and waits to receive a signal to exit?
Yes.
Quoted 3 lines
If we don't set
*iscsit_get_rx_pdufor iser, so the thread exits immediately fromiscsi_target_rx_thread, would that be an ok change?
I think it may need few more changes to remove Rx thread. Please see Nicholas's comment on this issue.
https://www.spinics.net/lists/target-devel/msg12269.html
Thanks
Varun
PATCH v3 4/13 iscsi-target: split iscsi_target_rx_thread()
In reply to Varun Prakashsplit iscsi_target_rx_thread() into two parts,
1. iscsi_target_rx_thread() is common to all
transport drivers, it will call Rx function
registered by transport driver.
2. iscsit_get_rx_pdu() is Rx function for
ISCSI_TCP transport.
--- drivers/target/iscsi/iscsi_target.c | 59 +++++++++++++++++++++---------------- 1 file changed, 33 insertions(+), 26 deletions(-)
drivers/target/iscsi/iscsi_target.c +33 -26
@@ -480,6 +480,7 @@ int iscsit_del_np(struct iscsi_np *np)static int iscsit_immediate_queue (struct iscsi_conn *,struct iscsi_cmd *,int );static int iscsit_response_queue (struct iscsi_conn *,struct iscsi_cmd *,int ); +static void iscsit_get_rx_pdu (struct iscsi_conn *);static int iscsit_queue_rsp (struct iscsi_conn *conn,struct iscsi_cmd *cmd) {
@@ -682,6 +683,7 @@ static struct iscsit_transport iscsi_target_transport = { .iscsit_queue_status = iscsit_queue_rsp, .iscsit_aborted_task = iscsit_aborted_task, .iscsit_xmit_pdu = iscsit_xmit_pdu, + .iscsit_get_rx_pdu = iscsit_get_rx_pdu, .iscsit_get_sup_prot_ops = iscsit_get_sup_prot_ops, };
@@ -3931,30 +3933,12 @@ static bool iscsi_target_check_conn_state(struct iscsi_conn *conn)return ret; } -int iscsi_target_rx_thread (void *arg) +static void iscsit_get_rx_pdu (struct iscsi_conn *conn) { -int ret, rc; +int ret;u8 buffer[ISCSI_HDR_LEN ], opcode;u32 checksum =0 , digest =0 ; -struct iscsi_conn *conn = arg;struct kvec iov; -/* -* Allow ourselves to be interrupted by SIGINT so that a -* connection recovery / failure event can be triggered externally. -*/ -allow_signal (SIGINT ); -/* -* Wait for iscsi_post_login_handler() to complete before allowing -* incoming iscsi/tcp socket I/O, and/or failing the connection. -*/ - rc =wait_for_completion_interruptible (&conn->rx_login_comp); -if (rc <0 ||iscsi_target_check_conn_state (conn)) -return 0 ; - -if (conn->conn_transport->iscsit_get_rx_pdu) { - conn->conn_transport->iscsit_get_rx_pdu (conn); - goto transport_err; - }while (!kthread_should_stop ()) {/*
@@ -3972,7 +3956,7 @@ int iscsi_target_rx_thread(void *arg) ret =rx_data (conn, &iov,1 ,ISCSI_HDR_LEN );if (ret !=ISCSI_HDR_LEN ) {iscsit_rx_thread_wait_for_tcp (conn); - goto transport_err; +return ; }if (conn->conn_ops->HeaderDigest) {
@@ -3982,7 +3966,7 @@ int iscsi_target_rx_thread(void *arg) ret =rx_data (conn, &iov,1 ,ISCSI_CRC_LEN );if (ret !=ISCSI_CRC_LEN ) {iscsit_rx_thread_wait_for_tcp (conn); - goto transport_err; +return ; } iscsit_do_crypto_hash_buf(conn->conn_rx_hash,
@@ -4006,7 +3990,7 @@ int iscsi_target_rx_thread(void *arg) }if (conn->conn_state ==TARG_CONN_STATE_IN_LOGOUT ) - goto transport_err; +return ; opcode = buffer[0 ] &ISCSI_OPCODE_MASK ;
@@ -4017,15 +4001,38 @@ int iscsi_target_rx_thread(void *arg) " while in Discovery Session, rejecting.\n", opcode);iscsit_add_reject (conn,ISCSI_REASON_PROTOCOL_ERROR , buffer); - goto transport_err; +return ; } ret =iscsi_target_rx_opcode (conn, buffer);if (ret <0 ) - goto transport_err; +return ; } +} + +int iscsi_target_rx_thread (void *arg) +{ +int rc; +struct iscsi_conn *conn = arg; + +/* +* Allow ourselves to be interrupted by SIGINT so that a +* connection recovery / failure event can be triggered externally. +*/ +allow_signal (SIGINT ); +/* +* Wait for iscsi_post_login_handler() to complete before allowing +* incoming iscsi/tcp socket I/O, and/or failing the connection. +*/ + rc =wait_for_completion_interruptible (&conn->rx_login_comp); +if (rc <0 ||iscsi_target_check_conn_state (conn)) +return 0 ; + +if (!conn->conn_transport->iscsit_get_rx_pdu) +return 0 ; + + conn->conn_transport->iscsit_get_rx_pdu (conn); -transport_err:if (!signal_pending (current))atomic_set (&conn->transport_failed,1 );iscsit_take_action_for_connection_exit (conn);
Signature · 1 line
2.0.2
PATCH v3 5/13 iscsi-target: add int (*iscsit_validate_params)()
In reply to Varun PrakashAdd int (*iscsit_validate_params)() to
struct iscsit_transport, iscsi-target
uses this callback for validating
conn operational parameters.
cxgbit.ko needs this callback to check
and update the value of
MAXXMITDATASEGMENTLENGTH.
--- drivers/target/iscsi/iscsi_target_login.c | 10 ++++++++++ include/target/iscsi/iscsi_transport.h | 1 + 2 files changed, 11 insertions(+)
drivers/target/iscsi/iscsi_target_login.c +10 -0
@@ -1387,6 +1387,16 @@ static int __iscsi_target_login_thread(struct iscsi_np *np) goto old_sess_out; } +if (conn->conn_transport->iscsit_validate_params) { + ret = conn->conn_transport->iscsit_validate_params (conn); +if (ret <0 ) { +if (zero_tsih) + goto new_sess_out; +else + goto old_sess_out; + } + } + ret =iscsi_target_start_negotiation (login, conn);if (ret <0 ) goto new_sess_out;
include/target/iscsi/iscsi_transport.h +1 -0
@@ -26,6 +26,7 @@ struct iscsit_transport { struct iscsi_datain_req *, const void *, u32);void (*iscsit_release_cmd)(struct iscsi_conn *,struct iscsi_cmd *);void (*iscsit_get_rx_pdu)(struct iscsi_conn *); +int (*iscsit_validate_params)(struct iscsi_conn *);enum target_prot_op (*iscsit_get_sup_prot_ops)(struct iscsi_conn *); };
Signature · 1 line
2.0.2
PATCH v3 6/13 iscsi-target: add void (*iscsit_get_r2t_ttt)()
In reply to Varun PrakashAdd void (*iscsit_get_r2t_ttt)() to struct iscsit_transport, iscsi-target uses this callback to get r2t->targ_xfer_tag.
cxgbit.ko needs this callback
for Direct Data Placement of Data Out pdus, adapter uses ttt in Data Out pdus for placing data directly in to the host buffers.
--- drivers/target/iscsi/iscsi_target.c | 5 ++++- include/target/iscsi/iscsi_transport.h | 2 ++ 2 files changed, 6 insertions(+), 1 deletion(-)
drivers/target/iscsi/iscsi_target.c +4 -1
@@ -3039,7 +3039,10 @@ static int iscsit_send_r2t(int_to_scsilun (cmd->se_cmd.orig_fe_lun, (struct scsi_lun *)&hdr->lun); hdr->itt = cmd->init_task_tag; - r2t->targ_xfer_tag =session_get_next_ttt (conn->sess); +if (conn->conn_transport->iscsit_get_r2t_ttt) + conn->conn_transport->iscsit_get_r2t_ttt (conn, cmd, r2t); +else + r2t->targ_xfer_tag =session_get_next_ttt (conn->sess); hdr->ttt =cpu_to_be32 (r2t->targ_xfer_tag); hdr->statsn =cpu_to_be32 (conn->stat_sn); hdr->exp_cmdsn =cpu_to_be32 (conn->sess->exp_cmd_sn);
include/target/iscsi/iscsi_transport.h +2 -0
@@ -27,6 +27,8 @@ struct iscsit_transport {void (*iscsit_release_cmd)(struct iscsi_conn *,struct iscsi_cmd *);void (*iscsit_get_rx_pdu)(struct iscsi_conn *);int (*iscsit_validate_params)(struct iscsi_conn *); +void (*iscsit_get_r2t_ttt)(struct iscsi_conn *,struct iscsi_cmd *, +struct iscsi_r2t *);enum target_prot_op (*iscsit_get_sup_prot_ops)(struct iscsi_conn *); };
Signature · 1 line
2.0.2
PATCH v3 7/13 iscsi-target: move iscsit_thread_check_cpumask()
In reply to Varun PrakashMove iscsit_thread_check_cpumask() to header file so that ISCSI_HW_OFFLOAD and other transport drivers can call this function to ensure both tx and rx thread runs on same cpu.
--- drivers/target/iscsi/iscsi_target.c | 26 -------------------------- include/target/iscsi/iscsi_target_core.h | 26 ++++++++++++++++++++++++++ 2 files changed, 26 insertions(+), 26 deletions(-)
drivers/target/iscsi/iscsi_target.c +0 -26
@@ -3580,32 +3580,6 @@ void iscsit_thread_get_cpumask(struct iscsi_conn *conn)cpumask_setall (conn->conn_cpumask); } -static inline void iscsit_thread_check_cpumask ( -struct iscsi_conn *conn, -struct task_struct *p, -int mode) -{ -/* -* mode == 1 signals iscsi_target_tx_thread() usage. -* mode == 0 signals iscsi_target_rx_thread() usage. -*/ -if (mode ==1 ) { -if (!conn->conn_tx_reset_cpumask) -return ; - conn->conn_tx_reset_cpumask =0 ; - }else { -if (!conn->conn_rx_reset_cpumask) -return ; - conn->conn_rx_reset_cpumask =0 ; - } -/* -* Update the CPU mask for this single kthread so that -* both TX and RX kthreads are scheduled to run on the -* same CPU. -*/ -set_cpus_allowed_ptr (p, conn->conn_cpumask); -} -static int iscsit_immediate_queue (struct iscsi_conn *conn,struct iscsi_cmd *cmd,int state) {
include/target/iscsi/iscsi_target_core.h +26 -0
@@ -890,4 +890,30 @@ static inline u32 session_get_next_ttt(struct iscsi_session *session) }extern struct iscsi_cmd *iscsit_find_cmd_from_itt (struct iscsi_conn *,itt_t ); + +static inline void iscsit_thread_check_cpumask ( +struct iscsi_conn *conn, +struct task_struct *p, +int mode) +{ +/* +* mode == 1 signals iscsi_target_tx_thread() usage. +* mode == 0 signals iscsi_target_rx_thread() usage. +*/ +if (mode ==1 ) { +if (!conn->conn_tx_reset_cpumask) +return ; + conn->conn_tx_reset_cpumask =0 ; + }else { +if (!conn->conn_rx_reset_cpumask) +return ; + conn->conn_rx_reset_cpumask =0 ; + } +/* +* Update the CPU mask for this single kthread so that +* both TX and RX kthreads are scheduled to run on the +* same CPU. +*/ +set_cpus_allowed_ptr (p, conn->conn_cpumask); +}#endif /* ISCSI_TARGET_CORE_H */
Signature · 1 line
2.0.2
PATCH v3 8/13 iscsi-target: use conn_transport->transport_type in text rsp
In reply to Varun PrakashUse conn_transport->transport_type instead ofISCSI_TCP to build text response.
--- drivers/target/iscsi/iscsi_target.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
drivers/target/iscsi/iscsi_target.c +2 -1
@@ -3513,7 +3513,8 @@ static int iscsit_send_text_rsp(struct iscsi_text_rsp *hdr = (struct iscsi_text_rsp *)cmd->pdu;int text_length; - text_length =iscsit_build_text_rsp (cmd, conn, hdr,ISCSI_TCP ); + text_length =iscsit_build_text_rsp (cmd, conn, hdr, + conn->conn_transport->transport_type);if (text_length <0 )return text_length;
Signature · 1 line
2.0.2
PATCH v3 9/13 iscsi-target: add new offload transport type
In reply to Varun PrakashAdd new transport type ISCSI_HW_OFFLOAD,
hw offload transport drivers will use
this transport type.
--- drivers/target/iscsi/iscsi_target_configfs.c | 76 ++++++++++++++++++++++++++++ include/target/iscsi/iscsi_target_core.h | 1 + 2 files changed, 77 insertions(+)
drivers/target/iscsi/iscsi_target_configfs.c +76 -0
@@ -182,12 +182,88 @@ out:return rc; } +static ssize_t lio_target_np_hw_offload_show (struct config_item *item, +char *page) +{ +struct iscsi_tpg_np *tpg_np =to_iscsi_tpg_np (item); +struct iscsi_tpg_np *tpg_np_hw_offload; +ssize_t rb; + + tpg_np_hw_offload =iscsit_tpg_locate_child_np (tpg_np, +ISCSI_HW_OFFLOAD ); +if (tpg_np_hw_offload) + rb =sprintf (page,"1\n" ); +else + rb =sprintf (page,"0\n" ); + +return rb; +} + +static ssize_t lio_target_np_hw_offload_store (struct config_item *item, +const char *page,size_t count) +{ +struct iscsi_tpg_np *tpg_np =to_iscsi_tpg_np (item); +struct iscsi_np *np; +struct iscsi_portal_group *tpg; +struct iscsi_tpg_np *tpg_np_hw_offload =NULL ; +u32 op; +int rc =0 ; + + rc =kstrtou32 (page,0 , &op); +if (rc) +return rc; + +if ((op !=1 ) && (op !=0 )) { +pr_err ("Illegal value for tpg_enable: %u\n" , op); +return -EINVAL ; + } + + np = tpg_np->tpg_np; +if (!np) { +pr_err ("Unable to locate struct iscsi_np from" +" struct iscsi_tpg_np\n" ); +return -EINVAL ; + } + + tpg = tpg_np->tpg; +if (iscsit_get_tpg (tpg) <0 ) +return -EINVAL ; + +if (op) { + tpg_np_hw_offload =iscsit_tpg_add_network_portal (tpg, + &np->np_sockaddr, tpg_np,ISCSI_HW_OFFLOAD ); + +if (IS_ERR (tpg_np_hw_offload)) { + rc =PTR_ERR (tpg_np_hw_offload); + goto out; + } + }else { + tpg_np_hw_offload =iscsit_tpg_locate_child_np (tpg_np, +ISCSI_HW_OFFLOAD ); + +if (tpg_np_hw_offload) { + rc =iscsit_tpg_del_network_portal (tpg, + tpg_np_hw_offload); +if (rc <0 ) + goto out; + } + } + +iscsit_put_tpg (tpg); +return count; +out: +iscsit_put_tpg (tpg); +return rc; +} +CONFIGFS_ATTR (lio_target_np_, sctp);CONFIGFS_ATTR (lio_target_np_, iser); +CONFIGFS_ATTR (lio_target_np_, hw_offload);static struct configfs_attribute *lio_target_portal_attrs[] = { &lio_target_np_attr_sctp, &lio_target_np_attr_iser, + &lio_target_np_attr_hw_offload,NULL , };
include/target/iscsi/iscsi_target_core.h +1 -0
@@ -74,6 +74,7 @@ enum iscsit_transport_type {ISCSI_IWARP_TCP =3 ,ISCSI_IWARP_SCTP =4 ,ISCSI_INFINIBAND =5 , + ISCSI_HW_OFFLOAD = 6, };/* RFC-3720 7.1.4 Standard Connection State Diagram for a Target */
Signature · 1 line
2.0.2
PATCH v3 10/13 iscsi-target: clear tx_thread_active
In reply to Varun Prakashclear tx_thread_active for ISCSI_HW_OFFLOAD
transport in logout_post_handler functions.
--- drivers/target/iscsi/iscsi_target.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)
drivers/target/iscsi/iscsi_target.c +4 -2
@@ -4379,7 +4379,8 @@ static void iscsit_logout_post_handler_closesession(* always sleep waiting for RX/TX thread shutdown to complete * within iscsit_close_connection(). */ -if (conn->conn_transport->transport_type ==ISCSI_TCP ) +if ((conn->conn_transport->transport_type ==ISCSI_TCP ) || + (conn->conn_transport->transport_type ==ISCSI_HW_OFFLOAD )) sleep =cmpxchg (&conn->tx_thread_active, true, false);atomic_set (&conn->conn_logout_remove,0 );
@@ -4396,7 +4397,8 @@ static void iscsit_logout_post_handler_samecid( {int sleep =1 ; -if (conn->conn_transport->transport_type ==ISCSI_TCP ) +if ((conn->conn_transport->transport_type ==ISCSI_TCP ) || + (conn->conn_transport->transport_type ==ISCSI_HW_OFFLOAD )) sleep =cmpxchg (&conn->tx_thread_active, true, false);atomic_set (&conn->conn_logout_remove,0 );
Signature · 1 line
2.0.2
PATCH v3 11/13 iscsi-target: call complete on conn_logout_comp
In reply to Varun PrakashISCSI_HW_OFFLOAD transport drivers waits
on conn_logout_comp as ISCSI_TCP driver
so call complete if transport type
is ISCSI_HW_OFFLOAD.
--- drivers/target/iscsi/iscsi_target.c | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-)
drivers/target/iscsi/iscsi_target.c +6 -4
@@ -4063,16 +4063,18 @@ int iscsit_close_connection(pr_debug ("Closing iSCSI connection CID %hu on SID:" " %u\n" , conn->cid, sess->sid);/* -* Always up conn_logout_comp for the traditional TCP case just in case -* the RX Thread in iscsi_target_rx_opcode() is sleeping and the logout -* response never got sent because the connection failed. +* Always up conn_logout_comp for the traditional TCP and HW_OFFLOAD +* case just in case the RX Thread in iscsi_target_rx_opcode() is +* sleeping and the logout response never got sent because the +* connection failed. * * However for iser-target, isert_wait4logout() is using conn_logout_comp * to signal logout response TX interrupt completion. Go ahead and skip * this for iser since isert_rx_opcode() does not wait on logout failure, * and to avoid iscsi_conn pointer dereference in iser-target code. */ -if (conn->conn_transport->transport_type ==ISCSI_TCP ) +if ((conn->conn_transport->transport_type ==ISCSI_TCP ) || + (conn->conn_transport->transport_type ==ISCSI_HW_OFFLOAD ))complete (&conn->conn_logout_comp);if (!strcmp (current->comm,ISCSI_RX_THREAD_NAME )) {
Signature · 1 line
2.0.2
PATCH v3 12/13 iscsi-target: export symbols
In reply to Varun Prakashexport symbols for ISCSI_HW_OFFLOAD
transport drivers.
--- drivers/target/iscsi/iscsi_target.c | 25 ++++++++++------- drivers/target/iscsi/iscsi_target_datain_values.c | 1 + drivers/target/iscsi/iscsi_target_login.c | 3 ++- drivers/target/iscsi/iscsi_target_nego.c | 1 + drivers/target/iscsi/iscsi_target_parameters.c | 1 + drivers/target/iscsi/iscsi_target_util.c | 2 ++ include/target/iscsi/iscsi_transport.h | 33 +++++++++++++++++++++++ 7 files changed, 56 insertions(+), 10 deletions(-)
drivers/target/iscsi/iscsi_target.c +16 -9
@@ -478,17 +478,16 @@ int iscsit_del_np(struct iscsi_np *np)return 0 ; } -static int iscsit_immediate_queue (struct iscsi_conn *,struct iscsi_cmd *,int ); -static int iscsit_response_queue (struct iscsi_conn *,struct iscsi_cmd *,int );static void iscsit_get_rx_pdu (struct iscsi_conn *); -static int iscsit_queue_rsp (struct iscsi_conn *conn,struct iscsi_cmd *cmd) +int iscsit_queue_rsp (struct iscsi_conn *conn,struct iscsi_cmd *cmd) {iscsit_add_cmd_to_response_queue (cmd, cmd->conn, cmd->i_state);return 0 ; } +EXPORT_SYMBOL (iscsit_queue_rsp); -static void iscsit_aborted_task (struct iscsi_conn *conn,struct iscsi_cmd *cmd) +void iscsit_aborted_task (struct iscsi_conn *conn,struct iscsi_cmd *cmd) {bool scsi_cmd = (cmd->iscsi_opcode ==ISCSI_OP_SCSI_CMD );
@@ -499,6 +498,7 @@ static void iscsit_aborted_task(struct iscsi_conn *conn, struct iscsi_cmd *cmd)__iscsit_free_cmd (cmd, scsi_cmd, true); } +EXPORT_SYMBOL (iscsit_aborted_task);static void iscsit_do_crypto_hash_buf (struct ahash_request *,const void *,u32 ,u32 ,u8 *,u8 *);
@@ -799,7 +799,7 @@ static void __exit iscsi_target_cleanup_module(void)kfree (iscsit_global); } -static int iscsit_add_reject ( +int iscsit_add_reject (struct iscsi_conn *conn,u8 reason,unsigned char *buf)
@@ -829,6 +829,7 @@ static int iscsit_add_reject(return -1 ; } +EXPORT_SYMBOL (iscsit_add_reject); static int iscsit_add_reject_from_cmd( struct iscsi_cmd *cmd,
@@ -884,6 +885,7 @@ int iscsit_reject_cmd(struct iscsi_cmd *cmd, u8 reason, unsigned char *buf) {return iscsit_add_reject_from_cmd (cmd, reason, false, buf); } +EXPORT_SYMBOL (iscsit_reject_cmd);/* * Map some portion of the allocated scatterlist to an iovec, suitable for
@@ -2500,7 +2502,7 @@ iscsit_handle_logout_cmd(struct iscsi_conn *conn, struct iscsi_cmd *cmd, }EXPORT_SYMBOL (iscsit_handle_logout_cmd); -static int iscsit_handle_snack ( +int iscsit_handle_snack (struct iscsi_conn *conn,unsigned char *buf) {
@@ -2553,6 +2555,7 @@ static int iscsit_handle_snack(return 0 ; } +EXPORT_SYMBOL (iscsit_handle_snack);static void iscsit_rx_thread_wait_for_tcp (struct iscsi_conn *conn) {
@@ -2733,7 +2736,7 @@ static void iscsit_tx_thread_wait_for_tcp(struct iscsi_conn *conn) } } -static void +void iscsit_build_datain_pdu (struct iscsi_cmd *cmd,struct iscsi_conn *conn,struct iscsi_datain *datain,struct iscsi_data_rsp *hdr,bool set_statsn)
@@ -2777,6 +2780,7 @@ iscsit_build_datain_pdu(struct iscsi_cmd *cmd, struct iscsi_conn *conn, cmd->init_task_tag,ntohl (hdr->statsn),ntohl (hdr->datasn), ntohl(hdr->offset), datain->length, conn->cid); } +EXPORT_SYMBOL (iscsit_build_datain_pdu);static int iscsit_send_datain (struct iscsi_cmd *cmd,struct iscsi_conn *conn) {
@@ -3153,6 +3157,7 @@ int iscsit_build_r2ts_for_cmd(return 0 ; } +EXPORT_SYMBOL (iscsit_build_r2ts_for_cmd);void iscsit_build_rsp_pdu (struct iscsi_cmd *cmd,struct iscsi_conn *conn,bool inc_stat_sn,struct iscsi_scsi_rsp *hdr)
@@ -3581,7 +3586,7 @@ void iscsit_thread_get_cpumask(struct iscsi_conn *conn)cpumask_setall (conn->conn_cpumask); } -static int +int iscsit_immediate_queue (struct iscsi_conn *conn,struct iscsi_cmd *cmd,int state) {int ret;
@@ -3623,6 +3628,7 @@ iscsit_immediate_queue(struct iscsi_conn *conn, struct iscsi_cmd *cmd, int state err:return -1 ; } +EXPORT_SYMBOL (iscsit_immediate_queue);static int iscsit_handle_immediate_queue (struct iscsi_conn *conn)
@@ -3647,7 +3653,7 @@ iscsit_handle_immediate_queue(struct iscsi_conn *conn)return 0 ; } -static int +int iscsit_response_queue (struct iscsi_conn *conn,struct iscsi_cmd *cmd,int state) {int ret;
@@ -3752,6 +3758,7 @@ check_rsp_state: err:return -1 ; } +EXPORT_SYMBOL (iscsit_response_queue);static int iscsit_handle_response_queue (struct iscsi_conn *conn) {
drivers/target/iscsi/iscsi_target_datain_values.c +1 -0
@@ -524,3 +524,4 @@ struct iscsi_datain_req *iscsit_get_datain_values(return NULL ; } +EXPORT_SYMBOL (iscsit_get_datain_values);
drivers/target/iscsi/iscsi_target_login.c +2 -1
@@ -258,7 +258,7 @@ static void iscsi_login_set_conn_values(mutex_unlock (&auth_id_lock); } -static __printf(2, 3) int iscsi_change_param_sprintf( +__printf(2, 3) int iscsi_change_param_sprintf(struct iscsi_conn *conn,const char *fmt, ...) {
@@ -279,6 +279,7 @@ static __printf(2, 3) int iscsi_change_param_sprintf(return 0 ; } +EXPORT_SYMBOL (iscsi_change_param_sprintf);/* * This is the leading connection of a new session,
drivers/target/iscsi/iscsi_target_nego.c +1 -0
@@ -269,6 +269,7 @@ int iscsi_target_check_login_request(return 0 ; } +EXPORT_SYMBOL (iscsi_target_check_login_request); static int iscsi_target_check_first_request( struct iscsi_conn *conn,
drivers/target/iscsi/iscsi_target_parameters.c +1 -0
@@ -680,6 +680,7 @@ struct iscsi_param *iscsi_find_param_from_key(pr_err ("Unable to locate key \"%s\".\n" , key);return NULL ; } +EXPORT_SYMBOL (iscsi_find_param_from_key);int iscsi_extract_key_value (char *textbuf,char **key,char **value) {
drivers/target/iscsi/iscsi_target_util.c +2 -0
@@ -514,6 +514,7 @@ void iscsit_add_cmd_to_immediate_queue(wake_up (&conn->queues_wq); } +EXPORT_SYMBOL (iscsit_add_cmd_to_immediate_queue);struct iscsi_queue_req *iscsit_get_cmd_from_immediate_queue (struct iscsi_conn *conn) {
@@ -776,6 +777,7 @@ void iscsit_free_cmd(struct iscsi_cmd *cmd, bool shutdown)break ; } } +EXPORT_SYMBOL (iscsit_free_cmd);int iscsit_check_session_usage_count (struct iscsi_session *sess) {
include/target/iscsi/iscsi_transport.h +33 -0
@@ -84,6 +84,18 @@ extern void iscsit_build_reject(struct iscsi_cmd *, struct iscsi_conn *,extern int iscsit_build_logout_rsp (struct iscsi_cmd *,struct iscsi_conn *,struct iscsi_logout_rsp *);extern int iscsit_logout_post_handler (struct iscsi_cmd *,struct iscsi_conn *); +extern int iscsit_queue_rsp (struct iscsi_conn *,struct iscsi_cmd *); +extern void iscsit_aborted_task (struct iscsi_conn *,struct iscsi_cmd *); +extern int iscsit_add_reject (struct iscsi_conn *,u8 ,unsigned char *); +extern int iscsit_reject_cmd (struct iscsi_cmd *,u8 ,unsigned char *); +extern int iscsit_handle_snack (struct iscsi_conn *,unsigned char *); +extern void iscsit_build_datain_pdu (struct iscsi_cmd *,struct iscsi_conn *, +struct iscsi_datain *, +struct iscsi_data_rsp *,bool ); +extern int iscsit_build_r2ts_for_cmd (struct iscsi_conn *,struct iscsi_cmd *, +bool ); +extern int iscsit_immediate_queue (struct iscsi_conn *,struct iscsi_cmd *,int ); +extern int iscsit_response_queue (struct iscsi_conn *,struct iscsi_cmd *,int );/* * From iscsi_target_device.c */
@@ -109,3 +121,24 @@ extern struct iscsi_cmd *iscsit_allocate_cmd(struct iscsi_conn *, int);extern int iscsit_sequence_cmd (struct iscsi_conn *,struct iscsi_cmd *,unsigned char *,__be32 );extern void iscsit_release_cmd (struct iscsi_cmd *); +extern void iscsit_free_cmd (struct iscsi_cmd *,bool ); +extern void iscsit_add_cmd_to_immediate_queue (struct iscsi_cmd *, +struct iscsi_conn *,u8 ); + +/* +* From iscsi_target_nego.c +*/ +extern int iscsi_target_check_login_request (struct iscsi_conn *, +struct iscsi_login *); + +/* +* From iscsi_target_login.c +*/ +extern __printf(2, 3) int iscsi_change_param_sprintf( + struct iscsi_conn *, const char *, ...); + +/* +* From iscsi_target_parameters.c +*/ +extern struct iscsi_param *iscsi_find_param_from_key( +char *,struct iscsi_param_list *);
Signature · 1 line
2.0.2
PATCH v3 13/13 cxgbit: add files for cxgbit.ko
In reply to Varun Prakashcxgbit.h - This file contains data structure
definitions for cxgbit.ko.
cxgbit_lro.h - This file contains data structure
definitions for LRO support.
cxgbit_main.c - This file contains code for
registering with iscsi target transport and
cxgb4 driver.
cxgbit_cm.c - This file contains code for
connection management.
cxgbit_target.c - This file contains code
for processing iSCSI PDU.
cxgbit_ddp.c - This file contains code for Direct Data Placement.
v2: added check for NULL sg in cxgbit_set_one_ppod()
cxgbit: add Kconfig and Makefile
v2: added dependency on INET
iscsi-target: update Kconfig and Makefile
for compiling cxgbit.ko.
--- drivers/target/iscsi/Kconfig | 2 + drivers/target/iscsi/Makefile | 1 + drivers/target/iscsi/cxgbit/Kconfig | 7 + drivers/target/iscsi/cxgbit/Makefile | 6 + drivers/target/iscsi/cxgbit/cxgbit.h | 353 +++++ drivers/target/iscsi/cxgbit/cxgbit_cm.c | 2086 +++++++++++++++++++++++++++ drivers/target/iscsi/cxgbit/cxgbit_ddp.c | 325 +++++ drivers/target/iscsi/cxgbit/cxgbit_lro.h | 72 + drivers/target/iscsi/cxgbit/cxgbit_main.c | 701 +++++++++ drivers/target/iscsi/cxgbit/cxgbit_target.c | 1561 ++++++++++++++++++++ 10 files changed, 5114 insertions(+) create mode 100644 drivers/target/iscsi/cxgbit/Kconfig create mode 100644 drivers/target/iscsi/cxgbit/Makefile create mode 100644 drivers/target/iscsi/cxgbit/cxgbit.h create mode 100644 drivers/target/iscsi/cxgbit/cxgbit_cm.c create mode 100644 drivers/target/iscsi/cxgbit/cxgbit_ddp.c create mode 100644 drivers/target/iscsi/cxgbit/cxgbit_lro.h create mode 100644 drivers/target/iscsi/cxgbit/cxgbit_main.c create mode 100644 drivers/target/iscsi/cxgbit/cxgbit_target.c
drivers/target/iscsi/Kconfig +2 -0
@@ -7,3 +7,5 @@ config ISCSI_TARGET help Say M here to enable the ConfigFS enabled Linux-iSCSI.org iSCSI Target Mode Stack. + +source "drivers/target/iscsi/cxgbit/Kconfig"
drivers/target/iscsi/Makefile +1 -0
@@ -18,3 +18,4 @@ iscsi_target_mod-y += iscsi_target_parameters.o \ iscsi_target_transport.o obj-$(CONFIG_ISCSI_TARGET) += iscsi_target_mod.o +obj-$(CONFIG_ISCSI_TARGET_CXGB4) += cxgbit/
drivers/target/iscsi/cxgbit/Kconfig new file +7 -0
@@ -0,0 +1,7 @@ +config ISCSI_TARGET_CXGB4 + tristate "Chelsio iSCSI target offload driver" + depends on ISCSI_TARGET && CHELSIO_T4 && INET + select CHELSIO_T4_UWIRE + ---help--- + To compile this driver as module, choose M here: the module + will be called cxgbit.
drivers/target/iscsi/cxgbit/Makefile new file +6 -0
@@ -0,0 +1,6 @@ +ccflags-y := -Idrivers/net/ethernet/chelsio/cxgb4 +ccflags-y += -Idrivers/target/iscsi + +obj-$(CONFIG_ISCSI_TARGET_CXGB4) += cxgbit.o + +cxgbit-y := cxgbit_main.o cxgbit_cm.o cxgbit_target.o cxgbit_ddp.o
drivers/target/iscsi/cxgbit/cxgbit.h new file +353 -0
353 lines not on this page · raw message
drivers/target/iscsi/cxgbit/cxgbit_cm.c new file +2086 -0
2,086 lines not on this page · raw message
drivers/target/iscsi/cxgbit/cxgbit_ddp.c new file +325 -0
325 lines not on this page · raw message
drivers/target/iscsi/cxgbit/cxgbit_lro.h new file +72 -0
72 lines not on this page · raw message
drivers/target/iscsi/cxgbit/cxgbit_main.c new file +701 -0
142 lines not on this page · raw message
drivers/target/iscsi/cxgbit/cxgbit_target.c new file +1561 -0
1,561 lines not on this page · raw message
The rest of this diff is not shown. View the raw message.
Signature · 1 line
2.0.2
Part of the diff is not shown here. View the raw message.
Re: [PATCH v3 13/13] cxgbit: add files for cxgbit.ko
Quoted 10 lines · Varun Prakash
cxgbit.h- This file contains data structure definitions for cxgbit.ko.
cxgbit_lro.h- This file contains data structure definitions for LRO support.
cxgbit_main.c- This file contains code for registering with iscsi target transport and cxgb4 driver.
Quoted 8 lines
cxgbit_cm.c- This file contains code for connection management.
cxgbit_target.c- This file contains code for processing iSCSI PDU.
cxgbit_ddp.c- This file contains code for Direct Data Placement.
Wait,
You are adding many K's LOCs to handle things like CM (connection management), DDP and LRO. But your upstream solution must be using CM and DDP (and LRO as well) for the HW offloaded initiator side as well, not to mention the iWARP side of things.
There must be some way to refactor things instead of repeating the same bits over and over, thoughts?
Or.
Quoted 11 lines
drivers/target/iscsi/Kconfig | 2 + drivers/target/iscsi/Makefile | 1 + drivers/target/iscsi/cxgbit/Kconfig | 7 + drivers/target/iscsi/cxgbit/Makefile | 6 + drivers/target/iscsi/cxgbit/cxgbit.h | 353 +++++ drivers/target/iscsi/cxgbit/cxgbit_cm.c | 2086 +++++++++++++++++++++++++++ drivers/target/iscsi/cxgbit/cxgbit_ddp.c | 325 +++++ drivers/target/iscsi/cxgbit/cxgbit_lro.h | 72 + drivers/target/iscsi/cxgbit/cxgbit_main.c | 701 +++++++++ drivers/target/iscsi/cxgbit/cxgbit_target.c | 1561 ++++++++++++++++++++ 10 files changed, 5114 insertions(+)
Re: [PATCH v3 13/13] cxgbit: add files for cxgbit.ko
Quoted 22 lines · Or Gerlitz
Quoted 10 lines · Varun Prakash
cxgbit.h- This file contains data structure definitions for cxgbit.ko.
cxgbit_lro.h- This file contains data structure definitions for LRO support.
cxgbit_main.c- This file contains code for registering with iscsi target transport and cxgb4 driver.Quoted 8 lines
cxgbit_cm.c- This file contains code for connection management.
cxgbit_target.c- This file contains code for processing iSCSI PDU.
cxgbit_ddp.c- This file contains code for Direct Data Placement.Wait,
Quoted 7 lines
You are adding many K's LOCs to handle things like CM (connection management), DDP and LRO. But your upstream solution must be using CM and DDP (and LRO as well) for the HW offloaded initiator side as well, not to mention the iWARP side of things.
There must be some way to refactor things instead of repeating the same bits over and over, thoughts?
Nic,
The author haven't responded... where that this stands from your point of view?
Or.
Quoted 11 lines
Quoted 11 lines
drivers/target/iscsi/Kconfig | 2 + drivers/target/iscsi/Makefile | 1 + drivers/target/iscsi/cxgbit/Kconfig | 7 + drivers/target/iscsi/cxgbit/Makefile | 6 + drivers/target/iscsi/cxgbit/cxgbit.h | 353 +++++ drivers/target/iscsi/cxgbit/cxgbit_cm.c | 2086 +++++++++++++++++++++++++++ drivers/target/iscsi/cxgbit/cxgbit_ddp.c | 325 +++++ drivers/target/iscsi/cxgbit/cxgbit_lro.h | 72 + drivers/target/iscsi/cxgbit/cxgbit_main.c | 701 +++++++++ drivers/target/iscsi/cxgbit/cxgbit_target.c | 1561 ++++++++++++++++++++ 10 files changed, 5114 insertions(+)
Re: [PATCH v3 13/13] cxgbit: add files for cxgbit.ko
Hi Or & Co,
Quoted 28 lines · Or Gerlitz
Quoted 27 lines · Or Gerlitz
Quoted 10 lines · Varun Prakash
cxgbit.h- This file contains data structure definitions for cxgbit.ko.
cxgbit_lro.h- This file contains data structure definitions for LRO support.
cxgbit_main.c- This file contains code for registering with iscsi target transport and cxgb4 driver.Quoted 8 lines
cxgbit_cm.c- This file contains code for connection management.
cxgbit_target.c- This file contains code for processing iSCSI PDU.
cxgbit_ddp.c- This file contains code for Direct Data Placement.Wait,
You are adding many K's LOCs to handle things like CM (connection management), DDP and LRO. But your upstream solution must be using CM and DDP (and LRO as well) for the HW offloaded initiator side as well, not to mention the iWARP side of things.
Quoted 7 lines
Quoted 2 lines
There must be some way to refactor things instead of repeating the same bits over and over, thoughts?
Nic,
The author haven't responded... where that this stands from your point of view?
For an initial merge, I don't have an objection to this series wrt drivers/target/iscsi/* improvements + prerequisites, and new standalone cxgbit iscsit_transport driver.
That said, there are areas between cxgbi + cxgbit code that can be made common as you've pointed out. The Cheliso folks have mentioned off-list that cxgbi as-is in mainline does not support LRO, and that the majority of DDP logic is shared between initiator + target.
Are there specific pieces of logic in DDP or iWARP for cxgb* that you'd like to see Varun + Co pursue as common code in v4.8+..?
Re: [PATCH v3 13/13] cxgbit: add files for cxgbit.ko
Quoted 39 lines · Nicholas A. Bellinger
Hi Or & Co,
Quoted 28 lines · Or Gerlitz
Quoted 27 lines · Or Gerlitz
Quoted 10 lines · Varun Prakash
cxgbit.h- This file contains data structure definitions for cxgbit.ko.
cxgbit_lro.h- This file contains data structure definitions for LRO support.
cxgbit_main.c- This file contains code for registering with iscsi target transport and cxgb4 driver.Quoted 8 lines
cxgbit_cm.c- This file contains code for connection management.
cxgbit_target.c- This file contains code for processing iSCSI PDU.
cxgbit_ddp.c- This file contains code for Direct Data Placement.Wait,
You are adding many K's LOCs to handle things like CM (connection management), DDP and LRO. But your upstream solution must be using CM and DDP (and LRO as well) for the HW offloaded initiator side as well, not to mention the iWARP side of things.
Quoted 4 lines
Quoted 2 lines
There must be some way to refactor things instead of repeating the same bits over and over, thoughts?
The author haven't responded... where that this stands from your point of view?
For an initial merge, I don't have an objection to this series wrt
drivers/target/iscsi/*improvements + prerequisites, and new standalone cxgbitiscsit_transportdriver.
Quoted 7 lines
That said, there are areas between cxgbi + cxgbit code that can be made common as you've pointed out. The Cheliso folks have mentioned off-list that cxgbi as-is in mainline does not support LRO, and that the majority of DDP logic is shared between initiator + target.
Are there specific pieces of logic in DDP or iWARP for cxgb* that you'd like to see Varun + Co pursue as common code in v4.8+..?
Hi Nic,
As I wrote above, I have good reasons to believe that there are few K LOCs of duplication
between this series to the chelsio hw iscsi initiator or the chelsio iwarp driver or both (triple).
Ys, I'd like to see a public response from Varun and Co on this valid reviewer comment
before you proceed with this series, makes sense? There's no point to duplicate the same
code in the kernel again and again. **Even** if there's one duplication now, we don't want
another one.
Or.
RE: [PATCH v3 13/13] cxgbit: add files for cxgbit.ko
Quoted 66 lines
From: Or Gerlitz [mailto:[email protected]]
Quoted 39 lines · Nicholas A. Bellinger
Hi Or & Co,
Quoted 28 lines · Or Gerlitz
Quoted 27 lines · Or Gerlitz
Quoted 10 lines · Varun Prakash
cxgbit.h- This file contains data structure definitions for cxgbit.ko.
cxgbit_lro.h- This file contains data structure definitions for LRO support.
cxgbit_main.c- This file contains code for registering with iscsi target transport and cxgb4 driver.Quoted 8 lines
cxgbit_cm.c- This file contains code for connection management.
cxgbit_target.c- This file contains code for processing iSCSI PDU.
cxgbit_ddp.c- This file contains code for Direct Data Placement.Wait,
You are adding many K's LOCs to handle things like CM (connection management), DDP and LRO. But your upstream solution must be using CM and DDP (and LRO as well) for the HW offloaded initiator side as well, not to mention the iWARP side of things.
Quoted 4 lines
Quoted 2 lines
There must be some way to refactor things instead of repeating the same bits over and over, thoughts?
The author haven't responded... where that this stands from your point of view?
For an initial merge, I don't have an objection to this series wrt
drivers/target/iscsi/*improvements + prerequisites, and new standalone cxgbitiscsit_transportdriver.Quoted 7 lines
That said, there are areas between cxgbi + cxgbit code that can be made common as you've pointed out. The Cheliso folks have mentioned off-list that cxgbi as-is in mainline does not support LRO, and that the majority of DDP logic is shared between initiator + target.
Are there specific pieces of logic in DDP or iWARP for cxgb* that you'd like to see Varun + Co pursue as common code in v4.8+..?
Hi Nic,
As I wrote above, I have good reasons to believe that there are few K LOCs of duplication
between this series to the chelsio hw iscsi initiator or the chelsio iwarp driver or both (triple).Ys, I'd like to see a public response from Varun and Co on this valid reviewer comment
before you proceed with this series, makes sense? There's no point to duplicate the same
code in the kernel again and again. **Even** if there's one duplication now, we don't want
another one.
Quoted 1 line
Or.
Hey Or and Nicholas,
I've been staying out of this directly due to my workload. But I will now take a look at where and how we can refactor to reduce the code duplication. Here are some thoughts with a quick glance:
DDP is not used by iWARP. DDP is for direct placement attempt on a TCP streaming mode connection. RDMA has its own way of doing this that doesn’t utilize the same HW resources. So I would say that the DDP usage could be refactored such that there is a set of helper functions to do the common logic, like managing page pod adapter resources. An example would be cxgb4i.c:ddp_ppod_write_idata(), and cxgbit_ppod_write_idata() from patch 13.
Connection Management (CM) can definitely be refactored to share helper functions for setting up/tearing down TCP connections. But the iWARP logic is very different from iscsi once the TCP connection is setup and the connection moved into RDMA mode. So the sharing of logic would be in sending various CPL messages to the adapter to connect/accept/close/abort connections. Having said that, the initiator and target wouldn't share a lot by virtue of the initiator only doing active side connection setup, and the target only doing passive side connection setup. So refactor would be
common services that iw_cxgb4, cxgbi4, and cxgbit all use. An example
would be: iw_cxgb4/cm.c:send_connect(), and cxgb4i.c/send_act_open_req().
I didn't look at LRO at this point.
Anyway, none of these are particularly difficult, but will require significant effort and time. The current cxgbit series has had a lot of internal review and testing by the Chelsio iscsi team, and it would be great if this refactoring can be deferred with the promise that we will get it done for the 4.8 merge window. Thoughts?
Steve.
--
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
Re: [PATCH v3 13/13] cxgbit: add files for cxgbit.ko
Quoted 74 lines · Steve Wise
Quoted 66 lines
From: Or Gerlitz [mailto:[email protected]]
Quoted 39 lines · Nicholas A. Bellinger
Hi Or & Co,
Quoted 28 lines · Or Gerlitz
Quoted 27 lines · Or Gerlitz
Quoted 10 lines · Varun Prakash
cxgbit.h- This file contains data structure definitions for cxgbit.ko.
cxgbit_lro.h- This file contains data structure definitions for LRO support.
cxgbit_main.c- This file contains code for registering with iscsi target transport and cxgb4 driver.Quoted 8 lines
cxgbit_cm.c- This file contains code for connection management.
cxgbit_target.c- This file contains code for processing iSCSI PDU.
cxgbit_ddp.c- This file contains code for Direct Data Placement.Wait,
You are adding many K's LOCs to handle things like CM (connection management), DDP and LRO. But your upstream solution must be using CM and DDP (and LRO as well) for the HW offloaded initiator side as well, not to mention the iWARP side of things.
Quoted 4 lines
Quoted 2 lines
There must be some way to refactor things instead of repeating the same bits over and over, thoughts?
The author haven't responded... where that this stands from your point of view?
For an initial merge, I don't have an objection to this series wrt
drivers/target/iscsi/*improvements + prerequisites, and new standalone cxgbitiscsit_transportdriver.Quoted 7 lines
That said, there are areas between cxgbi + cxgbit code that can be made common as you've pointed out. The Cheliso folks have mentioned off-list that cxgbi as-is in mainline does not support LRO, and that the majority of DDP logic is shared between initiator + target.
Are there specific pieces of logic in DDP or iWARP for cxgb* that you'd like to see Varun + Co pursue as common code in v4.8+..?
Hi Nic,
As I wrote above, I have good reasons to believe that there are few K LOCs of duplication
between this series to the chelsio hw iscsi initiator or the chelsio iwarp driver or both (triple).Ys, I'd like to see a public response from Varun and Co on this valid reviewer comment
before you proceed with this series, makes sense? There's no point to duplicate the same
code in the kernel again and again. **Even** if there's one duplication now, we don't want
another one.Quoted 1 line
Or.
Hey Or and Nicholas,
I've been staying out of this directly due to my workload. But I will now take a look at where and how we can refactor to reduce the code duplication. Here are some thoughts with a quick glance:
Quoted 7 lines
DDP is not used by iWARP. DDP is for direct placement attempt on a TCP streaming mode connection. RDMA has its own way of doing this that doesn’t utilize the same HW resources. So I would say that the DDP usage could be refactored such that there is a set of helper functions to do the common logic, like managing page pod adapter resources. An example would be cxgb4i.c:ddp_ppod_write_idata(), and
cxgbit_ppod_write_idata()from patch 13.
sounds good
Quoted 6 lines
Connection Management (CM) can definitely be refactored to share helper functions for setting up/tearing down TCP connections. But the iWARP logic is very different from iscsi once the TCP connection is setup and the connection moved into RDMA mode. So the sharing of logic would be in sending various CPL messages to the adapter to connect/accept/close/abort connections.
Ditto
Quoted 3 lines
Having said that, the initiator and target wouldn't share a
lot by virtue of the initiator only doing active side connection setup, and the target only doing passive side connection setup.
Well, I am not sure. It's like saying that if you break the IB/RoCE CM to active side and passive side they will not share lots of code. If you look on the existing CM (drivers/infiniband/core/cm.c) and think how to break it to two, you'll see that you end up with two code bases to maintain with likelihood of same bugs and similar state machines to implement/maintain and debug. So in that sense, it's much (much) better to have one CM code which does both iscsi sides.
Quoted 3 lines
So refactor would be
common services thatiw_cxgb4, cxgbi4, and cxgbit all use. An example
would be: iw_cxgb4/cm.c:send_connect(), and cxgb4i.c/send_act_open_req().
good and one code base which treats both sides.
Quoted 7 lines
I didn't look at LRO at this point.
Anyway, none of these are particularly difficult, but will require significant effort and time. The current cxgbit series has had a lot of internal review and testing by the Chelsio iscsi team, and it would be great if this refactoring can be deferred with the promise that we will get it done for the 4.8 merge window. Thoughts?
We've been there, e.g Intel recently sent iWARP driver and throughout the review we realized that lots of the iwarp netlink code is shared between existing drivers and the new driver, so the driver didn't get in kernel X but rather X+1 after doing that fix, it's only off by one...
I don't think we should be letting duplication of that extent to get in, for Chelsio ppl that know the materials well better vs anyone else it should have been clear that they create that dup without any real justification and till that moment they didn't come here to even comment on that. Lets have them fix that for the next merge window, that's my thinking, Nic?
Or.
--
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
Re: [PATCH v3 13/13] cxgbit: add files for cxgbit.ko
Quoted 3 lines · Or Gerlitz
Quoted 2 lines · Steve Wise
Quoted 2 lines
From: Or Gerlitz [mailto:[email protected]]
<SNIP>
Quoted 59 lines
.
Quoted 7 lines
Hey Or and Nicholas,
I've been staying out of this directly due to my workload. But I will now take a look at where and how we can refactor to reduce the code duplication. Here are some thoughts with a quick glance:
Quoted 7 lines
DDP is not used by iWARP. DDP is for direct placement attempt on a TCP streaming mode connection. RDMA has its own way of doing this that doesn’t utilize the same HW resources. So I would say that the DDP usage could be refactored such that there is a set of helper functions to do the common logic, like managing page pod adapter resources. An example would be cxgb4i.c:ddp_ppod_write_idata(), and
cxgbit_ppod_write_idata()from patch 13.sounds good
Quoted 6 lines
Connection Management (CM) can definitely be refactored to share helper functions for setting up/tearing down TCP connections. But the iWARP logic is very different from iscsi once the TCP connection is setup and the connection moved into RDMA mode. So the sharing of logic would be in sending various CPL messages to the adapter to connect/accept/close/abort connections.
Ditto
Quoted 3 lines
Having said that, the initiator and target wouldn't share a
lot by virtue of the initiator only doing active side connection setup, and the target only doing passive side connection setup.Well, I am not sure. It's like saying that if you break the IB/RoCE CM to active side and passive side they will not share lots of code. If you look on the existing CM (
drivers/infiniband/core/cm.c) and think how to break it to two, you'll see that you end up with two code bases to maintain with likelihood of same bugs and similar state machines to implement/maintain and debug. So in that sense, it's much (much) better to have one CM code which does both iscsi sides.Quoted 3 lines
So refactor would be
common services thatiw_cxgb4, cxgbi4, and cxgbit all use. An example
would be: iw_cxgb4/cm.c:send_connect(), and cxgb4i.c/send_act_open_req().good and one code base which treats both sides.
Quoted 7 lines
I didn't look at LRO at this point.
Anyway, none of these are particularly difficult, but will require significant effort and time. The current cxgbit series has had a lot of internal review and testing by the Chelsio iscsi team, and it would be great if this refactoring can be deferred with the promise that we will get it done for the 4.8 merge window. Thoughts?
We've been there, e.g Intel recently sent iWARP driver and throughout the review we realized that lots of the iwarp netlink code is shared between existing drivers and the new driver, so the driver didn't get in kernel X but rather X+1 after doing that fix, it's only off by one...
Quoted 7 lines
I don't think we should be letting duplication of that extent to get in, for Chelsio ppl that know the materials well better vs anyone else it should have been clear that they create that dup without any real justification and till that moment they didn't come here to even comment on that. Lets have them fix that for the next merge window, that's my thinking, Nic?
Varun + Co have made common improvements between existing software iscsi-target RX + TX PDU handling and their new driver, and no further comments for these prerequisites have been made.
The additional improvements discussed here so far are cxgb* specific, and will not effect other drivers, and will not change configfs user ABI layout compatibility within /sys/kernel/config/target/iscsi/.
That being the case, I think it's a reasonable starting point for mainline users to consume target ISO on cxgb hardware, and for Chelsio to make further common code improvements across their existing host drivers.
--
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
Re: [PATCH v3 13/13] cxgbit: add files for cxgbit.ko
Hi Or, Nicholas and Steve
Thank you for the feedback and apologies for the delay in my response.
Quoted 39 lines · Nicholas A. Bellinger
Quoted 3 lines · Or Gerlitz
Quoted 2 lines · Steve Wise
Quoted 2 lines
From: Or Gerlitz [mailto:[email protected]]
<SNIP>
Quoted 20 lines
Quoted 3 lines
Quoted 1 line
So refactor would be
common services that
iw_cxgb4, cxgbi4, and cxgbit all use. An example
would be: iw_cxgb4/cm.c:send_connect(), and cxgb4i.c/send_act_open_req().good and one code base which treats both sides.
Quoted 7 lines
I didn't look at LRO at this point.
Anyway, none of these are particularly difficult, but will require significant effort and time. The current cxgbit series has had a lot of internal review and testing by the Chelsio iscsi team, and it would be great if this refactoring can be deferred with the promise that we will get it done for the 4.8 merge window. Thoughts?
We've been there, e.g Intel recently sent iWARP driver and throughout the review we realized that lots of the iwarp netlink code is shared between existing drivers and the new driver, so the driver didn't get in kernel X but rather X+1 after doing that fix, it's only off by one...
Quoted 7 lines
I don't think we should be letting duplication of that extent to get in, for Chelsio ppl that know the materials well better vs anyone else it should have been clear that they create that dup without any real justification and till that moment they didn't come here to even comment on that. Lets have them fix that for the next merge window, that's my thinking, Nic?
Varun + Co have made common improvements between existing software iscsi-target RX + TX PDU handling and their new driver, and no further comments for these prerequisites have been made.
Quoted 8 lines
The additional improvements discussed here so far are cxgb* specific, and will not effect other drivers, and will not change configfs user ABI layout compatibility within
/sys/kernel/config/target/iscsi/.That being the case, I think it's a reasonable starting point for mainline users to consume target ISO on cxgb hardware, and for Chelsio to make further common code improvements across their existing host drivers.
I agree that we can refactor initiator, target and iwarp drivers to reduce code duplication as Steve has mentioned. We will work on this for 4.8 merge window.
Regards,
Varun
Re: [PATCH v3 13/13] cxgbit: add files for cxgbit.ko
Quoted 13 lines · Varun Prakash
Hi Or, Nicholas and Steve
Thank you for the feedback and apologies for the delay in my response.Quoted 7 lines · Nicholas A. Bellinger
Varun + Co have made common improvements between existing software iscsi-target RX + TX PDU handling and their new driver, and no further comments for these prerequisites have been made.
The additional improvements discussed here so far are cxgb* specific, and will not effect other drivers, and will not change configfs user ABI layout compatibility within
/sys/kernel/config/target/iscsi/.
Quoted 8 lines
Quoted 4 lines
That being the case, I think it's a reasonable starting point for mainline users to consume target ISO on cxgb hardware, and for Chelsio to make further common code improvements across their existing host drivers.
I agree that we can refactor initiator, target and iwarp drivers to reduce code duplication as Steve has mentioned. We will work on this for 4.8 merge window.
Nic, Varun, was anything done on this matter? we're on rc6
Or.
Re: [PATCH v3 13/13] cxgbit: add files for cxgbit.ko
Quoted 10 lines · Or Gerlitz
Quoted 6 lines · Varun Prakash
Hi Or, Nicholas and Steve
Thank you for the feedback and apologies for the delay in my response.I agree that we can refactor initiator, target and iwarp drivers to reduce code duplication as Steve has mentioned. We will work on this for 4.8 merge window.
Nic, Varun, was anything done on this matter? we're on rc6
Yes, I am working on this, I will post first series within two days, it will add common library module libcxgb.ko.
In first series libcxgb.ko will have common iSCSI DDP Page Pod Manager that will be shared by three Chelsio iSCSI drivers
cxgb3i, cxgb4i, cxgbit.
In subsequent series I will add common connection management and other hardware specific common code in this module.
Re: [PATCH v3 13/13] cxgbit: add files for cxgbit.ko
Quoted 6 lines · Varun Prakash
Quoted 5 lines · Or Gerlitz
Quoted 2 lines · Varun Prakash
Hi Or, Nicholas and Steve
Thank you for the feedback and apologies for the delay in my response.
Quoted 8 lines
Quoted 5 lines
Quoted 3 lines
I agree that we can refactor initiator, target and iwarp drivers to reduce code duplication as Steve has mentioned. We will work on this for 4.8 merge window.
Nic, Varun, was anything done on this matter? we're on rc6
Yes, I am working on this, I will post first series within two days, it will add common library module libcxgb.ko.
thanks for the update, the plan was to get that info 4.8-rc1, and as we're after rc6 there's not much time left for submitting code for 4.8, so doing that sooner rather than later would be good here.
Quoted 4 lines
In first series libcxgb.ko will have common iSCSI DDP Page Pod Manager that will be shared by three Chelsio iSCSI drivers
cxgb3i, cxgb4i, cxgbit.
cool
Quoted 3 lines
In subsequent series I will add common connection management and other hardware specific common code in this module.
any chance to get that ready for 4.8 too?
Or.
Re: [PATCH v3 13/13] cxgbit: add files for cxgbit.ko
Quoted 25 lines · Or Gerlitz
Quoted 6 lines · Varun Prakash
Quoted 5 lines · Or Gerlitz
Quoted 2 lines · Varun Prakash
Hi Or, Nicholas and Steve
Thank you for the feedback and apologies for the delay in my response.Quoted 8 lines
Quoted 5 lines
Quoted 3 lines
I agree that we can refactor initiator, target and iwarp drivers to reduce code duplication as Steve has mentioned. We will work on this for 4.8 merge window.
Nic, Varun, was anything done on this matter? we're on rc6
Yes, I am working on this, I will post first series within two days, it will add common library module libcxgb.ko.
thanks for the update, the plan was to get that info 4.8-rc1, and as we're after rc6 there's not much time left for submitting code for 4.8, so doing that sooner rather than later would be good here.
Quoted 4 lines
In first series libcxgb.ko will have common iSCSI DDP Page Pod Manager that will be shared by three Chelsio iSCSI drivers
cxgb3i, cxgb4i, cxgbit.
Quoted 7 lines
cool
Quoted 3 lines
In subsequent series I will add common connection management and other hardware specific common code in this module.
any chance to get that ready for 4.8 too?
I am working on common connection management, it is a big change as it involves multiple modules, so it is difficult to get it ready for 4.8.
RE: [PATCH v3 13/13] cxgbit: add files for cxgbit.ko
Quoted 11 lines
Quoted 11 lines
Quoted 4 lines
In first series libcxgb.ko will have common iSCSI DDP Page Pod Manager that will be shared by three Chelsio iSCSI drivers
cxgb3i, cxgb4i, cxgbit.cool
Quoted 3 lines
In subsequent series I will add common connection management and other hardware specific common code in this module.
Quoted 5 lines
Quoted 1 line
any chance to get that ready for 4.8 too?
I am working on common connection management, it is a big change as it involves multiple modules, so it is difficult to get it ready for 4.8.
Let's shoot for 4.9 for the common CM. Nice work on the PPOD unification!
Steve.
Re: [PATCH v3 13/13] cxgbit: add files for cxgbit.ko
Quoted 11 lines · Steve Wise
Quoted 11 lines
Quoted 11 lines
Quoted 4 lines
In first series libcxgb.ko will have common iSCSI DDP Page Pod Manager that will be shared by three Chelsio iSCSI drivers
cxgb3i, cxgb4i, cxgbit.cool
Quoted 3 lines
In subsequent series I will add common connection management and other hardware specific common code in this module.
Quoted 7 lines
Quoted 5 lines
Quoted 1 line
any chance to get that ready for 4.8 too?
I am working on common connection management, it is a big change as it involves multiple modules, so it is difficult to get it ready for 4.8.
Let's shoot for 4.9 for the common CM. Nice work on the PPOD unification!
Taking into account that this was a reviewer comment that basically should have been addressed for
the initial merge into 4.7 and that there's more time for 4.8 work [1], could you try and get that for 4.8?