> Yes, every Linux arch aligns structs to the min alignment for the
> members, so at least 32 in this case.
>
> However, it doesn't really matter, look at ibv_cmd_query_port, it
> doesn't zero the padding. So there must be an ABI bump to ensure that
> new code links to a library that doesn't fill the new member with
> garbage.
>
> This is a messy one, the low level libraries have to be reved somehow too..
> ops.query_port2() I guess.
Actually I think we can fix this in libibverbs without having to break
anything. It's a little bit devious, but if we do something like:
// ... add link_layer member in padding of struct ibv_port_attr
enum {
IBV_LINK_LAYER_UNSPECIFIED,
IBV_LINK_LAYER_INFINIBAND,
IBV_LINK_LAYER_ETHERNET,
};
static inline int __ibv_query_port(struct ibv_context *context, uint8_t
port_num,
struct ibv_port_attr *port_attr)
{
port_attr->link_layer = IBV_LINK_LAYER_UNSPECIFIED;
return ibv_query_port(context, port_num, port_attr);
}
// ... rest of file...
#define ibv_query_port(context, port_num, port_attr) \
__ibv_query_port(context, port_num, port_attr)
then I think legacy apps should be OK (port_attr size doesn't change,
binary compat is still there), and new apps that do check link_layer
should also be OK ... if they use an old library and/or old driver,
they'll see LINK_LAYER_UNSPECIFIED, which means that IBoE is not supported.
What do you think, does this work?
- R.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
