On Wed, Oct 28, 2009 at 1:14 PM, Bart Van Assche <bart.vanass...@gmail.com> wrote: > On Wed, Oct 28, 2009 at 7:47 PM, Chris Worley <worl...@gmail.com> wrote: >> It appears that SRP tries to coalesce and fragment initiator I/O >> requests into 64KB packets, as that looks to be the size requested >> to/from the device on the target side (and the I/O scheduler is >> disabled on the target). >> >> Is there a way to control this, where no coalescing occurs when >> latency is an issue and requests are small, and no fragmentation >> occurs when requests are large? >> >> Or, am I totally wrong in my assumption that SRP is coalescing/fragmenting >> data? > > Regarding avoiding coalescing of I/O requests: which I/O scheduler is > being used on the initiator system and how has it been configured via > sysfs ?
There is no scheduler running on either target or initiator on the drives in question (sorry I worded that incorrectly initially), or so I've been told (this information is second-hand). I did see iostat output from the initiator in his case, where there were long waits and service times that I'm guessing was due to some coalescing/merging. There was also a hint in the iostat output that a scheduler was enabled, as there were non-zero values (occasionally) under the [rw]qm/s columns, which, if I understand iostat correctly, means there is a scheduler merging results. So you're saying there is no hold-off for merging on the initiator side of the IB/SRP stack? > > Adjusting the constant MAX_RDMA_SIZE in scst/srpt/src/ib_srpt.h might > help to avoid fragmentation of large requests by the SRP protocol. > Please post a follow-up message to the mailing list with your findings > such that MAX_RDMA_SIZE can be converted from a compile-time constant > to a sysfs variable if this would be useful. Will do. Thanks, Chris > > Bart. > -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
