> > A source change is completely unvaoidable. Supporting the new MTU
> > values requires updated source.
>
>
> I don't really care one way or the other; I'll submit whatever patch people
> want. :-)
>
> But FWIW, I tend to believe the Doug/Jason position:
>
> - MTU really needs to be a plain integer (not an enum)
> - forcing application source change/adaptation is the safest way to move
> forward
> - doing it this way preserves ABI, so existing binaries are safe
I don't remember. Is it known how the mtu is communicated with the kernel?
Looking at kern-abi.h, the mtu fields are:
struct ibv_query_port_resp {
__u8 max_mtu;
__u8 active_mtu;
struct ibv_kern_qp_attr {
__u32 path_mtu;
struct ibv_query_qp_resp {
__u8 path_mtu;
struct ibv_modify_qp {
__u8 path_mtu;
In most cases, we only have 8 bits available to/from the kernel. (There are at
least 16 bits of reserved space in these structures.)
- Sean
--
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
