On 1/22/2015 1:10 AM, Mike Christie wrote:
On 01/21/2015 03:14 PM, Or Gerlitz wrote:
On Wed, Jan 21, 2015 at 8:41 PM, Mike Christie <micha...@cs.wisc.edu
<mailto:micha...@cs.wisc.edu>> wrote:

     On 1/21/15, 8:19 AM, Or Gerlitz wrote:

         Hi Mike,

         Long time.. hope you are all well after EOY holidays and with
         energy to
         for the MCS debates @ LSF...


     Hey,

     Hope you are doing well too.

         So back in upstream commit
         ea05be3ff043efd44256283d968fa1__bb9a371568
         "iscsi tools: set non negotiated params early" we are
         doing set_param towards the kernel/transport before sending the
         login
         request.

         Running with latest upstream (commit
         76a441ba0dc0071a19daeac456aa89__8889437efd) we did dump of all
         set_params
         done towards iser and I see that Max Recv DSL and friends are
         set after
         sending the login, in both discovery and normal sessions (see
         below), is
         that a bug? aren't they declarative?


     Most of them being set are not declarative.

     If we have ImmediateData=yes, but the target has ImmediateData=No,
     then we end up turning off ImmediateData. MaxBurstLength uses the
     min of what each side can support.

     Is the only one currently being set at that time that is declarative
     MRDSL (TPGT we will not count because we can sometimes get a
     different TGPT than what discovery told us). The thing about MRDSL
     is that we have our own MaxXmitDataSegmentLength setting. It is not
     a iscsi RFC setting. It is just a initiator side limit that we take
     into account when setting the final MRDSL. See
     usr/login.c:get_op_params___text_keys().

     Do you need the values earlier? Is it just MRSDL? We can pass that
     earlier, but then if we find out it is larger than
     MaxRecvDataSegmentLength we can update the value by calling set
     param again. We could also just turn that off for iser if it causes
     problems.


What we need in iser is an early (== between bind and sending login) set
param call to tell us the MRSDL for the initiator which is to be assumed
by the target side. We need not worry if the value advertized before the
login nego is larger vs. the max DSL which is going to be used by the
  target. We need all that when running discovery over iser but if it
makes things simpler, we can have it for Normal sessions too. Any chance
you can suggest quick user-space patch or you want us to dig there...

It sounds like you just need something like the attached patch. Let me
know if I am misunderstanding you.



Mike, with your patch the user-space --> transport setting of MRDSL is done before sending the login request (but also again after getting the login response), see below.

However, I am not clear why in my setup I get 8192 where iscsi.conf I have

node.conn[0].iscsi.MaxRecvDataSegmentLength = 262144

and later

discovery.sendtargets.iscsi.MaxRecvDataSegmentLength = 32768

where none of them is 8192 ... is this possible that we send 32768 in the SendTargets payload but program 8K to the transport?

Running iscsid with debug open (-d 15), for discovery sessions I don't have login/TEXT dumps such as the below which is seen for Normal sessions, any chance you can come up with another quick patch that adds these dumps? I will also be able to run ibdump next week and feed the output into iser capable wire-shark, but for the time being such a patch will be helpful.

iscsid: sending login PDU with current stage 1, next stage 3, transit 0x80, isid 0x00023d100000 exp_statsn 0
iscsid: >    InitiatorName=iqn.1994-05.com.redhat:afa6a392a57a
iscsid: >    InitiatorAlias=r-dcs54
iscsid: >    TargetName=iqn.2001-04.com.r-dcs53-tgt-2
iscsid: >    SessionType=Normal
iscsid: >    DefaultTime2Wait=2
iscsid: >    DefaultTime2Retain=0
iscsid: >    IFMarker=No
iscsid: >    OFMarker=No
iscsid: >    ErrorRecoveryLevel=0
iscsid: >    InitialR2T=No
iscsid: >    ImmediateData=Yes
iscsid: >    MaxBurstLength=16776192
iscsid: >    FirstBurstLength=262144
iscsid: >    MaxOutstandingR2T=1
[...]



iser: iscsi_iser_conn_bind: binding iscsi conn ffff880207a6b4a8 to iser_conn [...]
iser: iscsi_iser_set_param: set param 18 value 0
iser: iscsi_iser_set_param: set param 26 value 0
iser: iscsi_iser_set_param: set param 27 value 0
iser: iscsi_iser_set_param: set param 28 value 0
iser: iscsi_iser_set_param: set param 35 value 0
iser: iscsi_iser_set_param: set param 30 value 0
iser: iscsi_iser_set_param: set param 31 value 0
iser: iscsi_iser_set_param: set param 32 value iser
iser: iscsi_iser_set_param: set param 34 value iqn.1994-05.com.redhat:afa6a392a57a
iser: iscsi_iser_set_param: set param 43 value 1
iser: iscsi_iser_set_param: set param 0 value 8192
iser: iscsi_iser_mtask_xmit: mtask xmit [cid 0 itt 0x0]
iser: iser_send_control: op 43 dsl f4, posting login rx buffer
iser: iser_post_rx_bufs: req op 43 flags 87
iser: iser_post_rx_bufs: Discovery session, re-using login RX buffer
iser: iser_cq_tasklet_fn: got 1 completions
iser: iser_rcv_completion: op 0x23 itt 0x0 dlen 142
iser: iser_cq_tasklet_fn: got 1 completions
iser: iscsi_iser_set_param: set param 0 value 8192
iser: iscsi_iser_set_param: set param 1 value 8192
iser: iscsi_iser_set_param: set param 4 value 0
iser: iscsi_iser_set_param: set param 5 value 1
iser: iscsi_iser_set_param: set param 6 value 1
iser: iscsi_iser_set_param: set param 7 value 262144
iser: iscsi_iser_set_param: set param 8 value 16776192
iser: iscsi_iser_set_param: set param 9 value 0
iser: iscsi_iser_set_param: set param 10 value 0
iser: iscsi_iser_set_param: set param 11 value 0
iser: iscsi_iser_set_param: set param 14 value 1
iser: iscsi_iser_set_param: set param 16 value 1
iser: iscsi_iser_mtask_xmit: mtask xmit [cid 0 itt 0x0]




--
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/d/optout.

Reply via email to