Jack Morgenstein wrote:
No, it isn't. If the customer has an old libibverbs running against a new
kernel (which uses your bitmap suggestion of bits 0..7), all his apps will fail
to run (the qp_type passed by the old libibverbs to the new kernel will be
misinterpreted).
Ok, Jack, I see your point now, sorry for being slow to catch up, so
with this in mind:
This means that we are using the 3 LSBs in an enumerated fashion (integers
0..7), so
we can't use a bitmap here. This leads us to a mixed field anyway --
3 bits for existing QP types (integers 0..6), and 29 bits of bit-map.
Yes, so way we can go the somehow not very elegant way, that is have the
uverbs code examine the u32 value and if the only non zero bits are
among the 3 LS ones, uses the values from the old enum and if any of the
remaining 29 bits are set consider their values under the bit field
scheme, etc.
Why not just keep things separate, and use the enumeration as is for the
existing types,
and keep the bitmap as a separate "flags" field -- this is much cleaner.
and this means breaking the ABI, correct. If such a breakage is going to
happen anyway for the merge of XRC into the mainline kernel and the
official libibverbs as maintained by Roland, I guess this is fine. I see
now that the device capabilities enum is managed in bit field fashion
so at least there the kernel can advertise easily the block-loopback
support as you did for XRC (below) why have you left 6 unused bits
Or
enum ibv_device_cap_flags {
IBV_DEVICE_RESIZE_MAX_WR = 1,
IBV_DEVICE_BAD_PKEY_CNTR = 1 << 1,
IBV_DEVICE_BAD_QKEY_CNTR = 1 << 2,
IBV_DEVICE_RAW_MULTI = 1 << 3,
IBV_DEVICE_AUTO_PATH_MIG = 1 << 4,
IBV_DEVICE_CHANGE_PHY_PORT = 1 << 5,
IBV_DEVICE_UD_AV_PORT_ENFORCE = 1 << 6,
IBV_DEVICE_CURR_QP_STATE_MOD = 1 << 7,
IBV_DEVICE_SHUTDOWN_PORT = 1 << 8,
IBV_DEVICE_INIT_TYPE = 1 << 9,
IBV_DEVICE_PORT_ACTIVE_EVENT = 1 << 10,
IBV_DEVICE_SYS_IMAGE_GUID = 1 << 11,
IBV_DEVICE_RC_RNR_NAK_GEN = 1 << 12,
IBV_DEVICE_SRQ_RESIZE = 1 << 13,
IBV_DEVICE_N_NOTIFY_CQ = 1 << 14,
IBV_DEVICE_XRC = 1 << 20
};
_______________________________________________
general mailing list
[email protected]
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
