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
On 1/21/15, 8:19 AM, Or Gerlitz wrote:
Long time.. hope you are all well after EOY holidays and with
for the MCS debates @ LSF...
Hope you are doing well too.
So back in upstream commit
"iscsi tools: set non negotiated params early" we are
doing set_param towards the kernel/transport before sending the
Running with latest upstream (commit
76a441ba0dc0071a19daeac456aa89__8889437efd) we did dump of all
done towards iser and I see that Max Recv DSL and friends are
sending the login, in both discovery and normal sessions (see
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
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
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
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
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.iscsi.MaxRecvDataSegmentLength = 262144
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
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
To unsubscribe from this group and stop receiving emails from it, send an email
To post to this group, send email to firstname.lastname@example.org.
Visit this group at http://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.