[stgt] [PATCH] ISCSI: Honour MaxRecvDataSegmentLength for NORMAL sessions

[FUJITA Tomonori]

On Sat, 18 Aug 2012 18:13:05 +1000
ronnie sahlberg <ronniesahlberg at gmail.com> wrote:

> On Sat, Aug 18, 2012 at 6:06 PM, FUJITA Tomonori
> <fujita.tomonori at lab.ntt.co.jp> wrote:
>> On Sat, 18 Aug 2012 17:04:51 +0900 (JST)
>> FUJITA Tomonori <fujita.tomonori at lab.ntt.co.jp> wrote:
>>
>>> On Sat, 18 Aug 2012 09:03:54 +1000
>>> Ronnie Sahlberg <ronniesahlberg at gmail.com> wrote:
>>>
>>>> Fix a bug in iscsid.c with regards to MaxRecvDataSegmentLength.
>>>> The parsing of this login key only updated the settings for how large PDUs we can send for DISCOVERY sessions.
>>>
>>> Really? I thought that we call param_set_val() for
>>> ISCSI_PARAM_MAX_XMIT_DLENGTH in SESSION_NORMAL. If you configure
>>> ISCSI_PARAM_MAX_XMIT_DLENGTH, tgtd honors MaxRecvDataSegmentLength
>>> that an initiator sends?
>>>
>>> tgtadm --op show --mode target --tid 1 MaxRecvDataSegmentLength=8192
>>
>> Oops, this should be something like:
>>
>> tgtadm --op update --mode target --tid 1 --name MaxXmitDataSegmentLength --value 16384
> 
> Why set it manually from the tgtadm command line?
> The initiator already told tgtd what the size is, so only thing
> required is to fix the bug to make the target honour what the
> initiator aleady sent to the target.

Yeah, but tgtd still needs to check if the value that an initiator
told is acceptable from the iscsi spec (512 - 2^24 -1).

I agree that we had better to improve the current code. Setting
MaxXmitDataSegmentLength by hand is not a good idea.


> It is a trivial patch for a trivial bug that has massive performance
> hit on sequential or big i/o workloads.

--
To unsubscribe from this list: send the line "unsubscribe stgt" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html