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 ea05be3ff043efd44256283d968fa1bb9a371568
"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
76a441ba0dc0071a19daeac456aa898889437efd) 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.
--
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 [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.
