> -----Original Message----- > From: Haggai Eran [mailto:haggaie@xxxxxxxxxxxx] > Sent: Tuesday, July 07, 2015 9:34 AM > To: Steve Wise; dledford@xxxxxxxxxx > Cc: sagig@xxxxxxxxxxxx; ogerlitz@xxxxxxxxxxxx; roid@xxxxxxxxxxxx; linux-rdma@xxxxxxxxxxxxxxx; eli@xxxxxxxxxxxx; target- > devel@xxxxxxxxxxxxxxx; linux-nfs@xxxxxxxxxxxxxxx; trond.myklebust@xxxxxxxxxxxxxxx; bfields@xxxxxxxxxxxx > Subject: Re: [PATCH V3 1/5] RDMA/core: Transport-independent access flags > > On 07/07/2015 17:17, Steve Wise wrote: > > > > > >> -----Original Message----- > >> From: linux-nfs-owner@xxxxxxxxxxxxxxx [mailto:linux-nfs-owner@xxxxxxxxxxxxxxx] On Behalf Of Haggai Eran > >> Sent: Monday, July 06, 2015 2:09 AM > >> To: Steve Wise; dledford@xxxxxxxxxx > >> Cc: sagig@xxxxxxxxxxxx; ogerlitz@xxxxxxxxxxxx; roid@xxxxxxxxxxxx; linux-rdma@xxxxxxxxxxxxxxx; eli@xxxxxxxxxxxx; target- > >> devel@xxxxxxxxxxxxxxx; linux-nfs@xxxxxxxxxxxxxxx; trond.myklebust@xxxxxxxxxxxxxxx; bfields@xxxxxxxxxxxx > >> Subject: Re: [PATCH V3 1/5] RDMA/core: Transport-independent access flags > >> > >> On 06/07/2015 02:22, Steve Wise wrote: > >>> +int rdma_device_access_flags(struct ib_pd *pd, int roles, int attrs) > >>> +{ > >>> + int access_flags = attrs; > >>> + > >>> + if (roles & RDMA_MRR_RECV) > >>> + access_flags |= IB_ACCESS_LOCAL_WRITE; > >>> + > >>> + if (roles & RDMA_MRR_WRITE_DEST) > >>> + access_flags |= IB_ACCESS_LOCAL_WRITE | IB_ACCESS_REMOTE_WRITE; > >>> + > >>> + if (roles & RDMA_MRR_READ_DEST) { > >>> + access_flags |= IB_ACCESS_LOCAL_WRITE; > >>> + if (rdma_protocol_iwarp(pd->device, > >>> + rdma_start_port(pd->device))) > >>> + access_flags |= IB_ACCESS_REMOTE_WRITE; > >>> + } > >>> + > >>> + if (roles & RDMA_MRR_READ_SOURCE) > >>> + access_flags |= IB_ACCESS_REMOTE_READ; > >>> + > >>> + if (roles & RDMA_MRR_ATOMIC_DEST) > >>> + access_flags |= IB_ACCESS_LOCAL_WRITE | IB_ACCESS_REMOTE_ATOMIC; > >> > >> I think you need LOCAL_WRITE for ATOMIC_SOURCE in order to receive the > >> results of the atomic operation. > >> > > > > Where/how are the results returned? In a recv completion? If so, then that MR would need RDMA_MRR_RECV, not > RDMA_MRR_ATOMIC_SOURCE. > > They are returned in the scatter list provided in ib_send_wr.sg_list, > similarly to how RDMA read results are returned. Ah. Hmm. I was confused about how the atomic operations worked. Is this correct: ib_send_wr.wr.atomic.remote_addr : the peer's address that will be the target of the atomic operation. ib_send_wr.wr.atomic.compare_add/compare_add_mask: the data to be used in the atomic compare-and-add on the target address ib_send_wr.wr.atomic.swap/swap_mask: the data to be used in an atomic swap on the target address. ib_send_wr.sg_list: results from the swap or compare/add. Is the above correct? Maybe the two role names should be RDMA_MRR_ATOMIC_TARGET and RDMA_MRR_ATOMIC_RESULT? Steve. -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
