On Wed, Jan 21, 2015 at 8:41 PM, Mike Christie <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 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. > > 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... Or. -- 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.
