[ewg] [PATCH 1/2 v2]libibvers: add create_qp_expanded

[Ron Livne]

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 <rdreier at cisco.com> 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
> ewg at lists.openfabrics.org
> http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
>