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. It is a trivial patch for a trivial bug that has massive performance hit on sequential or big i/o workloads. ronnie s -- 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
