[openib-general] [PATCH 1/2] rdma_cm: add support to join IPOIB multicast groups

Or Gerlitz or.gerlitz at gmail.com
Wed Jan 24 10:12:21 PST 2007


On 1/24/07, Sean Hefty <mshefty at ichips.intel.com> 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.




More information about the general mailing list