[ofa-general] Re: IB/core: Add creation flags to QPs

[Or Gerlitz]

Jack Morgenstein wrote:
> You can't have your cake and eat it too.  You can't both use a bitmap
> and preserve backwards compatibility.
>
> The current QP types are:
> enum ib_qp_type {
> 	/*
> 	 * IB_QPT_SMI and IB_QPT_GSI have to be the first two entries
> 	 * here (and in that order) since the MAD layer uses them as
> 	 * indices into a 2-entry table.
> 	 */
> 	IB_QPT_SMI,
> 	IB_QPT_GSI,
>
> 	IB_QPT_RC,
> 	IB_QPT_UC,
> 	IB_QPT_UD,
> 	IB_QPT_XRC,
> 	IB_QPT_RAW_IPV6,
> 	IB_QPT_RAW_ETY
> };
>
> 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.
>
> 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.
>   
Basically, my motivation is to find a way to integrate the 
block-loopback feature without breaking the libibverbs (kernel/user) and 
(lib/app) ABI. So in that sense I do hope there's a way to eat the cake 
in a way which is not notable by libibverbs consumers which are compiled 
and/or linked in any static/dynamic manner against an older version of 
the library.

I assume that space wise (enum == unsigned int == u32) for the compiler.

So with that assumption at hand, the above enum has the values 0...7 
occupied, what would be the problem to replace in the kernel .h file, 
the enum qp_type field with u32 qp_type_bits field where the above types 
getting bits 0...7 respectively and the new "types" LSO, LL, BL getting 
bits 8,9,10 . Later change the libibverbs .h file to match this?!

Or.