Re: [PATCH 0/5] Indirect memory registration feature

[Christoph Hellwig <hch-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>]

On Tue, Jun 09, 2015 at 11:44:16AM +0300, Sagi Grimberg wrote:
> For example:
> - frwr requires a queue-pair for the post (and it must be the ULP
>   queue-pair to ensure the registration is done before the data-transfer
>   begins). While fmrs does not need the queue-pair.

How do you transfer data without a queue pair?

> - the ULP would probably always initiate data transfer after the
>   registration (send a request or do the rdma r/w). It is useful to
>   link the frwr post with the next wr in a single post_send call.
>   I wander how would an API allow such a thing (while other registration
>   methods don't use work request interface).
> 
> - There is the fmr_pool API which tries to tackle the disadvantages of
>   fmrs (very slow unmap) by delaying the fmr unmap until some dirty
>   watermark of remapping is met. I'm not sure how this can be done.
> 
> - How would the API choose the method to register memory?

Seems like the general preference in existing users is FRWR -> FMR -> FR
with an exception to use physical for single segment I/O requests.

> - If there is an alignment issue, do we fail? do we bounce?

Leave it to the high level driver for now.  NFS can simply split
requests when the offset mismatches for blok drivers the enhanced
SG_GAPS can take care of it.  If indirect is supported the driver
does not need to set SG_GAPS.
registrations tha

> - There is the whole T10-DIF support...

Just tell the driver if the registration model supports it.  Do the
indirect registrations support it, btw?

As far as I can tell the NFS abstraction fits SRP fairly well.  iSER
is a bit of a mess with it's bounce buffering so I'm not too sure about
that one.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html