On Fri, Sep 04, 2015 at 04:23:05PM -0400, Doug Ledford wrote: > On 09/03/2015 10:56 AM, Haggai Eran wrote: > > This series adds userspace support for on-demand paging. The first patch adds > > support for the new extended query device verb. Patch 2 adds the capability and > > interface bits related to on-demand paging, and patch 3 adds example code to > > the rc_pingpong program to use on-demand paging. > > I've reviewed this series and I'm OK with it. However, it's currently > blocked. We need to fix the API mess that was created when the > create/destroy flow verbs were added. I've gone back through the code, > and I'm pretty sure I know what Jason's objection to the create/destroy > flow implementation was. In particular, we weren't supposed to have this: > > struct verbs_context { > /* "grows up" - new fields go here */ > + int (*drv_ibv_destroy_flow) (struct ibv_flow *flow); > + int (*lib_ibv_destroy_flow) (struct ibv_flow *flow); > + struct ibv_flow * (*drv_ibv_create_flow) (struct ibv_qp *qp, > + struct ibv_flow_attr > + *flow_attr); > + struct ibv_flow * (*lib_ibv_create_flow) (struct ibv_qp *qp, > + struct ibv_flow_attr > + *flow_attr); > > There was only supposed to be ibv_create_flow and ibv_destroy_flow, not > this silly separate drv/lib versions that just amount to wasted space > and confusion. > > Our choices are: 1) Leave this in place but don't do any more extensions > this way, knowing full well that this is wrong but preserving ABI or We should drop the code so people don't copy it. Replace the one that isn't used with a 'void * __compat_foo_Bar' and if necessary have the common setup in ibverbs copy a non-null __compat_ into lib_. This will compile-break drivers using the wrong scheme, the driver should be changed. Using a new driver with a old verbs means only the flow API doesn't work, old driver with new verbs is stil OK. Drop a dependency in the mlx4 package. Safe breakage in an obscure scenario.. Jason -- 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