Hi Michal & Co, On Fri, 2018-01-19 at 19:33 +0000, Kalderon, Michal wrote: > ________________________________________ > From: Nicholas A. Bellinger <nab@xxxxxxxxxxxxxxx> > Sent: Thursday, January 18, 2018 11:58 AM > > > Hi Shiraz, Michal & Co, > Hi Nicholas, > > > Thanks for the feedback. Comments below. > > > A couple of thoughts. > > > First, would it be helpful to limit maximum payload size per I/O for > > consumers based on number of iser-target sq hw sges..? > > I don't think you need to limit the maximum payload, but instead > initialize the max_wr to be based on the number of supported SGEs > Instead of what is there today: > #define ISERT_QP_MAX_REQ_DTOS (ISCSI_DEF_XMIT_CMDS_MAX + \ > ISERT_MAX_TX_MISC_PDUS + \ > ISERT_MAX_RX_MISC_PDUS) > Add the maximum number of WQEs per command, > The calculation of number of WQEs per command needs to be something like > "MAX_TRANSFER_SIZE/(numSges*PAGE_SIZE)". > Makes sense, MAX_TRANSFER_SIZE would be defined globally by iser-target, right..? Btw, I'm not sure how this effects usage of ISER_MAX_TX_CQ_LEN + ISER_MAX_CQ_LEN, which currently depend on ISERT_QP_MAX_REQ_DTOS.. Sagi, what are your thoughts wrt changing attr.cap.max_send_wr at runtime vs. exposing a smaller max_data_sg_nents=32 for ib_devices with limited attr.cap.max_send_sge..? > For some devices like ours, breaking the IO into multiple WRs according to supported > number of SGEs doesn't necessarily means performance penalty. > AFAICT ading max_data_sg_nents for iser-target is safe enough work-around to include for stable, assuming we agree on what the max_send_sg cut-off is for setting max_data_sg_nents=32 usage from a larger default. I don't have a string preference either way, as long as it can be picked up for 4.x stable. Sagi, WDYT..? -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
