aboutsummaryrefslogtreecommitdiff
path: root/usr
diff options
context:
space:
mode:
authorOr Gerlitz <ogerlitz@voltaire.com>2008-03-11 16:10:02 +0200
committerRoland Dreier <rolandd@cisco.com>2008-03-11 14:12:03 -0700
commitb3e2749bf32f61e7beb259eb7cfb066d2ec6ad65 (patch)
tree3fb0ce0dd2c470b00a9bb942c163fd77f2a1dc51 /usr
parent450bb3875f5f5ab3679823c941d6045d16967370 (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 'usr')
0 files changed, 0 insertions, 0 deletions