On Wednesday 26 March 2008 13:02, Or Gerlitz wrote:
> How about making the qp_type field a bit mask, such that in the ipoib
> LSO use case it would be (UD | LSO) and in the ipoib ehca case (UD |
> LL), etc. The bit mask change would also be propagated up to libibverbs
> and be defined in a way such that it preserves backward compatibility re
> the qp_type field for users of libibverbs that did not changed their code.
>
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.
- Jack
_______________________________________________
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
