> > > > +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 would call SOURCE the RESPONDER..
>
> Initiator/Poster and Responder is closest to the language used in
> other places in the API for READ.
I agree with Steve. I think of this in terms of copy and like source/dest myself, similar to source/sink. A memory buffer is not a responder or initiator.
In hindsight, we probably never should have exposed initiator_depth and responder_resources. Those values have been an endless source of confusion and bugs.
--
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
