>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
