On Apr 3, 2013, at 12:52 PM, Roland Dreier <rol...@purestorage.com> wrote:
> I don't think we can blithely do this... I think the IB enum values > are defined to match the values used in the IB spec (PathRecord etc). Gotcha. I inserted the enums in their proper numerical order to make the range comparisons simpler in ib_addr.h. But the 1500/9000 values could be tacked at the end of the current values (e.g., 6 and 7, respectively) -- it would just necessitate some different changes in ib_addr.h. > Even if we change it so 1500 and 9000 are outside of the range used by > the IB spec, I don't understand the motivation for this change. What > does this buy us? Our impression was that a userspace application cannot know the max message size it can send across a UD QP without having an accurate MTU enum. Specifically: the ibv_port_attr.max_msg_size value seems to be a higher-level value. E.g., on Mellanox devices, .max_msg_size is the max size of RC QP messages. Is there another way to determine max UD QP message size that we missed? > How is iWARP working today without this change? They lie about the actual/underlying MTU. But they don't have UD QPs, so .max_msg_size is sufficient for their RC QPs. -- Jeff Squyres jsquy...@cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/ -- 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
