From: Santosh Shilimkar <santosh.shilimkar@oracle.com>
To: Jason Gunthorpe <jgg@ziepe.ca>
Cc: netdev@vger.kernel.org, davem@davemloft.net,
Hans Westgaard Ry <hans.westgaard.ry@oracle.com>
Subject: Re: [net-next][PATCH v2 1/2] rds: handle unsupported rdma request to fs dax memory
Date: Fri, 10 May 2019 12:38:31 -0700 [thread overview]
Message-ID: <2c16b35d-c20c-e51d-5d4e-0904c740a4ec@oracle.com> (raw)
In-Reply-To: <20190510192046.GH13038@ziepe.ca>
On 5/10/2019 12:20 PM, Jason Gunthorpe wrote:
> On Fri, May 10, 2019 at 11:58:42AM -0700, santosh.shilimkar@oracle.com wrote:
>> On 5/10/19 11:07 AM, Jason Gunthorpe wrote:
>>> On Fri, May 10, 2019 at 11:02:35AM -0700, santosh.shilimkar@oracle.com wrote:
[...]
>>> Why would you need to detect FS DAX memory? GUP users are not supposed
>>> to care.
>>>
>>> GUP is supposed to work just 'fine' - other than the usual bugs we
>>> have with GUP and any FS backed memory.
>>>
>> Am not saying there is any issue with GUP. Let me try to explain the
>> issue first. You are aware of various discussions about doing DMA
>> or RDMA on FS DAX memory. e.g [1] [2] [3]
>>
>> One of the proposal to do safely RDMA on FS DAX memory is/was ODP
>
> It is not about safety. ODP is required in all places that would have
> used gup_longterm because ODP avoids th gup_longterm entirely.
>
>> Currently RDS doesn't have support for ODP MR registration
>> and hence we don't want user application to do RDMA using
>> fastreg/fmr on FS DAX memory which isn't safe.
>
> No, it is safe.
>
> The only issue is you need to determine if this use of GUP is longterm
> or short term. Longterm means userspace is in control of how long the
> GUP lasts, short term means the kernel is in control.
>
> ie posting a fastreg, sending the data, then un-GUP'ing on completion
> is a short term GUP and it is fine on any type of memory.
>
> So if it is a long term pin then it needs to be corrected and the only
> thing the comment needs to explain is that it is a long term pin.
>
Thanks for clarification. At least the distinction is clear to me now.
Yes the key can be valid for long term till the remote RDMA IO is issued
and finished. After that user can issue an invalidate/free key or
upfront specify a flag to free/invalidate the key on remote IO
completion.
Will update the commit message accordingly. Can you please also
comment on question on 2/2 ?
regards,
Santosh
next prev parent reply other threads:[~2019-05-10 19:36 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-29 23:37 [net-next][PATCH v2 0/2] rds: handle unsupported rdma request to fs dax memory Santosh Shilimkar
2019-04-29 23:37 ` [net-next][PATCH v2 1/2] " Santosh Shilimkar
2019-05-01 7:44 ` Leon Romanovsky
2019-05-01 17:54 ` Santosh Shilimkar
2019-05-02 6:21 ` Leon Romanovsky
2019-05-02 17:52 ` Santosh Shilimkar
2019-05-05 6:28 ` Leon Romanovsky
2019-05-06 16:39 ` Santosh Shilimkar
2019-05-10 12:54 ` Jason Gunthorpe
2019-05-10 16:11 ` Santosh Shilimkar
2019-05-10 17:55 ` Jason Gunthorpe
2019-05-10 18:02 ` santosh.shilimkar
2019-05-10 18:07 ` Jason Gunthorpe
2019-05-10 18:58 ` santosh.shilimkar
2019-05-10 19:20 ` Jason Gunthorpe
2019-05-10 19:38 ` Santosh Shilimkar [this message]
2019-05-10 19:47 ` Jason Gunthorpe
2019-05-10 20:12 ` Santosh Shilimkar
2019-05-10 20:39 ` Jason Gunthorpe
2019-04-29 23:37 ` [net-next][PATCH v2 2/2] rds: add sysctl for rds support of On-Demand-Paging Santosh Shilimkar
2019-05-01 7:45 ` Leon Romanovsky
2019-05-01 17:54 ` Santosh Shilimkar
2019-05-02 6:18 ` Leon Romanovsky
2019-05-02 17:59 ` Santosh Shilimkar
2019-05-05 6:22 ` Leon Romanovsky
2019-05-06 16:37 ` Santosh Shilimkar
2019-05-10 13:02 ` Jason Gunthorpe
2019-05-10 16:13 ` Santosh Shilimkar
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=2c16b35d-c20c-e51d-5d4e-0904c740a4ec@oracle.com \
--to=santosh.shilimkar@oracle.com \
--cc=davem@davemloft.net \
--cc=hans.westgaard.ry@oracle.com \
--cc=jgg@ziepe.ca \
--cc=netdev@vger.kernel.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;
as well as URLs for NNTP newsgroup(s).