Re: do discovery through SW transports too
On Thu, 2013-06-20 at 19:01 +0300, Or Gerlitz wrote: > On 19/06/2013 04:32, Nicholas A. Bellinger wrote: > > So I'm pretty sure this is due to iscsi_target_parameters.c: > > iscsi_set_keys_irrelevant_for_discovery() currently clearing > > INITIATORRECVDATASEGMENTLENGTH and TARGETRECVDATASEGMENTLENGTH for > > all discovery scenarios.. > > > > As I'm still not yet able to force iser discovery to occur on the > > initiator side, can you give the following patch a shot on your setup..? > > > > --nab > > Nic, > > I see that this patch exists in the queue branch of your target-pending > tree, so I tested with that branch and still faced problems. So what > happens now is that the login of the discovery session works fine! , thanks for verifying that particular bit.. > But, the sending over the IB connection of the TEXT PDU containing > Sendtargets=Allwhich is 16 byte long > > iscsiadm: in kstart_conn > iscsiadm: in __kipc_call > iscsiadm: in kwritev > iscsiadm: in nlpayload_read > iscsiadm: in nlpayload_read > iscsiadm: sending text pdu with CmdSN 1, exp_statsn 1 > iscsiadm: >SendTargets=All > iscsiadm: in ksend_pdu_begin > iscsiadm: send PDU began for hdr 48 bytes and data 16 bytes > iscsiadm: in kwritev > iscsiadm: wrote 48 bytes of PDU header > iscsiadm: in kwritev > iscsiadm: wrote 16 bytes of PDU data > iscsiadm: in ksend_pdu_end > iscsiadm: in __kipc_call > iscsiadm: in kwritev > iscsiadm: in nlpayload_read > iscsiadm: in nlpayload_read > iscsiadm: send PDU finished for conn 28:0 > > > > fails, that is the kernel iser driver gets TX completion with error > IB_WC_REM_OP_ERR > > iser: iser_drain_tx_cq:tx id 88006facac98 status 11 vend_err 89 > > > Is there a chance you don't post RX buffer which is large enough to hold > these 48 + 16 bytes in case this is discovery and not normal session? > > AFAICT, the isert_put_login_tx() -> isert_alloc_rx_descriptors() -> isert_post_recv() is happening for both types of sessions, before the last login response is posted and login state moves to full feature phase. Can you post a target side dump with dynamic debugging enabled with the following..? echo 'module iscsi_target_mod +p' > /debug/dynamic_debug/control echo 'module ib_isert +p' > /debug/dynamic_debug/control --nab -- You received this message because you are subscribed to the Google Groups "open-iscsi" group. To unsubscribe from this group and stop receiving emails from it, send an email to open-iscsi+unsubscr...@googlegroups.com. To post to this group, send email to open-iscsi@googlegroups.com. Visit this group at http://groups.google.com/group/open-iscsi. For more options, visit https://groups.google.com/groups/opt_out.
Re: [PATCH v2] LIBISCSI: Added new boot entries in the session sysfs
On 06/20/2013 12:21 PM, Eddie Wai wrote: > v2: Moved the new BOOT params to the end of the iscsi_param enum > > This is the kernel part of the modification to extract the net params > from the ibft sysfs to the iface struct used for the connection > request upon sync_session in the open-iscsi util. > > Three new session sysfs params are defined: > boot_root - holds the name of the /sys/firmware/ibft or iscsi_rootN > boot_nic - holds the ethernetN name > boot_target - holds the targetN name > > Signed-off-by: Eddie Wai Ok. Reviewed-by: Mike Christie -- You received this message because you are subscribed to the Google Groups "open-iscsi" group. To unsubscribe from this group and stop receiving emails from it, send an email to open-iscsi+unsubscr...@googlegroups.com. To post to this group, send email to open-iscsi@googlegroups.com. Visit this group at http://groups.google.com/group/open-iscsi. For more options, visit https://groups.google.com/groups/opt_out.
[PATCH v2] LIBISCSI: Added new boot entries in the session sysfs
v2: Moved the new BOOT params to the end of the iscsi_param enum
This is the kernel part of the modification to extract the net params
from the ibft sysfs to the iface struct used for the connection
request upon sync_session in the open-iscsi util.
Three new session sysfs params are defined:
boot_root - holds the name of the /sys/firmware/ibft or iscsi_rootN
boot_nic - holds the ethernetN name
boot_target - holds the targetN name
Signed-off-by: Eddie Wai
---
drivers/scsi/libiscsi.c | 18 ++
drivers/scsi/scsi_transport_iscsi.c | 12
include/scsi/iscsi_if.h |5 +
include/scsi/libiscsi.h |4
4 files changed, 39 insertions(+), 0 deletions(-)
diff --git a/drivers/scsi/libiscsi.c b/drivers/scsi/libiscsi.c
index 5de9469..ae69dfc 100644
--- a/drivers/scsi/libiscsi.c
+++ b/drivers/scsi/libiscsi.c
@@ -2808,6 +2808,9 @@ void iscsi_session_teardown(struct iscsi_cls_session
*cls_session)
kfree(session->targetname);
kfree(session->targetalias);
kfree(session->initiatorname);
+ kfree(session->boot_root);
+ kfree(session->boot_nic);
+ kfree(session->boot_target);
kfree(session->ifacename);
iscsi_destroy_session(cls_session);
@@ -3248,6 +3251,12 @@ int iscsi_set_param(struct iscsi_cls_conn *cls_conn,
return iscsi_switch_str_param(&session->ifacename, buf);
case ISCSI_PARAM_INITIATOR_NAME:
return iscsi_switch_str_param(&session->initiatorname, buf);
+ case ISCSI_PARAM_BOOT_ROOT:
+ return iscsi_switch_str_param(&session->boot_root, buf);
+ case ISCSI_PARAM_BOOT_NIC:
+ return iscsi_switch_str_param(&session->boot_nic, buf);
+ case ISCSI_PARAM_BOOT_TARGET:
+ return iscsi_switch_str_param(&session->boot_target, buf);
default:
return -ENOSYS;
}
@@ -3326,6 +3335,15 @@ int iscsi_session_get_param(struct iscsi_cls_session
*cls_session,
case ISCSI_PARAM_INITIATOR_NAME:
len = sprintf(buf, "%s\n", session->initiatorname);
break;
+ case ISCSI_PARAM_BOOT_ROOT:
+ len = sprintf(buf, "%s\n", session->boot_root);
+ break;
+ case ISCSI_PARAM_BOOT_NIC:
+ len = sprintf(buf, "%s\n", session->boot_nic);
+ break;
+ case ISCSI_PARAM_BOOT_TARGET:
+ len = sprintf(buf, "%s\n", session->boot_target);
+ break;
default:
return -ENOSYS;
}
diff --git a/drivers/scsi/scsi_transport_iscsi.c
b/drivers/scsi/scsi_transport_iscsi.c
index 133926b..abf7c40 100644
--- a/drivers/scsi/scsi_transport_iscsi.c
+++ b/drivers/scsi/scsi_transport_iscsi.c
@@ -3473,6 +3473,9 @@ iscsi_session_attr(tgt_reset_tmo,
ISCSI_PARAM_TGT_RESET_TMO, 0);
iscsi_session_attr(ifacename, ISCSI_PARAM_IFACE_NAME, 0);
iscsi_session_attr(initiatorname, ISCSI_PARAM_INITIATOR_NAME, 0);
iscsi_session_attr(targetalias, ISCSI_PARAM_TARGET_ALIAS, 0);
+iscsi_session_attr(boot_root, ISCSI_PARAM_BOOT_ROOT, 0);
+iscsi_session_attr(boot_nic, ISCSI_PARAM_BOOT_NIC, 0);
+iscsi_session_attr(boot_target, ISCSI_PARAM_BOOT_TARGET, 0);
static ssize_t
show_priv_session_state(struct device *dev, struct device_attribute *attr,
@@ -3568,6 +3571,9 @@ static struct attribute *iscsi_session_attrs[] = {
&dev_attr_sess_ifacename.attr,
&dev_attr_sess_initiatorname.attr,
&dev_attr_sess_targetalias.attr,
+ &dev_attr_sess_boot_root.attr,
+ &dev_attr_sess_boot_nic.attr,
+ &dev_attr_sess_boot_target.attr,
&dev_attr_priv_sess_recovery_tmo.attr,
&dev_attr_priv_sess_state.attr,
&dev_attr_priv_sess_creator.attr,
@@ -3631,6 +3637,12 @@ static umode_t iscsi_session_attr_is_visible(struct
kobject *kobj,
param = ISCSI_PARAM_INITIATOR_NAME;
else if (attr == &dev_attr_sess_targetalias.attr)
param = ISCSI_PARAM_TARGET_ALIAS;
+ else if (attr == &dev_attr_sess_boot_root.attr)
+ param = ISCSI_PARAM_BOOT_ROOT;
+ else if (attr == &dev_attr_sess_boot_nic.attr)
+ param = ISCSI_PARAM_BOOT_NIC;
+ else if (attr == &dev_attr_sess_boot_target.attr)
+ param = ISCSI_PARAM_BOOT_TARGET;
else if (attr == &dev_attr_priv_sess_recovery_tmo.attr)
return S_IRUGO | S_IWUSR;
else if (attr == &dev_attr_priv_sess_state.attr)
diff --git a/include/scsi/iscsi_if.h b/include/scsi/iscsi_if.h
index fe7f06c..9d28ded 100644
--- a/include/scsi/iscsi_if.h
+++ b/include/scsi/iscsi_if.h
@@ -489,6 +489,11 @@ enum iscsi_param {
ISCSI_PARAM_CHAP_IN_IDX,
ISCSI_PARAM_CHAP_OUT_IDX,
+
+ ISCSI_PARAM_BOOT_ROOT,
+ ISCSI_PARAM_BOOT_NIC,
+ ISCSI_PARAM_BOOT_TARGET,
+
/* must always be last */
ISCSI_PARAM_MAX,
};
diff --git a/include/scsi/libiscsi.h b/include/scsi/libiscsi.h
index 0
Re: do discovery through SW transports too
On 06/20/2013 11:10 AM, Or Gerlitz wrote:
> On 19/06/2013 00:47, Mike Christie wrote:
>> On 06/18/2013 10:35 AM, Or Gerlitz wrote:
>>> Now, back to the initiator, Mike, is there a chance that the initiator
>>> SENDS the key TargetRecvDataSegmentLength? this shouldn't be the case
>>> according to the iser IETF spec.
>>>
>> See add_params_transport_specific() in login.c. Add some prints in there
>> to see what is set at that time and getting sent.
>
> Hi Mike,
>
> I see that in user space, session has type field, does this propagate
> into the kernel? in other words, can the iser kernel module somehow
No.
> realize if the session being created is normal or discovery?if not, is
> there an easy way to add that?
>
Pass it down like any other param. There is a param
ISCSI_PARAM_DISCOVERY_SESS for this, but I do not think userspace is
sending it down yet.
> Looking on add_params_transport_specific, I see that it checks the
> session type, but its only
> called when the type is NORMAL... also, is there any reason for the
You lost me. So it is not sent during discovery like we want right? Did
you say that want it sent because it will then hit the double bug where
it ends up working.
> initiator to send the
> TargetRecvDataSegmentLength key?
No idea off the top of my head :) You guys added that code for iser right?
>
> Or.
>
>
>> tatic int
>> add_params_transport_specific(iscsi_session_t *session, int cid,
>> struct iscsi_hdr *pdu, char *data,
>> int max_data_length)
>> {
>> char value[AUTH_STR_MAX_LEN];
>> iscsi_conn_t *conn = &session->conn[cid];
>>
>> if (session->type == ISCSI_SESSION_TYPE_DISCOVERY ||
>> !session->t->template->rdma) {
>> sprintf(value, "%d", conn->max_recv_dlength);
>> if (!iscsi_add_text(pdu, data, max_data_length,
>> "MaxRecvDataSegmentLength", value))
>> return 0;
>> } else {
>> sprintf(value, "%d", conn->max_recv_dlength);
>> if (!iscsi_add_text(pdu, data, max_data_length,
>> "InitiatorRecvDataSegmentLength",
>> value))
>> return 0;
>>
>> sprintf(value, "%d", conn->max_xmit_dlength);
>> if (!iscsi_add_text(pdu, data, max_data_length,
>> "TargetRecvDataSegmentLength",
>> value))
>> return 0;
>>
>> if (!iscsi_add_text(pdu, data, max_data_length,
>>"RDMAExtensions", "Yes"))
>> return 0;
>> }
>> return 1;
>> }
>
>
>
> Or.
--
You received this message because you are subscribed to the Google Groups
"open-iscsi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to open-iscsi+unsubscr...@googlegroups.com.
To post to this group, send email to open-iscsi@googlegroups.com.
Visit this group at http://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/groups/opt_out.
Re: do discovery through SW transports too
On 19/06/2013 00:47, Mike Christie wrote:
On 06/18/2013 10:35 AM, Or Gerlitz wrote:
Now, back to the initiator, Mike, is there a chance that the initiator
SENDS the key TargetRecvDataSegmentLength? this shouldn't be the case
according to the iser IETF spec.
See add_params_transport_specific() in login.c. Add some prints in there
to see what is set at that time and getting sent.
Hi Mike,
I see that in user space, session has type field, does this propagate
into the kernel? in other words, can the iser kernel module somehow
realize if the session being created is normal or discovery?if not, is
there an easy way to add that?
Looking on add_params_transport_specific, I see that it checks the
session type, but its only
called when the type is NORMAL... also, is there any reason for the
initiator to send the
TargetRecvDataSegmentLength key?
Or.
tatic int
add_params_transport_specific(iscsi_session_t *session, int cid,
struct iscsi_hdr *pdu, char *data,
int max_data_length)
{
char value[AUTH_STR_MAX_LEN];
iscsi_conn_t *conn = &session->conn[cid];
if (session->type == ISCSI_SESSION_TYPE_DISCOVERY ||
!session->t->template->rdma) {
sprintf(value, "%d", conn->max_recv_dlength);
if (!iscsi_add_text(pdu, data, max_data_length,
"MaxRecvDataSegmentLength", value))
return 0;
} else {
sprintf(value, "%d", conn->max_recv_dlength);
if (!iscsi_add_text(pdu, data, max_data_length,
"InitiatorRecvDataSegmentLength",
value))
return 0;
sprintf(value, "%d", conn->max_xmit_dlength);
if (!iscsi_add_text(pdu, data, max_data_length,
"TargetRecvDataSegmentLength",
value))
return 0;
if (!iscsi_add_text(pdu, data, max_data_length,
"RDMAExtensions", "Yes"))
return 0;
}
return 1;
}
Or.
--
You received this message because you are subscribed to the Google Groups
"open-iscsi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to open-iscsi+unsubscr...@googlegroups.com.
To post to this group, send email to open-iscsi@googlegroups.com.
Visit this group at http://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/groups/opt_out.
Re: do discovery through SW transports too
On 19/06/2013 04:32, Nicholas A. Bellinger wrote: So I'm pretty sure this is due to iscsi_target_parameters.c: iscsi_set_keys_irrelevant_for_discovery() currently clearing INITIATORRECVDATASEGMENTLENGTH and TARGETRECVDATASEGMENTLENGTH for all discovery scenarios.. As I'm still not yet able to force iser discovery to occur on the initiator side, can you give the following patch a shot on your setup..? --nab Nic, I see that this patch exists in the queue branch of your target-pending tree, so I tested with that branch and still faced problems. So what happens now is that the login of the discovery session works fine! But, the sending over the IB connection of the TEXT PDU containing Sendtargets=Allwhich is 16 byte long iscsiadm: in kstart_conn iscsiadm: in __kipc_call iscsiadm: in kwritev iscsiadm: in nlpayload_read iscsiadm: in nlpayload_read iscsiadm: sending text pdu with CmdSN 1, exp_statsn 1 iscsiadm: >SendTargets=All iscsiadm: in ksend_pdu_begin iscsiadm: send PDU began for hdr 48 bytes and data 16 bytes iscsiadm: in kwritev iscsiadm: wrote 48 bytes of PDU header iscsiadm: in kwritev iscsiadm: wrote 16 bytes of PDU data iscsiadm: in ksend_pdu_end iscsiadm: in __kipc_call iscsiadm: in kwritev iscsiadm: in nlpayload_read iscsiadm: in nlpayload_read iscsiadm: send PDU finished for conn 28:0 fails, that is the kernel iser driver gets TX completion with error IB_WC_REM_OP_ERR iser: iser_drain_tx_cq:tx id 88006facac98 status 11 vend_err 89 Is there a chance you don't post RX buffer which is large enough to hold these 48 + 16 bytes in case this is discovery and not normal session? -- You received this message because you are subscribed to the Google Groups "open-iscsi" group. To unsubscribe from this group and stop receiving emails from it, send an email to open-iscsi+unsubscr...@googlegroups.com. To post to this group, send email to open-iscsi@googlegroups.com. Visit this group at http://groups.google.com/group/open-iscsi. For more options, visit https://groups.google.com/groups/opt_out.
Re: [PATCH] LIBISCSI: Added new boot entries in the session sysfs
On 06/10/2013 01:34 PM, Eddie Wai wrote:
> index fe7f06c..f9cc89b 100644
> --- a/include/scsi/iscsi_if.h
> +++ b/include/scsi/iscsi_if.h
> @@ -487,6 +487,10 @@ enum iscsi_param {
> ISCSI_PARAM_TGT_RESET_TMO,
> ISCSI_PARAM_TARGET_ALIAS,
>
> + ISCSI_PARAM_BOOT_ROOT,
> + ISCSI_PARAM_BOOT_NIC,
> + ISCSI_PARAM_BOOT_TARGET,
> +
> ISCSI_PARAM_CHAP_IN_IDX,
> ISCSI_PARAM_CHAP_OUT_IDX,
> /* must always be last */
We cannot add in the middle because it would screw up older tools and
kernels. Just add adter the CHAP ones at the end.
Other than that patch looks ok.
--
You received this message because you are subscribed to the Google Groups
"open-iscsi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to open-iscsi+unsubscr...@googlegroups.com.
To post to this group, send email to open-iscsi@googlegroups.com.
Visit this group at http://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/groups/opt_out.
