I guess what I'm objecting to is hard coding mlx4. I was trying to think of a way that would allow other HCAs to support the block loopback option in the future. It looks like ipoib sets IB_QP_CREATE_BLOCK_MULTICAST_LOOPBACK for kernel QPs but this isn't defined in libibverbs yet. It seems reasonable to add that feature some time in the future and change ibacm to use it.
In the mean time, I guess I don't see an alternative to your patch. On Tue, 2010-11-16 at 17:24 -0800, Hefty, Sean wrote: > > Is there a way to make it HCA neutral? > > Would it require extending the libibverbs API to set the option? > > I'm not quite following what the problem is. ACM doesn't care what HCA is > used. It does adjust how it handles loopback addresses based on whether some > value is written in an HCA/OFED 1.5.2 release file, but it will work > regardless. (This is worse than being HCA specific, we're HCA and OFED > release specific.) > > In the worst case, ACM basically stops working correctly over mlx4 HCAs. > Loopback requests will end up going through all retries (default is 15) until > they time out (default ~45 seconds). If the user is the librdmacm, it will > fall back to normal operation. > > ACM has a configuration file that _could_ be used to specify a loopback > protocol. However, that file is usually generated by the ib_acme utility, so > the check would move into it. > > Since OFED 1.5.2 has shipped, I don't know how you fix it. In a more ideal > world, this loopback issue would be limited only to ipoib QPs, or be > configurable per QP, or disabled by default, or have gone upstream first... > > - Sean > > > -- > 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 > -- 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
