All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
To: Jason Gunthorpe
	<jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
Cc: Roland Dreier <roland-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
	"Michael R. Hines"
	<mrhines-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>,
	Sean Hefty <sean.hefty-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>,
	Hal Rosenstock
	<hal.rosenstock-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
	Yishai Hadas <yishaih-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>,
	Christoph Lameter <cl-vYTEC60ixJUAvxtiuMwx3w@public.gmane.org>,
	"linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
	<linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	LKML <linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	qemu-devel-qX2TKyscuCcdnm+yROfE0A@public.gmane.org
Subject: Re: [PATCH] rdma: don't make pages writeable if not requiested
Date: Thu, 21 Mar 2013 20:16:33 +0200	[thread overview]
Message-ID: <20130321181633.GC4366@redhat.com> (raw)
In-Reply-To: <20130321171115.GA653-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>

On Thu, Mar 21, 2013 at 11:11:15AM -0600, Jason Gunthorpe wrote:
> On Thu, Mar 21, 2013 at 11:39:47AM +0200, Michael S. Tsirkin wrote:
> > On Thu, Mar 21, 2013 at 02:13:38AM -0700, Roland Dreier wrote:
> > > On Thu, Mar 21, 2013 at 1:51 AM, Michael S. Tsirkin <mst-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
> > > >> In that case, no, I don't see any reason for LOCAL_WRITE, since the
> > > >> only RDMA operations that will access this memory are remote reads.
> > > >
> > > > What is the meaning of LOCAL_WRITE then? There are no local
> > > > RDMA writes as far as I can see.
> > > 
> > > Umm, it means you're giving the local adapter permission to write to
> > > that memory.  So you can use it as a receive buffer or as the target
> > > for remote data from an RDMA read operation.
> > 
> > Well RDMA read has it's own flag, IB_ACCESS_REMOTE_READ.
> > I don't see why do you need to give adapter permission
> 
> The access flags have to do with what independent access remote nodes
> get. There are four major cases:
> 
> access = IBV_ACCESS_REMOTE_READ says the adaptor will let remote nodes
> read the memory.
> 
> access = 0 (ie IBV_ACCESS_LOCAL_READ) says that only the adaptor, under
> the direct control of the application, can read this memory. Remote
> nodes are barred.
> 
> access = IBV_ACCESS_REMOTE_WRITE|IBV_ACCESS_LOCAL_WRITE says the adaptor
> will let remote nodes write the memory
> 
> access = IBV_ACCESS_LOCAL_WRITE bars remote nodes from writing to that
> memory. Only the adaptor, under the direct control of the application,
> can write the memory.

This is the one I find redundant. Since the write will be done
by the adaptor under direct control by the application,
why does it make sense to declare this beforehand?
If you don't want to allow local write access to memory,
just do not post any receive WRs with this address.
If you posted and regret it, reset the QP to cancel.

But IB spec specified LOCAL_WRITE in this redundant way so I guess
applications expect it to have the semantics defined there, I just
didn't remember what they are.

No way around it then, need another flag.
--
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

WARNING: multiple messages have this Message-ID (diff)
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
Cc: Roland Dreier <roland@kernel.org>,
	"Michael R. Hines" <mrhines@linux.vnet.ibm.com>,
	Sean Hefty <sean.hefty@intel.com>,
	Hal Rosenstock <hal.rosenstock@gmail.com>,
	Yishai Hadas <yishaih@mellanox.com>,
	Christoph Lameter <cl@linux.com>,
	"linux-rdma@vger.kernel.org" <linux-rdma@vger.kernel.org>,
	LKML <linux-kernel@vger.kernel.org>,
	qemu-devel@nongnu.org
Subject: Re: [PATCH] rdma: don't make pages writeable if not requiested
Date: Thu, 21 Mar 2013 20:16:33 +0200	[thread overview]
Message-ID: <20130321181633.GC4366@redhat.com> (raw)
In-Reply-To: <20130321171115.GA653@obsidianresearch.com>

On Thu, Mar 21, 2013 at 11:11:15AM -0600, Jason Gunthorpe wrote:
> On Thu, Mar 21, 2013 at 11:39:47AM +0200, Michael S. Tsirkin wrote:
> > On Thu, Mar 21, 2013 at 02:13:38AM -0700, Roland Dreier wrote:
> > > On Thu, Mar 21, 2013 at 1:51 AM, Michael S. Tsirkin <mst@redhat.com> wrote:
> > > >> In that case, no, I don't see any reason for LOCAL_WRITE, since the
> > > >> only RDMA operations that will access this memory are remote reads.
> > > >
> > > > What is the meaning of LOCAL_WRITE then? There are no local
> > > > RDMA writes as far as I can see.
> > > 
> > > Umm, it means you're giving the local adapter permission to write to
> > > that memory.  So you can use it as a receive buffer or as the target
> > > for remote data from an RDMA read operation.
> > 
> > Well RDMA read has it's own flag, IB_ACCESS_REMOTE_READ.
> > I don't see why do you need to give adapter permission
> 
> The access flags have to do with what independent access remote nodes
> get. There are four major cases:
> 
> access = IBV_ACCESS_REMOTE_READ says the adaptor will let remote nodes
> read the memory.
> 
> access = 0 (ie IBV_ACCESS_LOCAL_READ) says that only the adaptor, under
> the direct control of the application, can read this memory. Remote
> nodes are barred.
> 
> access = IBV_ACCESS_REMOTE_WRITE|IBV_ACCESS_LOCAL_WRITE says the adaptor
> will let remote nodes write the memory
> 
> access = IBV_ACCESS_LOCAL_WRITE bars remote nodes from writing to that
> memory. Only the adaptor, under the direct control of the application,
> can write the memory.

This is the one I find redundant. Since the write will be done
by the adaptor under direct control by the application,
why does it make sense to declare this beforehand?
If you don't want to allow local write access to memory,
just do not post any receive WRs with this address.
If you posted and regret it, reset the QP to cancel.

But IB spec specified LOCAL_WRITE in this redundant way so I guess
applications expect it to have the semantics defined there, I just
didn't remember what they are.

No way around it then, need another flag.

WARNING: multiple messages have this Message-ID (diff)
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
Cc: Roland Dreier <roland@kernel.org>,
	qemu-devel@nongnu.org,
	"linux-rdma@vger.kernel.org" <linux-rdma@vger.kernel.org>,
	Yishai Hadas <yishaih@mellanox.com>,
	LKML <linux-kernel@vger.kernel.org>,
	"Michael R. Hines" <mrhines@linux.vnet.ibm.com>,
	Hal Rosenstock <hal.rosenstock@gmail.com>,
	Sean Hefty <sean.hefty@intel.com>,
	Christoph Lameter <cl@linux.com>
Subject: Re: [Qemu-devel] [PATCH] rdma: don't make pages writeable if not requiested
Date: Thu, 21 Mar 2013 20:16:33 +0200	[thread overview]
Message-ID: <20130321181633.GC4366@redhat.com> (raw)
In-Reply-To: <20130321171115.GA653@obsidianresearch.com>

On Thu, Mar 21, 2013 at 11:11:15AM -0600, Jason Gunthorpe wrote:
> On Thu, Mar 21, 2013 at 11:39:47AM +0200, Michael S. Tsirkin wrote:
> > On Thu, Mar 21, 2013 at 02:13:38AM -0700, Roland Dreier wrote:
> > > On Thu, Mar 21, 2013 at 1:51 AM, Michael S. Tsirkin <mst@redhat.com> wrote:
> > > >> In that case, no, I don't see any reason for LOCAL_WRITE, since the
> > > >> only RDMA operations that will access this memory are remote reads.
> > > >
> > > > What is the meaning of LOCAL_WRITE then? There are no local
> > > > RDMA writes as far as I can see.
> > > 
> > > Umm, it means you're giving the local adapter permission to write to
> > > that memory.  So you can use it as a receive buffer or as the target
> > > for remote data from an RDMA read operation.
> > 
> > Well RDMA read has it's own flag, IB_ACCESS_REMOTE_READ.
> > I don't see why do you need to give adapter permission
> 
> The access flags have to do with what independent access remote nodes
> get. There are four major cases:
> 
> access = IBV_ACCESS_REMOTE_READ says the adaptor will let remote nodes
> read the memory.
> 
> access = 0 (ie IBV_ACCESS_LOCAL_READ) says that only the adaptor, under
> the direct control of the application, can read this memory. Remote
> nodes are barred.
> 
> access = IBV_ACCESS_REMOTE_WRITE|IBV_ACCESS_LOCAL_WRITE says the adaptor
> will let remote nodes write the memory
> 
> access = IBV_ACCESS_LOCAL_WRITE bars remote nodes from writing to that
> memory. Only the adaptor, under the direct control of the application,
> can write the memory.

This is the one I find redundant. Since the write will be done
by the adaptor under direct control by the application,
why does it make sense to declare this beforehand?
If you don't want to allow local write access to memory,
just do not post any receive WRs with this address.
If you posted and regret it, reset the QP to cancel.

But IB spec specified LOCAL_WRITE in this redundant way so I guess
applications expect it to have the semantics defined there, I just
didn't remember what they are.

No way around it then, need another flag.

  parent reply	other threads:[~2013-03-21 18:16 UTC|newest]

Thread overview: 62+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-03-21  6:18 [PATCH] rdma: don't make pages writeable if not requiested Michael S. Tsirkin
2013-03-21  6:18 ` [Qemu-devel] " Michael S. Tsirkin
2013-03-21  6:18 ` Michael S. Tsirkin
     [not found] ` <20130321061838.GA28319-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2013-03-21  6:55   ` Roland Dreier
2013-03-21  6:55     ` [Qemu-devel] " Roland Dreier
2013-03-21  6:55     ` Roland Dreier
     [not found]     ` <CAL1RGDUcMj9QVsuQgK+ozw64L6-cGehL7YBUJ1_ckni6TD=Kcg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2013-03-21  7:03       ` Michael S. Tsirkin
2013-03-21  7:03         ` [Qemu-devel] " Michael S. Tsirkin
2013-03-21  7:03         ` Michael S. Tsirkin
     [not found]         ` <20130321070357.GD28328-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2013-03-21  7:15           ` Roland Dreier
2013-03-21  7:15             ` [Qemu-devel] " Roland Dreier
2013-03-21  7:15             ` Roland Dreier
     [not found]             ` <CAG4TOxPkhOhGmzeA1K4a0Zw8HxS-QkOr-PCx7mJgA+KkuH3ZiQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2013-03-21  8:51               ` Michael S. Tsirkin
2013-03-21  8:51                 ` [Qemu-devel] " Michael S. Tsirkin
2013-03-21  8:51                 ` Michael S. Tsirkin
     [not found]                 ` <20130321085107.GE28328-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2013-03-21  9:13                   ` Roland Dreier
2013-03-21  9:13                     ` [Qemu-devel] " Roland Dreier
2013-03-21  9:13                     ` Roland Dreier
     [not found]                     ` <CAL1RGDVnkLZU2Vge4o3BwDxnAfGv7TQRMqE6ha3MUt39CVp5NQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2013-03-21  9:39                       ` Michael S. Tsirkin
2013-03-21  9:39                         ` [Qemu-devel] " Michael S. Tsirkin
2013-03-21  9:39                         ` Michael S. Tsirkin
     [not found]                         ` <20130321093946.GG28328-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2013-03-21 17:11                           ` Jason Gunthorpe
2013-03-21 17:11                             ` [Qemu-devel] " Jason Gunthorpe
2013-03-21 17:11                             ` Jason Gunthorpe
     [not found]                             ` <20130321171115.GA653-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
2013-03-21 17:15                               ` Michael S. Tsirkin
2013-03-21 17:15                                 ` [Qemu-devel] " Michael S. Tsirkin
2013-03-21 17:15                                 ` Michael S. Tsirkin
     [not found]                                 ` <20130321171525.GE2994-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2013-03-21 17:21                                   ` Jason Gunthorpe
2013-03-21 17:21                                     ` [Qemu-devel] " Jason Gunthorpe
2013-03-21 17:21                                     ` Jason Gunthorpe
     [not found]                                     ` <20130321172150.GA3118-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
2013-03-21 17:42                                       ` Michael S. Tsirkin
2013-03-21 17:42                                         ` [Qemu-devel] " Michael S. Tsirkin
2013-03-21 17:42                                         ` Michael S. Tsirkin
     [not found]                                         ` <20130321174237.GA4060-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2013-03-21 17:57                                           ` Jason Gunthorpe
2013-03-21 17:57                                             ` [Qemu-devel] " Jason Gunthorpe
2013-03-21 17:57                                             ` Jason Gunthorpe
     [not found]                                             ` <20130321175732.GA3263-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
2013-03-21 18:03                                               ` Michael S. Tsirkin
2013-03-21 18:03                                                 ` [Qemu-devel] " Michael S. Tsirkin
2013-03-21 18:03                                                 ` Michael S. Tsirkin
2013-03-21 18:16                               ` Michael S. Tsirkin [this message]
2013-03-21 18:16                                 ` [Qemu-devel] " Michael S. Tsirkin
2013-03-21 18:16                                 ` Michael S. Tsirkin
     [not found]                                 ` <20130321181633.GC4366-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2013-03-21 18:41                                   ` Jason Gunthorpe
2013-03-21 18:41                                     ` [Qemu-devel] " Jason Gunthorpe
2013-03-21 18:41                                     ` Jason Gunthorpe
     [not found]                                     ` <20130321184135.GA8044-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
2013-03-21 19:15                                       ` Michael S. Tsirkin
2013-03-21 19:15                                         ` [Qemu-devel] " Michael S. Tsirkin
2013-03-21 19:15                                         ` Michael S. Tsirkin
     [not found]                                         ` <20130321191541.GB5272-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2013-03-21 20:09                                           ` Jason Gunthorpe
2013-03-21 20:09                                             ` [Qemu-devel] " Jason Gunthorpe
2013-03-21 20:09                                             ` Jason Gunthorpe
2013-03-21  9:32       ` Michael S. Tsirkin
2013-03-21  9:32         ` [Qemu-devel] " Michael S. Tsirkin
2013-03-21  9:32         ` Michael S. Tsirkin
     [not found]         ` <20130321093230.GF28328-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2013-03-21 11:30           ` Michael S. Tsirkin
2013-03-21 11:30             ` [Qemu-devel] " Michael S. Tsirkin
2013-03-21 11:30             ` Michael S. Tsirkin
2013-03-21 12:23   ` Michael R. Hines
2013-03-21 12:23     ` [Qemu-devel] " Michael R. Hines
2013-03-21 12:23     ` Michael R. Hines
2013-03-21 12:32     ` Michael S. Tsirkin
2013-03-21 12:32       ` [Qemu-devel] " Michael S. Tsirkin

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=20130321181633.GC4366@redhat.com \
    --to=mst-h+wxahxf7alqt0dzr+alfa@public.gmane.org \
    --cc=cl-vYTEC60ixJUAvxtiuMwx3w@public.gmane.org \
    --cc=hal.rosenstock-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
    --cc=jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org \
    --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=mrhines-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org \
    --cc=qemu-devel-qX2TKyscuCcdnm+yROfE0A@public.gmane.org \
    --cc=roland-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
    --cc=sean.hefty-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org \
    --cc=yishaih-VPRAkNaXOzVWk0Htik3J/w@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.