Hi Tejas,
On Wed, 2014-02-12 at 11:44 +0530, Tejas Vaykole wrote:
> Hi ,
>
> I'm looking for help in understanding how LIO handles key=value pair
> during negotiation. The problem I'm experiencing now is that LIO seems to
> ignore sending back 'InitialR2T' key=value pair.
>
> For example, If am setting 'InitialR2T=Yes' using targetcli (output
> below) , and then trying to negotiate 'InitialR2T=No' .
> I am getting back the key=value pair (attachment pcap InitialR2T_No )
>
> -----targetcli ouput--------------
> /> cd iscsi/iqn.2003-01.org.linux-iscsi.root.x8664:sn.4ba6ed0d62e7/tpg1/
> /iscsi/iqn.20...ed0d62e7/tpg1> get parameter InitialR2T
> InitialR2T=Yes
> /iscsi/iqn.20...ed0d62e7/tpg1>
> ------------------------------------------
>
> However, if I am setting 'InitialR2T=Yes' using targetcli and then
> trying to negotiate 'InitialR2T=Yes'
> I am observing that LIO does *not* send back 'InitialR2T' key=value pair.
> (attachment pcap InitialR2T_Yes)
>
>
> As I understand, 'InitialR2T' is not a declarative key and therefore the
> target should respond with Key=value.
>
> Is my understanding correct? Am I looking at an error ? Please confirm.
>
No. The code in question is in iscsi_target_parameter.c, which sets an
optional reply bit based on proposed NO/YES values when the result
function is AND/OR respectively:
static void iscsi_check_proposer_for_optional_reply(struct iscsi_param *param)
{
if (IS_TYPE_BOOL_AND(param)) {
if (!strcmp(param->value, NO))
SET_PSTATE_REPLY_OPTIONAL(param);
} else if (IS_TYPE_BOOL_OR(param)) {
if (!strcmp(param->value, YES))
SET_PSTATE_REPLY_OPTIONAL(param);
/*
* Required for gPXE iSCSI boot client
*/
if (!strcmp(param->name, IMMEDIATEDATA))
SET_PSTATE_REPLY_OPTIONAL(param);
} else if (IS_TYPE_NUMBER(param)) {
if (!strcmp(param->name, MAXRECVDATASEGMENTLENGTH))
SET_PSTATE_REPLY_OPTIONAL(param);
/*
* The GlobalSAN iSCSI Initiator for MacOSX does
* not respond to MaxBurstLength, FirstBurstLength,
* DefaultTime2Wait or DefaultTime2Retain parameter keys.
* So, we set them to 'reply optional' here, and assume the
* the defaults from iscsi_parameters.h if the initiator
* is not RFC compliant and the keys are not negotiated.
*/
if (!strcmp(param->name, MAXBURSTLENGTH))
SET_PSTATE_REPLY_OPTIONAL(param);
if (!strcmp(param->name, FIRSTBURSTLENGTH))
SET_PSTATE_REPLY_OPTIONAL(param);
if (!strcmp(param->name, DEFAULTTIME2WAIT))
SET_PSTATE_REPLY_OPTIONAL(param);
if (!strcmp(param->name, DEFAULTTIME2RETAIN))
SET_PSTATE_REPLY_OPTIONAL(param);
/*
* Required for gPXE iSCSI boot client
*/
if (!strcmp(param->name, MAXCONNECTIONS))
SET_PSTATE_REPLY_OPTIONAL(param);
} else if (IS_PHASE_DECLARATIVE(param))
SET_PSTATE_REPLY_OPTIONAL(param);
}
So the two cases where Boolean AND + "No", and Boolean OR + "Yes" allow
for an optional response are defined in Section 5.2.2. Simple-value
Negotiations:
"In Boolean negotiations (i.e., those that result in keys taking the
values Yes or No), the accepting party MUST answer with the same key
and the result of the negotiation when the received value does not
determine that result by itself. The last value transmitted becomes
the negotiation result. The rules for selecting the value to answer
with are expressed as Boolean functions of the value received, and
the value that the accepting party would have selected if given a
choice.
Specifically, the two cases in which answers are OPTIONAL are:
- The Boolean function is "AND" and the value "No" is received.
The outcome of the negotiation is "No".
- The Boolean function is "OR" and the value "Yes" is received.
The outcome of the negotiation is "Yes".
Responses are REQUIRED in all other cases, and the value chosen and
sent by the acceptor becomes the outcome of the negotiation."
However, you'll notice some other special cases beyond these two Boolean
cases defined in Section 5.2.2 to set the optional reply bit as a
work-around for a few broken initiator implementations we've encountered
along the way..
These work-arounds have been in place for ~5 years at the point, and
thus far we've not run into any problems specific to these changes with
complaint initiators.
--nab
--
To unsubscribe from this list: send the line "unsubscribe target-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
