Sorry for jumping in so late in the process, but a few big concerns: > struct ibv_qp *ibv_create_qp_expanded(struct ibv_pd *pd, > struct ibv_qp_init_attr *qp_init_attr, > uint32_t create_flags);
I don't like the name "_expanded" when all we are doing is adding a flags parameter. The next time we need to tweak this API, then we end up with _extra_super_expanded or something like that. I see two better options: keep the same prototype but call it something like ibv_create_qp_with_flags (or maybe ibv_create_qp_flags), or keep the name ibv_create_qp_expanded but instead of create_flags, have the new parameter be ext_mask, have one bit in ext_mask indicate create flags, and add create_flags to struct ibv_qp_init_attr -- then we can add more extra stuff by using more bits in ext_mask. Also, I wonder if it's worth a new verb in the kernel ABI for this. Maybe we should add a new command in the ABI where libibverbs can pass in a bitmask of supported extensions, and the kernel can respond with which extensions it supports. And then we can just continue to use the reserved field in the existing create_qp command if both kernel and userspace agree that they support create flags there. - R. _______________________________________________ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg