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
Ron Livne wrote:
OK, but doesn't it contradict the approach you agreed on?
What do you think of the following approach?
Instead of adding creation flags to the qp_init_attr, I can add a new verb:
ibv_qp *create_qp_extended(struct ibv_pd *pd, struct ibv_qp_init_attr,
*init_attr, enum
Olga Shern wrote:
Tziporet,
Ron cannot work with Roland's tree,
because not all XRC patches are there.
But he should prepare us patches for OFED, or maybe we skip this?
Tziporet
___
ewg mailing list
ewg@lists.openfabrics.org
OK, but doesn't it contradict the approach you agreed on?
What do you think of the following approach?
Instead of adding creation flags to the qp_init_attr, I can add a new verb:
ibv_qp *create_qp_extended(struct ibv_pd *pd, struct ibv_qp_init_attr,
*init_attr, enum ibv_qp_create_flags
On Tuesday 12 August 2008 22:37, Roland Dreier 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,
1. This patch adds a new capability flags to the enum ibv_device_cap_flags
IBV_DEVICE_BLOCK_MULTICAST_LOOPBACK.
which implies that the device is capable of blocking multicast
loopback packets.
2. This patch also adds a new verb to the libibverbs:
struct ibv_qp
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
