>I'm reluctant to override fields like this to save 4 bytes. The >clarity and extensibility of using an additional flags field seems >worth it to me, and the processing code is not complex. I cannot think >of a motivation to save the 4 bytes?
I wasn't thinking about saving the 4 bytes. struct ib_user_path_rec is already part of the ABI for query route. If the preference were used to indicate primary versus alternate path, which seems reasonable, then query route can more easily convey that information. Preference is implementation defined and meaningless once a path has been selected, so I really don't see any issue in using it however we want. I thought about using it to convey all of the flags, but it doesn't give much room for expansion. That led me to consider using the sgid and reversible bit to determine if a path is outbound or inbound. >As I said, in many ways I would actually much perfer it if the >structure was: > >struct ibv_kern_path_rec2 >{ > u32 flags; > u32 pr[512/8/4]; >} I would have preferred using MAD definitions directly everywhere myself, but I don't think it's worth breaking the ABI to change this. struct ib_user_path_rec is already in use by the ib_cm and rdma_cm at this point. (The rdma_cm simply copied its use by the ib_cm.) - Sean -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html