On 1/22/2015 3:53 PM, 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 <[email protected]
<mailto:[email protected]>> 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?
I think it's because in a discovery session the default (8192) MRDL is
used. I patched user-space to pass MRDL as non-negotiable and I get 8192
as well (just it was before conn_bind).
But I don't think passing it before is necessary. Reusing the login
buffer was our decision. We could have equally allocate a dedicated
buffer at sendtargets text execution time, pre-post it and release
it once we get the response (given we are in a discovery session of
course).
Thoughts?
I'm adding Nic to the discussion given that my tests against LIO showed
that sendtargets text response is broken for an amount of targets that
exceeds MRDL (both in iscsi and iser). First, LIO does not respect MRDL
for sendtargets response, and also there is no support for
multi-sequence text negotiation.
I patched LIO as well to get it working, but I (ab)used hdr->ttt to
indicate where the text response ended for the next empty
text request (was easier than keeping the command alive). I think
that a proper fix should store the end of the ST response under the
session.
Nic, it will be nice to solve this. Perhaps we can just limit the multi
sequence text support for sendtargets in discovery sessions (by
assuming that an empty text is a continuation of an incomplete
sendtargets response).
Sagi.
--
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.
