Roland, Wouldn't adding a new field to struct ibv_qp_init_attr break the ABI?
Anyway, I prefer your first approach and just change the functions name from create_qp_expanded to avoid compatibility issues. But if you prefer the ext_mask approach and adding creation flags to the qp_init_attr struct - it's fine by me. Please tell me which one do you prefer. > 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. There are only 8 reserved bits. I think they have a good chance to run out quickly. Ron On Tue, Aug 12, 2008 at 9:37 PM, Roland Dreier <[EMAIL PROTECTED]> wrote: > 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 > [email protected] > http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg > _______________________________________________ ewg mailing list [email protected] http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
