On 1/24/07, Sean Hefty <[EMAIL PROTECTED]> wrote: > > However, it will not support "mixed mode" communication patterns (which > > you were raising last week) that is one app having a UD QP for both > > multicast and unicast that talks with two "peers" IPoIB multicast and > > another app doing only unicast.
> Separating ipoib to its own port space alleviated my concerns on existing > usage. > The RDMA_PS_UDP continues operating as before, with mixed mode traffic > supported. Mixed mode for RDMA_PS_IPOIB is not supported, since it's not > clear > to me how that would be used. The IPOIB protocol doesn't use SIDR, so I'm > hesitant to extend the capabilities until there's a clear need/use. Indeed, it is not possible to have UDP --unicast-- interop between "IPoIB UD" (ie not IPoIB CM) and an RDMA_PS_IPOIB RDMA CM consumer. However, it is possible that an RDMA_PS_IPOIB consumer would want to talk over ---one-- UD QP with two peers: 1) IPoIB - multicast traffic 2) --another-- RDMA CM consumer - unicast traffic since both talks are over the same QP everyone must use the same --QKEY--, now since RDMA_PS_IPOIB does not support the SIDR exchange this config is broken. The patch i have sent allows this, and it can be really nice to remove this restriction with some documentation explaining the restrictions. > > Also, just a clarification - how exactly the patch enforces that an app > > would not be able to do listen/connect/accept on RDMA_PS_IPOIB ID??? > This is not enforce directly yet. (It just requires an if statement in > resolve > route.) I would expect that if it were tried, there would be a failure at > some > point. OK, that (failure at some point) was my thought as well. Or. _______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
