On Wed, Nov 11, 2015 at 11:07:14AM +0200, Sagi Grimberg wrote: > > > On 10/11/2015 15:41, Christoph Hellwig wrote: > >FYI, this is the API I'd aim for (only SRP and no HW driver converted > >yet): > > This looks fine, although personally I find scope and direction flags > more confusing than access_flags (but maybe it's just me). Looking at the drivers the current flags seem to confuse programmes hard, given that the choises seem to be random values that just happen to work: rkeys: iser: lwrite | rwrite | rread srp: lwrite | rwrite | rread rds: lwrite | rread | rwrite rds: rwrite xprdtrdma (wr): rwrite | lwrite xprdtrdma (rd): rread lkeys: isert: lwrite svcrdma: lwrite | rwrite moving to a model where the consumer clearly says what they intend to do with the MR seem much better than that. > I think that the real issue here is the server/target side which needs > extra logic for rdma_read and memory registration. If we can put this > logic in the core and give ULPs an API that looks something like: > - ib_rdma_read() > - ib_rdma_write() > > then maybe we don't need to change our flags? The current flags don't make any sense for someone trying to use the API. They're pointless leakage of badly designed protocol specs. -- 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
