public inbox for linux-rdma@vger.kernel.org
 help / color / mirror / Atom feed
From: Tom Talpey <tom-CLs1Zie5N5HQT0dZR+AlfA@public.gmane.org>
To: Alex Margolin <alexma-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>,
	"linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
	<linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Subject: Re: [RFC] Registering non-contiguous memory
Date: Tue, 28 Feb 2017 07:31:04 -0500	[thread overview]
Message-ID: <f40f326d-e76b-0471-dc7d-e81b7d07db78@talpey.com> (raw)
In-Reply-To: <VI1PR05MB127817A311C332553E4391AFB9410-79XLn2atqDMOK6E67s+DINqRiQSDpxhJvxpqHgZTriW3zl9H0oFU5g@public.gmane.org>

On 2/5/2017 11:46 AM, Alex Margolin wrote:
> Introduction
> --------------------------------------------------------------------------------
> Numerous applications communicate buffers with a non-contiguous memory layout.
> For example, HPC applications often work on a matrix, and require sending a row or a column. Sending non-contiguous data requires specifying all the buffers being transferred, along with potentially the same amount of memory keys (should the buffers be registered under different memory regions). Extended memory windows are proposed to address complex memory layouts, and allow the user to send and receive them in an efficient manner.
> This RFC proposes an extension for memory windows for the use of non-contiguous buffers.
>
...
> The layout is "switched on" as a bind parameter with an additional access flag, which is somewhat of a misuse, but since struct ibv_mw_bind_info is not easily expandable in the functions using it, the alternative is an additional verb.
>
> We do propose adding a verb for the allocation of such memory windows, which is required since the original memory window allocation function is not easily extendable, and we require an additional parameter to determine the amount of resources to allocate towards it (descriptors). In addition, this number is available for existing windows, in order to determine how to set this for a composite of two existing windows, or to keep track of resource use for it.
>
> Finally, we add the option to obtain a local memory key for memory windows, aside from the currently available remote key. This can be specified in an SGE to send data out of a memory layout. This key will only be valid if local access is requested in the access flags.

How does the application detect whether the adapter supports this new
verb? I don't see an attribute or other bit exposing it above the API.

Also, what applications are likely to use it? It is my understanding
that relatively few applications use Memory Windows-style registration
today. Roughly what performance benefit do you expect they will achieve
from the region descriptor format overall, motivating them to change?

Tom.
--
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

  parent reply	other threads:[~2017-02-28 12:31 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-05 16:46 [RFC] Registering non-contiguous memory Alex Margolin
     [not found] ` <VI1PR05MB127817A311C332553E4391AFB9410-79XLn2atqDMOK6E67s+DINqRiQSDpxhJvxpqHgZTriW3zl9H0oFU5g@public.gmane.org>
2017-02-05 22:44   ` Jason Gunthorpe
     [not found]     ` <20170205224401.GB26474-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
2017-03-23 18:21       ` Alex Margolin
     [not found]         ` <DB5PR05MB12702D1DE9A7E7773FF823ACB93F0-8IvNv+8VlcCeKfjjHlISstqRiQSDpxhJvxpqHgZTriW3zl9H0oFU5g@public.gmane.org>
2017-03-23 18:40           ` Jason Gunthorpe
2017-02-28 12:31   ` Tom Talpey [this message]
     [not found]     ` <f40f326d-e76b-0471-dc7d-e81b7d07db78-CLs1Zie5N5HQT0dZR+AlfA@public.gmane.org>
2017-03-16 13:32       ` Alex Margolin
2017-11-01 11:11   ` Alex Margolin
     [not found]     ` <DB5PR05MB1270529922F451A2CACF7AE9B95F0-8IvNv+8VlcCeKfjjHlISstqRiQSDpxhJvxpqHgZTriW3zl9H0oFU5g@public.gmane.org>
2017-11-01 16:56       ` Jason Gunthorpe
     [not found]         ` <20171101165625.GE1030-uk2M96/98Pc@public.gmane.org>
2017-11-02  5:09           ` Leon Romanovsky
     [not found]             ` <20171102050942.GU16127-U/DQcQFIOTAAJjI8aNfphQ@public.gmane.org>
2017-11-02 16:12               ` Jason Gunthorpe
     [not found]                 ` <20171102161222.GH18874-uk2M96/98Pc@public.gmane.org>
2017-11-02 16:31                   ` Leon Romanovsky
     [not found]                     ` <20171102163125.GZ16127-U/DQcQFIOTAAJjI8aNfphQ@public.gmane.org>
2017-11-02 16:42                       ` Jason Gunthorpe

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=f40f326d-e76b-0471-dc7d-e81b7d07db78@talpey.com \
    --to=tom-cls1zie5n5hqt0dzr+alfa@public.gmane.org \
    --cc=alexma-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org \
    --cc=linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox