----- Original Message -----
> On Mon, 5 May 2014, Hefty, Sean wrote:
>
> > I agree with Doug here. This makes more sense to specify on
> > multicast atta=
> > ch time, not QP creation time.
>
> On topic response: Do devices support multicast loopback blocking on
> a
> multicast group?
I would think this is very doubtful...see below...
> From what I can tell the multicast support in NICs
> is
> based on having a table with MAC addresses of the multicast groups
> that
> the NIC is able to receive.
That table only tells the NIC to listen to specific multicast
addresses on the wire. This is roughly equivalent to telling
the SM to subscribe the port to the multicast groups it needs
subscribed too. In both cases, this merely gets the packets
to the card. From there, the card (or the OS as is usually the
case on NICs and Ethernet multicast) must redistribute the
packet to all queue pairs that have subscribed to the group
that the packet was received from. If you were to block it at
the group level, then it universally effect all applications
that subscribed to that group, and there might well be a number
of applications that did not request this behavior and would
be rightfully confused at the card/OS not sending them their
multicast packets. So, I would suggest that the blocking of
loopback multicast packets needs to be "opt in" for all
applications. The big hammer of blocking all loopback on an
entire card or an entire group, while possible, should be
highly discouraged. It might work with limited applications
that know it is being done, but it can also lead to hard to
diagnose problems if you add a new application into the mix
and it is unaware of this hammer being used and unable to
handle the situation.
--
Doug Ledford <dledford@xxxxxxxxxx>
GPG KeyID: 0E572FDD
http://people.redhat.com/dledford
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
