On Sat, 18 Aug 2012 18:13:05 +1000 ronnie sahlberg <ronniesahlberg@xxxxxxxxx> wrote: > On Sat, Aug 18, 2012 at 6:06 PM, FUJITA Tomonori > <fujita.tomonori@xxxxxxxxxxxxx> wrote: >> On Sat, 18 Aug 2012 17:04:51 +0900 (JST) >> FUJITA Tomonori <fujita.tomonori@xxxxxxxxxxxxx> wrote: >> >>> On Sat, 18 Aug 2012 09:03:54 +1000 >>> Ronnie Sahlberg <ronniesahlberg@xxxxxxxxx> 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
