RE: [PATCH RFC] RDMA/core: add rdma_get_dma_mr()

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




> -----Original Message-----
> From: linux-rdma-owner@xxxxxxxxxxxxxxx [mailto:linux-rdma-owner@xxxxxxxxxxxxxxx] On Behalf Of Haggai Eran
> Sent: Sunday, June 28, 2015 10:47 AM
> To: Steve Wise; jgunthorpe@xxxxxxxxxxxxxxxxxxxx
> Cc: sagig@xxxxxxxxxxxx; roid@xxxxxxxxxxxx; ogerlitz@xxxxxxxxxxxx; sean.hefty@xxxxxxxxx; linux-rdma@xxxxxxxxxxxxxxx
> Subject: Re: [PATCH RFC] RDMA/core: add rdma_get_dma_mr()
> 
> On 26/06/2015 00:29, Steve Wise wrote:
> > +enum rdma_mr_roles {
> > +	RDMA_MRR_RECV			= 1,
> > +	RDMA_MRR_SEND			= (1<<1),
> > +	RDMA_MRR_READ_SOURCE		= (1<<2),
> > +	RDMA_MRR_READ_SINK		= (1<<3),
> 
> Maybe it's just me, but it took me a second to figure out which was the
> source and which was the sink in RDMA reads. Do you think calling them
> initiator and responder/target would be better?

Not to me.  For an RDMA operation, the "initiator" is the app that issues the read request WR.  That app doesn't create what I call the READ_SOURCE MR.  Its peer application does.  So calling READ_SOURCE something like READ_INITIATOR doesn't make sense to me.   That's why I thought SOURCE and SINK were clearer.  Perhaps not...

I have a new version I'll send out soon that will comment all of these in the enum declaration.  Perhaps that will make it clear.


> 
> > +	RDMA_MRR_WRITE_SOURCE		= (1<<4),
> > +	RDMA_MRR_WRITE_SINK		= (1<<5),
> > +	RDMA_MRR_ATOMIC			= (1<<6),
> > +	RDMA_MRR_MW_BIND		= (1<<7),
> > +	RDMA_MRR_ZERO_BASED		= (1<<8),
> > +	RDMA_MRR_ACCESS_ON_DEMAND	= (1<<9),
> > +};
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Photo]     [Yosemite News]     [Yosemite Photos]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux