Ralph Campbell wrote:
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
Hefty, Sean wrote:
One could argue that this change is reasonable regardless of the OFED kernel
patch. It avoids sending multicast traffic when the destination is local. The
main drawback beyond the extra code is that a node can't send a multicast
message to itself, with the intent that
To be precise, the bit avoids recieving multicast packets by the QP that
--sent-- it, not by other QPs subscribed to that group on the same
node/hca, the patch change-log even states that Inter QP multicast
packets on the relevant HCA will still be delivered. You can test that
with two mckey
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.
If there's
OFED 1.5.2 introduced a kernel patch that disables looping
back multicast messages to the sending QP. This capability
was enabled by default. The current ACM address resolution
protocol depends on this feature of multicast. To handle
the case where multicast loopback has been disabled, modify
On Tue, 2010-11-16 at 16:15 -0800, Hefty, Sean wrote:
...
@@ -2620,6 +2663,12 @@ static void acm_set_options(void)
}
fclose(f);
+
+ if (!(f = fopen(/sys/module/mlx4_core/parameters/block_loopback,
r)))
+ return;
+
+ fscanf(f, %d, loopback_prot);
+
This seems to introduce an HCA specific dependency.
yep :( This is why ACM just handles it rather than exposing any sort of option
to a user.
Isn't ibacm supposed to work with different HCAs?
It does and still will, even in a mixed environment.
One could argue that this change is
On Tue, 2010-11-16 at 16:54 -0800, Hefty, Sean wrote:
This seems to introduce an HCA specific dependency.
yep :( This is why ACM just handles it rather than exposing any sort of
option to a user.
Isn't ibacm supposed to work with different HCAs?
It does and still will, even in a
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
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
10 matches
Mail list logo
