On 1/22/15, 7:53 AM, Or Gerlitz wrote:
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.

Yeah, I thought you said that was ok. The first time is the initial value. The second time would be the negotiated value I described in the first mail.


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


The kernel libiscsi.c preallocates the login request buffer at 8K (default MRSDL from RFC) to avoid memory allocations during relogin. That buffer is then reused for discovery PDUs like TEXT ones since we never implemented support for dynamic buffer allocation.



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 am almost done with the first cut of mq support that I can pass on to Sagi to get him started on iser support. Hope to post Fri or Sat.

I do not know off the top of my head a solution for this issue, but can look into over the weekend after I post the mq stuff.

--
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