On 03/09/2016 07:55 AM, Christoph Hellwig wrote:
On Wed, Mar 09, 2016 at 02:07:23PM +0100, Christoph Hellwig wrote:
I think the multiple MR case here is simply broken, as we never hit
for the iSER or NVMe over Fabrics I/O sizes. I think the safest
is to simply not allow for it. I'll update the patch to disable the
loop, and add a helper for the driver to query the max I/O size
supported by the device.
Turns out if was easily fixable by doing a loop of sg_next() calls
until we reach the number of segments. Verified by hacking the
code to enable MRs for IB, and only accepting 4 pages per MR as arbitrarily
low limit.
Hello Christoph,
Regarding the iSERt patches that are present in your rdma-rw-api branch:
what is the impact of these patches on memory registration for the iSERt
driver in combination with an IB HCA? Is memory registration still
enabled for this combination? If not: how about changing this patch
series such that memory registration is performed either if the
transport protocol is iWARP or the ULP driver requests memory
registration explicitly, e.g. by setting a flag in struct rdma_rw_ctx
and/or struct ib_qp_init_attr?
Thanks,
Bart.
--
To unsubscribe from this list: send the line "unsubscribe target-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html