diff options
author | Or Gerlitz <ogerlitz@voltaire.com> | 2008-03-11 16:10:02 +0200 |
---|---|---|
committer | Roland Dreier <rolandd@cisco.com> | 2008-03-11 14:12:03 -0700 |
commit | b3e2749bf32f61e7beb259eb7cfb066d2ec6ad65 (patch) | |
tree | 3fb0ce0dd2c470b00a9bb942c163fd77f2a1dc51 /drivers/infiniband/ulp/ipoib/ipoib_cm.c | |
parent | 450bb3875f5f5ab3679823c941d6045d16967370 (diff) |
IPoIB: Don't drop multicast sends when they can be queued
When set_multicast_list() is called the multicast task is restarted
and the IPOIB_MCAST_STARTED bit is cleared. As a result for some
window of time, multicast packets are not transmitted nor queued but
rather dropped by ipoib_mcast_send(). These dropped packets are
painful in two cases:
- bonding fail-over which both calls set_multicast_list() on the new
active slave and sends Gratuitous ARP through that slave.
- IP_DROP_MEMBERSHIP code which both calls set_multicast_list() on the
device and issues IGMP leave.
In both these cases, depending on the scheduling of the IPoIB
multicast task, the packets would be dropped. As a result, in the
bonding case, the failover would not be detected by the peers until
their neighbour is renewed the neighbour (which takes a few tens of
seconds). In the IGMP case, the IP router doesn't get an IGMP leave
and would only learn on that from further probes on the group (also a
delay of at least a few tens of seconds).
Fix this by allowing transmission (or queuing) depending on the
IPOIB_FLAG_OPER_UP flag instead of the IPOIB_MCAST_STARTED flag.
Signed-off-by: Olga Shern <olgas@voltaire.com>
Signed-off-by: Or Gerlitz <ogerlitz@voltaire.com>
Signed-off-by: Roland Dreier <rolandd@cisco.com>
Diffstat (limited to 'drivers/infiniband/ulp/ipoib/ipoib_cm.c')
0 files changed, 0 insertions, 0 deletions