2006-01-03 02:04:38 +08:00
|
|
|
/*
|
|
|
|
* net/tipc/bcast.c: TIPC broadcast code
|
2007-02-09 22:25:21 +08:00
|
|
|
*
|
2006-01-12 02:14:19 +08:00
|
|
|
* Copyright (c) 2004-2006, Ericsson AB
|
2006-01-03 02:04:38 +08:00
|
|
|
* Copyright (c) 2004, Intel Corporation.
|
2011-01-08 02:00:11 +08:00
|
|
|
* Copyright (c) 2005, 2010-2011, Wind River Systems
|
2006-01-03 02:04:38 +08:00
|
|
|
* All rights reserved.
|
|
|
|
*
|
2006-01-11 20:30:43 +08:00
|
|
|
* Redistribution and use in source and binary forms, with or without
|
2006-01-03 02:04:38 +08:00
|
|
|
* modification, are permitted provided that the following conditions are met:
|
|
|
|
*
|
2006-01-11 20:30:43 +08:00
|
|
|
* 1. Redistributions of source code must retain the above copyright
|
|
|
|
* notice, this list of conditions and the following disclaimer.
|
|
|
|
* 2. Redistributions in binary form must reproduce the above copyright
|
|
|
|
* notice, this list of conditions and the following disclaimer in the
|
|
|
|
* documentation and/or other materials provided with the distribution.
|
|
|
|
* 3. Neither the names of the copyright holders nor the names of its
|
|
|
|
* contributors may be used to endorse or promote products derived from
|
|
|
|
* this software without specific prior written permission.
|
2006-01-03 02:04:38 +08:00
|
|
|
*
|
2006-01-11 20:30:43 +08:00
|
|
|
* Alternatively, this software may be distributed under the terms of the
|
|
|
|
* GNU General Public License ("GPL") version 2 as published by the Free
|
|
|
|
* Software Foundation.
|
|
|
|
*
|
|
|
|
* THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
|
|
|
|
* AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
|
|
|
|
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
|
|
|
|
* ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE
|
|
|
|
* LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
|
|
|
|
* CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
|
|
|
|
* SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
|
|
|
|
* INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
|
|
|
|
* CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
|
|
|
|
* ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
|
2006-01-03 02:04:38 +08:00
|
|
|
* POSSIBILITY OF SUCH DAMAGE.
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include "core.h"
|
|
|
|
#include "link.h"
|
|
|
|
#include "port.h"
|
|
|
|
#include "bcast.h"
|
2011-04-08 02:57:53 +08:00
|
|
|
#include "name_distr.h"
|
2006-01-03 02:04:38 +08:00
|
|
|
|
|
|
|
#define MAX_PKT_DEFAULT_MCAST 1500 /* bcast link max packet size (fixed) */
|
|
|
|
|
|
|
|
#define BCLINK_WIN_DEFAULT 20 /* bcast link window size (default) */
|
|
|
|
|
|
|
|
/**
|
2011-12-30 09:55:27 +08:00
|
|
|
* struct tipc_bcbearer_pair - a pair of bearers used by broadcast link
|
2006-01-03 02:04:38 +08:00
|
|
|
* @primary: pointer to primary bearer
|
|
|
|
* @secondary: pointer to secondary bearer
|
2007-02-09 22:25:21 +08:00
|
|
|
*
|
|
|
|
* Bearers must have same priority and same set of reachable destinations
|
2006-01-03 02:04:38 +08:00
|
|
|
* to be paired.
|
|
|
|
*/
|
|
|
|
|
2011-12-30 09:55:27 +08:00
|
|
|
struct tipc_bcbearer_pair {
|
2011-01-08 02:00:11 +08:00
|
|
|
struct tipc_bearer *primary;
|
|
|
|
struct tipc_bearer *secondary;
|
2006-01-03 02:04:38 +08:00
|
|
|
};
|
|
|
|
|
|
|
|
/**
|
2011-12-30 09:55:27 +08:00
|
|
|
* struct tipc_bcbearer - bearer used by broadcast link
|
2006-01-03 02:04:38 +08:00
|
|
|
* @bearer: (non-standard) broadcast bearer structure
|
|
|
|
* @media: (non-standard) broadcast media structure
|
|
|
|
* @bpairs: array of bearer pairs
|
2006-06-26 14:53:20 +08:00
|
|
|
* @bpairs_temp: temporary array of bearer pairs used by tipc_bcbearer_sort()
|
|
|
|
* @remains: temporary node map used by tipc_bcbearer_send()
|
|
|
|
* @remains_new: temporary node map used tipc_bcbearer_send()
|
2007-02-09 22:25:21 +08:00
|
|
|
*
|
2006-06-26 14:53:20 +08:00
|
|
|
* Note: The fields labelled "temporary" are incorporated into the bearer
|
|
|
|
* to avoid consuming potentially limited stack space through the use of
|
|
|
|
* large local variables within multicast routines. Concurrent access is
|
|
|
|
* prevented through use of the spinlock "bc_lock".
|
2006-01-03 02:04:38 +08:00
|
|
|
*/
|
2011-12-30 09:55:27 +08:00
|
|
|
struct tipc_bcbearer {
|
2011-01-08 02:00:11 +08:00
|
|
|
struct tipc_bearer bearer;
|
2011-12-30 09:19:42 +08:00
|
|
|
struct tipc_media media;
|
2011-12-30 09:55:27 +08:00
|
|
|
struct tipc_bcbearer_pair bpairs[MAX_BEARERS];
|
|
|
|
struct tipc_bcbearer_pair bpairs_temp[TIPC_MAX_LINK_PRI + 1];
|
2008-09-03 14:38:32 +08:00
|
|
|
struct tipc_node_map remains;
|
|
|
|
struct tipc_node_map remains_new;
|
2006-01-03 02:04:38 +08:00
|
|
|
};
|
|
|
|
|
|
|
|
/**
|
2011-12-30 09:52:18 +08:00
|
|
|
* struct tipc_bclink - link used for broadcast messages
|
2006-01-03 02:04:38 +08:00
|
|
|
* @link: (non-standard) broadcast link structure
|
|
|
|
* @node: (non-standard) node structure representing b'cast link's peer node
|
2011-10-24 23:18:12 +08:00
|
|
|
* @bcast_nodes: map of broadcast-capable nodes
|
2011-01-19 02:53:16 +08:00
|
|
|
* @retransmit_to: node that most recently requested a retransmit
|
2007-02-09 22:25:21 +08:00
|
|
|
*
|
2006-01-03 02:04:38 +08:00
|
|
|
* Handles sequence numbering, fragmentation, bundling, etc.
|
|
|
|
*/
|
2011-12-30 09:52:18 +08:00
|
|
|
struct tipc_bclink {
|
2011-12-30 09:58:42 +08:00
|
|
|
struct tipc_link link;
|
2008-09-03 14:38:32 +08:00
|
|
|
struct tipc_node node;
|
2011-10-24 23:18:12 +08:00
|
|
|
struct tipc_node_map bcast_nodes;
|
2011-01-19 02:53:16 +08:00
|
|
|
struct tipc_node *retransmit_to;
|
2006-01-03 02:04:38 +08:00
|
|
|
};
|
|
|
|
|
2011-12-30 09:55:27 +08:00
|
|
|
static struct tipc_bcbearer bcast_bearer;
|
2011-12-30 09:52:18 +08:00
|
|
|
static struct tipc_bclink bcast_link;
|
2011-10-24 22:29:26 +08:00
|
|
|
|
2011-12-30 09:55:27 +08:00
|
|
|
static struct tipc_bcbearer *bcbearer = &bcast_bearer;
|
2011-12-30 09:52:18 +08:00
|
|
|
static struct tipc_bclink *bclink = &bcast_link;
|
2011-12-30 09:58:42 +08:00
|
|
|
static struct tipc_link *bcl = &bcast_link.link;
|
2006-01-03 02:04:38 +08:00
|
|
|
|
2006-06-27 17:53:55 +08:00
|
|
|
static DEFINE_SPINLOCK(bc_lock);
|
2006-01-03 02:04:38 +08:00
|
|
|
|
2010-05-11 22:30:07 +08:00
|
|
|
const char tipc_bclink_name[] = "broadcast-link";
|
2006-01-03 02:04:38 +08:00
|
|
|
|
2010-10-13 21:20:35 +08:00
|
|
|
static void tipc_nmap_diff(struct tipc_node_map *nm_a,
|
|
|
|
struct tipc_node_map *nm_b,
|
|
|
|
struct tipc_node_map *nm_diff);
|
2006-01-03 02:04:38 +08:00
|
|
|
|
2006-03-21 14:37:04 +08:00
|
|
|
static u32 bcbuf_acks(struct sk_buff *buf)
|
2006-01-03 02:04:38 +08:00
|
|
|
{
|
2006-01-13 05:22:32 +08:00
|
|
|
return (u32)(unsigned long)TIPC_SKB_CB(buf)->handle;
|
2006-01-03 02:04:38 +08:00
|
|
|
}
|
|
|
|
|
2006-03-21 14:37:04 +08:00
|
|
|
static void bcbuf_set_acks(struct sk_buff *buf, u32 acks)
|
2006-01-03 02:04:38 +08:00
|
|
|
{
|
2006-01-13 05:22:32 +08:00
|
|
|
TIPC_SKB_CB(buf)->handle = (void *)(unsigned long)acks;
|
2006-01-03 02:04:38 +08:00
|
|
|
}
|
|
|
|
|
2006-03-21 14:37:04 +08:00
|
|
|
static void bcbuf_decr_acks(struct sk_buff *buf)
|
2006-01-03 02:04:38 +08:00
|
|
|
{
|
|
|
|
bcbuf_set_acks(buf, bcbuf_acks(buf) - 1);
|
|
|
|
}
|
|
|
|
|
2011-10-24 23:18:12 +08:00
|
|
|
void tipc_bclink_add_node(u32 addr)
|
|
|
|
{
|
|
|
|
spin_lock_bh(&bc_lock);
|
|
|
|
tipc_nmap_add(&bclink->bcast_nodes, addr);
|
|
|
|
spin_unlock_bh(&bc_lock);
|
|
|
|
}
|
|
|
|
|
|
|
|
void tipc_bclink_remove_node(u32 addr)
|
|
|
|
{
|
|
|
|
spin_lock_bh(&bc_lock);
|
|
|
|
tipc_nmap_remove(&bclink->bcast_nodes, addr);
|
|
|
|
spin_unlock_bh(&bc_lock);
|
|
|
|
}
|
2006-01-03 02:04:38 +08:00
|
|
|
|
2010-08-17 19:00:09 +08:00
|
|
|
static void bclink_set_last_sent(void)
|
|
|
|
{
|
|
|
|
if (bcl->next_out)
|
|
|
|
bcl->fsm_msg_cnt = mod(buf_seqno(bcl->next_out) - 1);
|
|
|
|
else
|
|
|
|
bcl->fsm_msg_cnt = mod(bcl->next_out_no - 1);
|
|
|
|
}
|
|
|
|
|
|
|
|
u32 tipc_bclink_get_last_sent(void)
|
|
|
|
{
|
|
|
|
return bcl->fsm_msg_cnt;
|
|
|
|
}
|
|
|
|
|
tipc: Major redesign of broadcast link ACK/NACK algorithms
Completely redesigns broadcast link ACK and NACK mechanisms to prevent
spurious retransmit requests in dual LAN networks, and to prevent the
broadcast link from stalling due to the failure of a receiving node to
acknowledge receiving a broadcast message or request its retransmission.
Note: These changes only impact the timing of when ACK and NACK messages
are sent, and not the basic broadcast link protocol itself, so inter-
operability with nodes using the "classic" algorithms is maintained.
The revised algorithms are as follows:
1) An explicit ACK message is still sent after receiving 16 in-sequence
messages, and implicit ACK information continues to be carried in other
unicast link message headers (including link state messages). However,
the timing of explicit ACKs is now based on the receiving node's absolute
network address rather than its relative network address to ensure that
the failure of another node does not delay the ACK beyond its 16 message
target.
2) A NACK message is now typically sent only when a message gap persists
for two consecutive incoming link state messages; this ensures that a
suspected gap is not confirmed until both LANs in a dual LAN network have
had an opportunity to deliver the message, thereby preventing spurious NACKs.
A NACK message can also be generated by the arrival of a single link state
message, if the deferred queue is so big that the current message gap
cannot be the result of "normal" mis-ordering due to the use of dual LANs
(or one LAN using a bonded interface). Since link state messages typically
arrive at different nodes at different times the problem of multiple nodes
issuing identical NACKs simultaneously is inherently avoided.
3) Nodes continue to "peek" at NACK messages sent by other nodes. If
another node requests retransmission of a message gap suspected (but not
yet confirmed) by the peeking node, the peeking node forgets about the
gap and does not generate a duplicate retransmit request. (If the peeking
node subsequently fails to receive the lost message, later link state
messages will cause it to rediscover and confirm the gap and send another
NACK.)
4) Message gap "equality" is now determined by the start of the gap only.
This is sufficient to deal with the most common cases of message loss,
and eliminates the need for complex end of gap computations.
5) A peeking node no longer tries to determine whether it should send a
complementary NACK, since the most common cases of message loss don't
require it to be sent. Consequently, the node no longer examines the
"broadcast tag" field of a NACK message when peeking.
Signed-off-by: Allan Stephens <allan.stephens@windriver.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2011-10-28 02:17:53 +08:00
|
|
|
static void bclink_update_last_sent(struct tipc_node *node, u32 seqno)
|
2006-01-03 02:04:38 +08:00
|
|
|
{
|
tipc: Major redesign of broadcast link ACK/NACK algorithms
Completely redesigns broadcast link ACK and NACK mechanisms to prevent
spurious retransmit requests in dual LAN networks, and to prevent the
broadcast link from stalling due to the failure of a receiving node to
acknowledge receiving a broadcast message or request its retransmission.
Note: These changes only impact the timing of when ACK and NACK messages
are sent, and not the basic broadcast link protocol itself, so inter-
operability with nodes using the "classic" algorithms is maintained.
The revised algorithms are as follows:
1) An explicit ACK message is still sent after receiving 16 in-sequence
messages, and implicit ACK information continues to be carried in other
unicast link message headers (including link state messages). However,
the timing of explicit ACKs is now based on the receiving node's absolute
network address rather than its relative network address to ensure that
the failure of another node does not delay the ACK beyond its 16 message
target.
2) A NACK message is now typically sent only when a message gap persists
for two consecutive incoming link state messages; this ensures that a
suspected gap is not confirmed until both LANs in a dual LAN network have
had an opportunity to deliver the message, thereby preventing spurious NACKs.
A NACK message can also be generated by the arrival of a single link state
message, if the deferred queue is so big that the current message gap
cannot be the result of "normal" mis-ordering due to the use of dual LANs
(or one LAN using a bonded interface). Since link state messages typically
arrive at different nodes at different times the problem of multiple nodes
issuing identical NACKs simultaneously is inherently avoided.
3) Nodes continue to "peek" at NACK messages sent by other nodes. If
another node requests retransmission of a message gap suspected (but not
yet confirmed) by the peeking node, the peeking node forgets about the
gap and does not generate a duplicate retransmit request. (If the peeking
node subsequently fails to receive the lost message, later link state
messages will cause it to rediscover and confirm the gap and send another
NACK.)
4) Message gap "equality" is now determined by the start of the gap only.
This is sufficient to deal with the most common cases of message loss,
and eliminates the need for complex end of gap computations.
5) A peeking node no longer tries to determine whether it should send a
complementary NACK, since the most common cases of message loss don't
require it to be sent. Consequently, the node no longer examines the
"broadcast tag" field of a NACK message when peeking.
Signed-off-by: Allan Stephens <allan.stephens@windriver.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2011-10-28 02:17:53 +08:00
|
|
|
node->bclink.last_sent = less_eq(node->bclink.last_sent, seqno) ?
|
|
|
|
seqno : node->bclink.last_sent;
|
2006-01-03 02:04:38 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
2012-07-10 18:55:09 +08:00
|
|
|
/**
|
2011-01-19 02:53:16 +08:00
|
|
|
* tipc_bclink_retransmit_to - get most recent node to request retransmission
|
|
|
|
*
|
|
|
|
* Called with bc_lock locked
|
|
|
|
*/
|
|
|
|
struct tipc_node *tipc_bclink_retransmit_to(void)
|
|
|
|
{
|
|
|
|
return bclink->retransmit_to;
|
|
|
|
}
|
|
|
|
|
2007-02-09 22:25:21 +08:00
|
|
|
/**
|
2006-01-03 02:04:38 +08:00
|
|
|
* bclink_retransmit_pkt - retransmit broadcast packets
|
|
|
|
* @after: sequence number of last packet to *not* retransmit
|
|
|
|
* @to: sequence number of last packet to retransmit
|
2007-02-09 22:25:21 +08:00
|
|
|
*
|
2006-06-26 14:40:01 +08:00
|
|
|
* Called with bc_lock locked
|
2006-01-03 02:04:38 +08:00
|
|
|
*/
|
|
|
|
static void bclink_retransmit_pkt(u32 after, u32 to)
|
|
|
|
{
|
|
|
|
struct sk_buff *buf;
|
|
|
|
|
|
|
|
buf = bcl->first_out;
|
2011-01-01 02:59:35 +08:00
|
|
|
while (buf && less_eq(buf_seqno(buf), after))
|
2007-02-09 22:25:21 +08:00
|
|
|
buf = buf->next;
|
2006-06-26 14:40:01 +08:00
|
|
|
tipc_link_retransmit(bcl, buf, mod(to - after));
|
2006-01-03 02:04:38 +08:00
|
|
|
}
|
|
|
|
|
2007-02-09 22:25:21 +08:00
|
|
|
/**
|
2006-01-18 07:38:21 +08:00
|
|
|
* tipc_bclink_acknowledge - handle acknowledgement of broadcast packets
|
2006-01-03 02:04:38 +08:00
|
|
|
* @n_ptr: node that sent acknowledgement info
|
|
|
|
* @acked: broadcast sequence # that has been acknowledged
|
2007-02-09 22:25:21 +08:00
|
|
|
*
|
2006-01-03 02:04:38 +08:00
|
|
|
* Node is locked, bc_lock unlocked.
|
|
|
|
*/
|
2008-09-03 14:38:32 +08:00
|
|
|
void tipc_bclink_acknowledge(struct tipc_node *n_ptr, u32 acked)
|
2006-01-03 02:04:38 +08:00
|
|
|
{
|
|
|
|
struct sk_buff *crs;
|
|
|
|
struct sk_buff *next;
|
|
|
|
unsigned int released = 0;
|
|
|
|
|
|
|
|
spin_lock_bh(&bc_lock);
|
|
|
|
|
2011-10-25 03:26:24 +08:00
|
|
|
/* Bail out if tx queue is empty (no clean up is required) */
|
2006-01-03 02:04:38 +08:00
|
|
|
crs = bcl->first_out;
|
2011-10-25 03:26:24 +08:00
|
|
|
if (!crs)
|
|
|
|
goto exit;
|
|
|
|
|
|
|
|
/* Determine which messages need to be acknowledged */
|
|
|
|
if (acked == INVALID_LINK_SEQ) {
|
|
|
|
/*
|
|
|
|
* Contact with specified node has been lost, so need to
|
|
|
|
* acknowledge sent messages only (if other nodes still exist)
|
|
|
|
* or both sent and unsent messages (otherwise)
|
|
|
|
*/
|
|
|
|
if (bclink->bcast_nodes.count)
|
|
|
|
acked = bcl->fsm_msg_cnt;
|
|
|
|
else
|
|
|
|
acked = bcl->next_out_no;
|
|
|
|
} else {
|
|
|
|
/*
|
|
|
|
* Bail out if specified sequence number does not correspond
|
|
|
|
* to a message that has been sent and not yet acknowledged
|
|
|
|
*/
|
|
|
|
if (less(acked, buf_seqno(crs)) ||
|
|
|
|
less(bcl->fsm_msg_cnt, acked) ||
|
|
|
|
less_eq(acked, n_ptr->bclink.acked))
|
|
|
|
goto exit;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Skip over packets that node has previously acknowledged */
|
2011-01-01 02:59:35 +08:00
|
|
|
while (crs && less_eq(buf_seqno(crs), n_ptr->bclink.acked))
|
2006-01-03 02:04:38 +08:00
|
|
|
crs = crs->next;
|
|
|
|
|
|
|
|
/* Update packets that node is now acknowledging */
|
|
|
|
|
|
|
|
while (crs && less_eq(buf_seqno(crs), acked)) {
|
|
|
|
next = crs->next;
|
2011-10-25 02:59:20 +08:00
|
|
|
|
|
|
|
if (crs != bcl->next_out)
|
|
|
|
bcbuf_decr_acks(crs);
|
|
|
|
else {
|
|
|
|
bcbuf_set_acks(crs, 0);
|
|
|
|
bcl->next_out = next;
|
|
|
|
bclink_set_last_sent();
|
|
|
|
}
|
|
|
|
|
2006-01-03 02:04:38 +08:00
|
|
|
if (bcbuf_acks(crs) == 0) {
|
|
|
|
bcl->first_out = next;
|
|
|
|
bcl->out_queue_size--;
|
2011-11-05 01:24:29 +08:00
|
|
|
kfree_skb(crs);
|
2006-01-03 02:04:38 +08:00
|
|
|
released = 1;
|
|
|
|
}
|
|
|
|
crs = next;
|
|
|
|
}
|
|
|
|
n_ptr->bclink.acked = acked;
|
|
|
|
|
|
|
|
/* Try resolving broadcast link congestion, if necessary */
|
|
|
|
|
2010-08-17 19:00:09 +08:00
|
|
|
if (unlikely(bcl->next_out)) {
|
2006-01-18 07:38:21 +08:00
|
|
|
tipc_link_push_queue(bcl);
|
2010-08-17 19:00:09 +08:00
|
|
|
bclink_set_last_sent();
|
|
|
|
}
|
2006-01-03 02:04:38 +08:00
|
|
|
if (unlikely(released && !list_empty(&bcl->waiting_ports)))
|
2006-01-18 07:38:21 +08:00
|
|
|
tipc_link_wakeup_ports(bcl, 0);
|
2011-10-25 03:26:24 +08:00
|
|
|
exit:
|
2006-01-03 02:04:38 +08:00
|
|
|
spin_unlock_bh(&bc_lock);
|
|
|
|
}
|
|
|
|
|
2012-07-10 18:55:09 +08:00
|
|
|
/**
|
tipc: Major redesign of broadcast link ACK/NACK algorithms
Completely redesigns broadcast link ACK and NACK mechanisms to prevent
spurious retransmit requests in dual LAN networks, and to prevent the
broadcast link from stalling due to the failure of a receiving node to
acknowledge receiving a broadcast message or request its retransmission.
Note: These changes only impact the timing of when ACK and NACK messages
are sent, and not the basic broadcast link protocol itself, so inter-
operability with nodes using the "classic" algorithms is maintained.
The revised algorithms are as follows:
1) An explicit ACK message is still sent after receiving 16 in-sequence
messages, and implicit ACK information continues to be carried in other
unicast link message headers (including link state messages). However,
the timing of explicit ACKs is now based on the receiving node's absolute
network address rather than its relative network address to ensure that
the failure of another node does not delay the ACK beyond its 16 message
target.
2) A NACK message is now typically sent only when a message gap persists
for two consecutive incoming link state messages; this ensures that a
suspected gap is not confirmed until both LANs in a dual LAN network have
had an opportunity to deliver the message, thereby preventing spurious NACKs.
A NACK message can also be generated by the arrival of a single link state
message, if the deferred queue is so big that the current message gap
cannot be the result of "normal" mis-ordering due to the use of dual LANs
(or one LAN using a bonded interface). Since link state messages typically
arrive at different nodes at different times the problem of multiple nodes
issuing identical NACKs simultaneously is inherently avoided.
3) Nodes continue to "peek" at NACK messages sent by other nodes. If
another node requests retransmission of a message gap suspected (but not
yet confirmed) by the peeking node, the peeking node forgets about the
gap and does not generate a duplicate retransmit request. (If the peeking
node subsequently fails to receive the lost message, later link state
messages will cause it to rediscover and confirm the gap and send another
NACK.)
4) Message gap "equality" is now determined by the start of the gap only.
This is sufficient to deal with the most common cases of message loss,
and eliminates the need for complex end of gap computations.
5) A peeking node no longer tries to determine whether it should send a
complementary NACK, since the most common cases of message loss don't
require it to be sent. Consequently, the node no longer examines the
"broadcast tag" field of a NACK message when peeking.
Signed-off-by: Allan Stephens <allan.stephens@windriver.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2011-10-28 02:17:53 +08:00
|
|
|
* tipc_bclink_update_link_state - update broadcast link state
|
2007-02-09 22:25:21 +08:00
|
|
|
*
|
2006-01-18 07:38:21 +08:00
|
|
|
* tipc_net_lock and node lock set
|
2006-01-03 02:04:38 +08:00
|
|
|
*/
|
tipc: Major redesign of broadcast link ACK/NACK algorithms
Completely redesigns broadcast link ACK and NACK mechanisms to prevent
spurious retransmit requests in dual LAN networks, and to prevent the
broadcast link from stalling due to the failure of a receiving node to
acknowledge receiving a broadcast message or request its retransmission.
Note: These changes only impact the timing of when ACK and NACK messages
are sent, and not the basic broadcast link protocol itself, so inter-
operability with nodes using the "classic" algorithms is maintained.
The revised algorithms are as follows:
1) An explicit ACK message is still sent after receiving 16 in-sequence
messages, and implicit ACK information continues to be carried in other
unicast link message headers (including link state messages). However,
the timing of explicit ACKs is now based on the receiving node's absolute
network address rather than its relative network address to ensure that
the failure of another node does not delay the ACK beyond its 16 message
target.
2) A NACK message is now typically sent only when a message gap persists
for two consecutive incoming link state messages; this ensures that a
suspected gap is not confirmed until both LANs in a dual LAN network have
had an opportunity to deliver the message, thereby preventing spurious NACKs.
A NACK message can also be generated by the arrival of a single link state
message, if the deferred queue is so big that the current message gap
cannot be the result of "normal" mis-ordering due to the use of dual LANs
(or one LAN using a bonded interface). Since link state messages typically
arrive at different nodes at different times the problem of multiple nodes
issuing identical NACKs simultaneously is inherently avoided.
3) Nodes continue to "peek" at NACK messages sent by other nodes. If
another node requests retransmission of a message gap suspected (but not
yet confirmed) by the peeking node, the peeking node forgets about the
gap and does not generate a duplicate retransmit request. (If the peeking
node subsequently fails to receive the lost message, later link state
messages will cause it to rediscover and confirm the gap and send another
NACK.)
4) Message gap "equality" is now determined by the start of the gap only.
This is sufficient to deal with the most common cases of message loss,
and eliminates the need for complex end of gap computations.
5) A peeking node no longer tries to determine whether it should send a
complementary NACK, since the most common cases of message loss don't
require it to be sent. Consequently, the node no longer examines the
"broadcast tag" field of a NACK message when peeking.
Signed-off-by: Allan Stephens <allan.stephens@windriver.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2011-10-28 02:17:53 +08:00
|
|
|
void tipc_bclink_update_link_state(struct tipc_node *n_ptr, u32 last_sent)
|
2006-01-03 02:04:38 +08:00
|
|
|
{
|
tipc: Major redesign of broadcast link ACK/NACK algorithms
Completely redesigns broadcast link ACK and NACK mechanisms to prevent
spurious retransmit requests in dual LAN networks, and to prevent the
broadcast link from stalling due to the failure of a receiving node to
acknowledge receiving a broadcast message or request its retransmission.
Note: These changes only impact the timing of when ACK and NACK messages
are sent, and not the basic broadcast link protocol itself, so inter-
operability with nodes using the "classic" algorithms is maintained.
The revised algorithms are as follows:
1) An explicit ACK message is still sent after receiving 16 in-sequence
messages, and implicit ACK information continues to be carried in other
unicast link message headers (including link state messages). However,
the timing of explicit ACKs is now based on the receiving node's absolute
network address rather than its relative network address to ensure that
the failure of another node does not delay the ACK beyond its 16 message
target.
2) A NACK message is now typically sent only when a message gap persists
for two consecutive incoming link state messages; this ensures that a
suspected gap is not confirmed until both LANs in a dual LAN network have
had an opportunity to deliver the message, thereby preventing spurious NACKs.
A NACK message can also be generated by the arrival of a single link state
message, if the deferred queue is so big that the current message gap
cannot be the result of "normal" mis-ordering due to the use of dual LANs
(or one LAN using a bonded interface). Since link state messages typically
arrive at different nodes at different times the problem of multiple nodes
issuing identical NACKs simultaneously is inherently avoided.
3) Nodes continue to "peek" at NACK messages sent by other nodes. If
another node requests retransmission of a message gap suspected (but not
yet confirmed) by the peeking node, the peeking node forgets about the
gap and does not generate a duplicate retransmit request. (If the peeking
node subsequently fails to receive the lost message, later link state
messages will cause it to rediscover and confirm the gap and send another
NACK.)
4) Message gap "equality" is now determined by the start of the gap only.
This is sufficient to deal with the most common cases of message loss,
and eliminates the need for complex end of gap computations.
5) A peeking node no longer tries to determine whether it should send a
complementary NACK, since the most common cases of message loss don't
require it to be sent. Consequently, the node no longer examines the
"broadcast tag" field of a NACK message when peeking.
Signed-off-by: Allan Stephens <allan.stephens@windriver.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2011-10-28 02:17:53 +08:00
|
|
|
struct sk_buff *buf;
|
2006-01-03 02:04:38 +08:00
|
|
|
|
tipc: Major redesign of broadcast link ACK/NACK algorithms
Completely redesigns broadcast link ACK and NACK mechanisms to prevent
spurious retransmit requests in dual LAN networks, and to prevent the
broadcast link from stalling due to the failure of a receiving node to
acknowledge receiving a broadcast message or request its retransmission.
Note: These changes only impact the timing of when ACK and NACK messages
are sent, and not the basic broadcast link protocol itself, so inter-
operability with nodes using the "classic" algorithms is maintained.
The revised algorithms are as follows:
1) An explicit ACK message is still sent after receiving 16 in-sequence
messages, and implicit ACK information continues to be carried in other
unicast link message headers (including link state messages). However,
the timing of explicit ACKs is now based on the receiving node's absolute
network address rather than its relative network address to ensure that
the failure of another node does not delay the ACK beyond its 16 message
target.
2) A NACK message is now typically sent only when a message gap persists
for two consecutive incoming link state messages; this ensures that a
suspected gap is not confirmed until both LANs in a dual LAN network have
had an opportunity to deliver the message, thereby preventing spurious NACKs.
A NACK message can also be generated by the arrival of a single link state
message, if the deferred queue is so big that the current message gap
cannot be the result of "normal" mis-ordering due to the use of dual LANs
(or one LAN using a bonded interface). Since link state messages typically
arrive at different nodes at different times the problem of multiple nodes
issuing identical NACKs simultaneously is inherently avoided.
3) Nodes continue to "peek" at NACK messages sent by other nodes. If
another node requests retransmission of a message gap suspected (but not
yet confirmed) by the peeking node, the peeking node forgets about the
gap and does not generate a duplicate retransmit request. (If the peeking
node subsequently fails to receive the lost message, later link state
messages will cause it to rediscover and confirm the gap and send another
NACK.)
4) Message gap "equality" is now determined by the start of the gap only.
This is sufficient to deal with the most common cases of message loss,
and eliminates the need for complex end of gap computations.
5) A peeking node no longer tries to determine whether it should send a
complementary NACK, since the most common cases of message loss don't
require it to be sent. Consequently, the node no longer examines the
"broadcast tag" field of a NACK message when peeking.
Signed-off-by: Allan Stephens <allan.stephens@windriver.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2011-10-28 02:17:53 +08:00
|
|
|
/* Ignore "stale" link state info */
|
2006-01-03 02:04:38 +08:00
|
|
|
|
tipc: Major redesign of broadcast link ACK/NACK algorithms
Completely redesigns broadcast link ACK and NACK mechanisms to prevent
spurious retransmit requests in dual LAN networks, and to prevent the
broadcast link from stalling due to the failure of a receiving node to
acknowledge receiving a broadcast message or request its retransmission.
Note: These changes only impact the timing of when ACK and NACK messages
are sent, and not the basic broadcast link protocol itself, so inter-
operability with nodes using the "classic" algorithms is maintained.
The revised algorithms are as follows:
1) An explicit ACK message is still sent after receiving 16 in-sequence
messages, and implicit ACK information continues to be carried in other
unicast link message headers (including link state messages). However,
the timing of explicit ACKs is now based on the receiving node's absolute
network address rather than its relative network address to ensure that
the failure of another node does not delay the ACK beyond its 16 message
target.
2) A NACK message is now typically sent only when a message gap persists
for two consecutive incoming link state messages; this ensures that a
suspected gap is not confirmed until both LANs in a dual LAN network have
had an opportunity to deliver the message, thereby preventing spurious NACKs.
A NACK message can also be generated by the arrival of a single link state
message, if the deferred queue is so big that the current message gap
cannot be the result of "normal" mis-ordering due to the use of dual LANs
(or one LAN using a bonded interface). Since link state messages typically
arrive at different nodes at different times the problem of multiple nodes
issuing identical NACKs simultaneously is inherently avoided.
3) Nodes continue to "peek" at NACK messages sent by other nodes. If
another node requests retransmission of a message gap suspected (but not
yet confirmed) by the peeking node, the peeking node forgets about the
gap and does not generate a duplicate retransmit request. (If the peeking
node subsequently fails to receive the lost message, later link state
messages will cause it to rediscover and confirm the gap and send another
NACK.)
4) Message gap "equality" is now determined by the start of the gap only.
This is sufficient to deal with the most common cases of message loss,
and eliminates the need for complex end of gap computations.
5) A peeking node no longer tries to determine whether it should send a
complementary NACK, since the most common cases of message loss don't
require it to be sent. Consequently, the node no longer examines the
"broadcast tag" field of a NACK message when peeking.
Signed-off-by: Allan Stephens <allan.stephens@windriver.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2011-10-28 02:17:53 +08:00
|
|
|
if (less_eq(last_sent, n_ptr->bclink.last_in))
|
|
|
|
return;
|
2006-01-03 02:04:38 +08:00
|
|
|
|
tipc: Major redesign of broadcast link ACK/NACK algorithms
Completely redesigns broadcast link ACK and NACK mechanisms to prevent
spurious retransmit requests in dual LAN networks, and to prevent the
broadcast link from stalling due to the failure of a receiving node to
acknowledge receiving a broadcast message or request its retransmission.
Note: These changes only impact the timing of when ACK and NACK messages
are sent, and not the basic broadcast link protocol itself, so inter-
operability with nodes using the "classic" algorithms is maintained.
The revised algorithms are as follows:
1) An explicit ACK message is still sent after receiving 16 in-sequence
messages, and implicit ACK information continues to be carried in other
unicast link message headers (including link state messages). However,
the timing of explicit ACKs is now based on the receiving node's absolute
network address rather than its relative network address to ensure that
the failure of another node does not delay the ACK beyond its 16 message
target.
2) A NACK message is now typically sent only when a message gap persists
for two consecutive incoming link state messages; this ensures that a
suspected gap is not confirmed until both LANs in a dual LAN network have
had an opportunity to deliver the message, thereby preventing spurious NACKs.
A NACK message can also be generated by the arrival of a single link state
message, if the deferred queue is so big that the current message gap
cannot be the result of "normal" mis-ordering due to the use of dual LANs
(or one LAN using a bonded interface). Since link state messages typically
arrive at different nodes at different times the problem of multiple nodes
issuing identical NACKs simultaneously is inherently avoided.
3) Nodes continue to "peek" at NACK messages sent by other nodes. If
another node requests retransmission of a message gap suspected (but not
yet confirmed) by the peeking node, the peeking node forgets about the
gap and does not generate a duplicate retransmit request. (If the peeking
node subsequently fails to receive the lost message, later link state
messages will cause it to rediscover and confirm the gap and send another
NACK.)
4) Message gap "equality" is now determined by the start of the gap only.
This is sufficient to deal with the most common cases of message loss,
and eliminates the need for complex end of gap computations.
5) A peeking node no longer tries to determine whether it should send a
complementary NACK, since the most common cases of message loss don't
require it to be sent. Consequently, the node no longer examines the
"broadcast tag" field of a NACK message when peeking.
Signed-off-by: Allan Stephens <allan.stephens@windriver.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2011-10-28 02:17:53 +08:00
|
|
|
/* Update link synchronization state; quit if in sync */
|
|
|
|
|
|
|
|
bclink_update_last_sent(n_ptr, last_sent);
|
|
|
|
|
|
|
|
if (n_ptr->bclink.last_sent == n_ptr->bclink.last_in)
|
|
|
|
return;
|
|
|
|
|
|
|
|
/* Update out-of-sync state; quit if loss is still unconfirmed */
|
|
|
|
|
|
|
|
if ((++n_ptr->bclink.oos_state) == 1) {
|
|
|
|
if (n_ptr->bclink.deferred_size < (TIPC_MIN_LINK_WIN / 2))
|
|
|
|
return;
|
|
|
|
n_ptr->bclink.oos_state++;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Don't NACK if one has been recently sent (or seen) */
|
2006-01-03 02:04:38 +08:00
|
|
|
|
tipc: Major redesign of broadcast link ACK/NACK algorithms
Completely redesigns broadcast link ACK and NACK mechanisms to prevent
spurious retransmit requests in dual LAN networks, and to prevent the
broadcast link from stalling due to the failure of a receiving node to
acknowledge receiving a broadcast message or request its retransmission.
Note: These changes only impact the timing of when ACK and NACK messages
are sent, and not the basic broadcast link protocol itself, so inter-
operability with nodes using the "classic" algorithms is maintained.
The revised algorithms are as follows:
1) An explicit ACK message is still sent after receiving 16 in-sequence
messages, and implicit ACK information continues to be carried in other
unicast link message headers (including link state messages). However,
the timing of explicit ACKs is now based on the receiving node's absolute
network address rather than its relative network address to ensure that
the failure of another node does not delay the ACK beyond its 16 message
target.
2) A NACK message is now typically sent only when a message gap persists
for two consecutive incoming link state messages; this ensures that a
suspected gap is not confirmed until both LANs in a dual LAN network have
had an opportunity to deliver the message, thereby preventing spurious NACKs.
A NACK message can also be generated by the arrival of a single link state
message, if the deferred queue is so big that the current message gap
cannot be the result of "normal" mis-ordering due to the use of dual LANs
(or one LAN using a bonded interface). Since link state messages typically
arrive at different nodes at different times the problem of multiple nodes
issuing identical NACKs simultaneously is inherently avoided.
3) Nodes continue to "peek" at NACK messages sent by other nodes. If
another node requests retransmission of a message gap suspected (but not
yet confirmed) by the peeking node, the peeking node forgets about the
gap and does not generate a duplicate retransmit request. (If the peeking
node subsequently fails to receive the lost message, later link state
messages will cause it to rediscover and confirm the gap and send another
NACK.)
4) Message gap "equality" is now determined by the start of the gap only.
This is sufficient to deal with the most common cases of message loss,
and eliminates the need for complex end of gap computations.
5) A peeking node no longer tries to determine whether it should send a
complementary NACK, since the most common cases of message loss don't
require it to be sent. Consequently, the node no longer examines the
"broadcast tag" field of a NACK message when peeking.
Signed-off-by: Allan Stephens <allan.stephens@windriver.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2011-10-28 02:17:53 +08:00
|
|
|
if (n_ptr->bclink.oos_state & 0x1)
|
2006-01-03 02:04:38 +08:00
|
|
|
return;
|
|
|
|
|
tipc: Major redesign of broadcast link ACK/NACK algorithms
Completely redesigns broadcast link ACK and NACK mechanisms to prevent
spurious retransmit requests in dual LAN networks, and to prevent the
broadcast link from stalling due to the failure of a receiving node to
acknowledge receiving a broadcast message or request its retransmission.
Note: These changes only impact the timing of when ACK and NACK messages
are sent, and not the basic broadcast link protocol itself, so inter-
operability with nodes using the "classic" algorithms is maintained.
The revised algorithms are as follows:
1) An explicit ACK message is still sent after receiving 16 in-sequence
messages, and implicit ACK information continues to be carried in other
unicast link message headers (including link state messages). However,
the timing of explicit ACKs is now based on the receiving node's absolute
network address rather than its relative network address to ensure that
the failure of another node does not delay the ACK beyond its 16 message
target.
2) A NACK message is now typically sent only when a message gap persists
for two consecutive incoming link state messages; this ensures that a
suspected gap is not confirmed until both LANs in a dual LAN network have
had an opportunity to deliver the message, thereby preventing spurious NACKs.
A NACK message can also be generated by the arrival of a single link state
message, if the deferred queue is so big that the current message gap
cannot be the result of "normal" mis-ordering due to the use of dual LANs
(or one LAN using a bonded interface). Since link state messages typically
arrive at different nodes at different times the problem of multiple nodes
issuing identical NACKs simultaneously is inherently avoided.
3) Nodes continue to "peek" at NACK messages sent by other nodes. If
another node requests retransmission of a message gap suspected (but not
yet confirmed) by the peeking node, the peeking node forgets about the
gap and does not generate a duplicate retransmit request. (If the peeking
node subsequently fails to receive the lost message, later link state
messages will cause it to rediscover and confirm the gap and send another
NACK.)
4) Message gap "equality" is now determined by the start of the gap only.
This is sufficient to deal with the most common cases of message loss,
and eliminates the need for complex end of gap computations.
5) A peeking node no longer tries to determine whether it should send a
complementary NACK, since the most common cases of message loss don't
require it to be sent. Consequently, the node no longer examines the
"broadcast tag" field of a NACK message when peeking.
Signed-off-by: Allan Stephens <allan.stephens@windriver.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2011-10-28 02:17:53 +08:00
|
|
|
/* Send NACK */
|
|
|
|
|
2010-10-13 21:20:35 +08:00
|
|
|
buf = tipc_buf_acquire(INT_H_SIZE);
|
2006-01-03 02:04:38 +08:00
|
|
|
if (buf) {
|
tipc: Major redesign of broadcast link ACK/NACK algorithms
Completely redesigns broadcast link ACK and NACK mechanisms to prevent
spurious retransmit requests in dual LAN networks, and to prevent the
broadcast link from stalling due to the failure of a receiving node to
acknowledge receiving a broadcast message or request its retransmission.
Note: These changes only impact the timing of when ACK and NACK messages
are sent, and not the basic broadcast link protocol itself, so inter-
operability with nodes using the "classic" algorithms is maintained.
The revised algorithms are as follows:
1) An explicit ACK message is still sent after receiving 16 in-sequence
messages, and implicit ACK information continues to be carried in other
unicast link message headers (including link state messages). However,
the timing of explicit ACKs is now based on the receiving node's absolute
network address rather than its relative network address to ensure that
the failure of another node does not delay the ACK beyond its 16 message
target.
2) A NACK message is now typically sent only when a message gap persists
for two consecutive incoming link state messages; this ensures that a
suspected gap is not confirmed until both LANs in a dual LAN network have
had an opportunity to deliver the message, thereby preventing spurious NACKs.
A NACK message can also be generated by the arrival of a single link state
message, if the deferred queue is so big that the current message gap
cannot be the result of "normal" mis-ordering due to the use of dual LANs
(or one LAN using a bonded interface). Since link state messages typically
arrive at different nodes at different times the problem of multiple nodes
issuing identical NACKs simultaneously is inherently avoided.
3) Nodes continue to "peek" at NACK messages sent by other nodes. If
another node requests retransmission of a message gap suspected (but not
yet confirmed) by the peeking node, the peeking node forgets about the
gap and does not generate a duplicate retransmit request. (If the peeking
node subsequently fails to receive the lost message, later link state
messages will cause it to rediscover and confirm the gap and send another
NACK.)
4) Message gap "equality" is now determined by the start of the gap only.
This is sufficient to deal with the most common cases of message loss,
and eliminates the need for complex end of gap computations.
5) A peeking node no longer tries to determine whether it should send a
complementary NACK, since the most common cases of message loss don't
require it to be sent. Consequently, the node no longer examines the
"broadcast tag" field of a NACK message when peeking.
Signed-off-by: Allan Stephens <allan.stephens@windriver.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2011-10-28 02:17:53 +08:00
|
|
|
struct tipc_msg *msg = buf_msg(buf);
|
|
|
|
|
2010-05-11 22:30:12 +08:00
|
|
|
tipc_msg_init(msg, BCAST_PROTOCOL, STATE_MSG,
|
tipc: Major redesign of broadcast link ACK/NACK algorithms
Completely redesigns broadcast link ACK and NACK mechanisms to prevent
spurious retransmit requests in dual LAN networks, and to prevent the
broadcast link from stalling due to the failure of a receiving node to
acknowledge receiving a broadcast message or request its retransmission.
Note: These changes only impact the timing of when ACK and NACK messages
are sent, and not the basic broadcast link protocol itself, so inter-
operability with nodes using the "classic" algorithms is maintained.
The revised algorithms are as follows:
1) An explicit ACK message is still sent after receiving 16 in-sequence
messages, and implicit ACK information continues to be carried in other
unicast link message headers (including link state messages). However,
the timing of explicit ACKs is now based on the receiving node's absolute
network address rather than its relative network address to ensure that
the failure of another node does not delay the ACK beyond its 16 message
target.
2) A NACK message is now typically sent only when a message gap persists
for two consecutive incoming link state messages; this ensures that a
suspected gap is not confirmed until both LANs in a dual LAN network have
had an opportunity to deliver the message, thereby preventing spurious NACKs.
A NACK message can also be generated by the arrival of a single link state
message, if the deferred queue is so big that the current message gap
cannot be the result of "normal" mis-ordering due to the use of dual LANs
(or one LAN using a bonded interface). Since link state messages typically
arrive at different nodes at different times the problem of multiple nodes
issuing identical NACKs simultaneously is inherently avoided.
3) Nodes continue to "peek" at NACK messages sent by other nodes. If
another node requests retransmission of a message gap suspected (but not
yet confirmed) by the peeking node, the peeking node forgets about the
gap and does not generate a duplicate retransmit request. (If the peeking
node subsequently fails to receive the lost message, later link state
messages will cause it to rediscover and confirm the gap and send another
NACK.)
4) Message gap "equality" is now determined by the start of the gap only.
This is sufficient to deal with the most common cases of message loss,
and eliminates the need for complex end of gap computations.
5) A peeking node no longer tries to determine whether it should send a
complementary NACK, since the most common cases of message loss don't
require it to be sent. Consequently, the node no longer examines the
"broadcast tag" field of a NACK message when peeking.
Signed-off-by: Allan Stephens <allan.stephens@windriver.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2011-10-28 02:17:53 +08:00
|
|
|
INT_H_SIZE, n_ptr->addr);
|
2011-01-26 05:12:39 +08:00
|
|
|
msg_set_non_seq(msg, 1);
|
2006-01-03 02:04:38 +08:00
|
|
|
msg_set_mc_netid(msg, tipc_net_id);
|
tipc: Major redesign of broadcast link ACK/NACK algorithms
Completely redesigns broadcast link ACK and NACK mechanisms to prevent
spurious retransmit requests in dual LAN networks, and to prevent the
broadcast link from stalling due to the failure of a receiving node to
acknowledge receiving a broadcast message or request its retransmission.
Note: These changes only impact the timing of when ACK and NACK messages
are sent, and not the basic broadcast link protocol itself, so inter-
operability with nodes using the "classic" algorithms is maintained.
The revised algorithms are as follows:
1) An explicit ACK message is still sent after receiving 16 in-sequence
messages, and implicit ACK information continues to be carried in other
unicast link message headers (including link state messages). However,
the timing of explicit ACKs is now based on the receiving node's absolute
network address rather than its relative network address to ensure that
the failure of another node does not delay the ACK beyond its 16 message
target.
2) A NACK message is now typically sent only when a message gap persists
for two consecutive incoming link state messages; this ensures that a
suspected gap is not confirmed until both LANs in a dual LAN network have
had an opportunity to deliver the message, thereby preventing spurious NACKs.
A NACK message can also be generated by the arrival of a single link state
message, if the deferred queue is so big that the current message gap
cannot be the result of "normal" mis-ordering due to the use of dual LANs
(or one LAN using a bonded interface). Since link state messages typically
arrive at different nodes at different times the problem of multiple nodes
issuing identical NACKs simultaneously is inherently avoided.
3) Nodes continue to "peek" at NACK messages sent by other nodes. If
another node requests retransmission of a message gap suspected (but not
yet confirmed) by the peeking node, the peeking node forgets about the
gap and does not generate a duplicate retransmit request. (If the peeking
node subsequently fails to receive the lost message, later link state
messages will cause it to rediscover and confirm the gap and send another
NACK.)
4) Message gap "equality" is now determined by the start of the gap only.
This is sufficient to deal with the most common cases of message loss,
and eliminates the need for complex end of gap computations.
5) A peeking node no longer tries to determine whether it should send a
complementary NACK, since the most common cases of message loss don't
require it to be sent. Consequently, the node no longer examines the
"broadcast tag" field of a NACK message when peeking.
Signed-off-by: Allan Stephens <allan.stephens@windriver.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2011-10-28 02:17:53 +08:00
|
|
|
msg_set_bcast_ack(msg, n_ptr->bclink.last_in);
|
|
|
|
msg_set_bcgap_after(msg, n_ptr->bclink.last_in);
|
|
|
|
msg_set_bcgap_to(msg, n_ptr->bclink.deferred_head
|
|
|
|
? buf_seqno(n_ptr->bclink.deferred_head) - 1
|
|
|
|
: n_ptr->bclink.last_sent);
|
2006-01-03 02:04:38 +08:00
|
|
|
|
2011-10-26 23:41:45 +08:00
|
|
|
spin_lock_bh(&bc_lock);
|
2011-04-08 03:47:48 +08:00
|
|
|
tipc_bearer_send(&bcbearer->bearer, buf, NULL);
|
|
|
|
bcl->stats.sent_nacks++;
|
2011-10-26 23:41:45 +08:00
|
|
|
spin_unlock_bh(&bc_lock);
|
2011-11-05 01:24:29 +08:00
|
|
|
kfree_skb(buf);
|
2006-01-03 02:04:38 +08:00
|
|
|
|
tipc: Major redesign of broadcast link ACK/NACK algorithms
Completely redesigns broadcast link ACK and NACK mechanisms to prevent
spurious retransmit requests in dual LAN networks, and to prevent the
broadcast link from stalling due to the failure of a receiving node to
acknowledge receiving a broadcast message or request its retransmission.
Note: These changes only impact the timing of when ACK and NACK messages
are sent, and not the basic broadcast link protocol itself, so inter-
operability with nodes using the "classic" algorithms is maintained.
The revised algorithms are as follows:
1) An explicit ACK message is still sent after receiving 16 in-sequence
messages, and implicit ACK information continues to be carried in other
unicast link message headers (including link state messages). However,
the timing of explicit ACKs is now based on the receiving node's absolute
network address rather than its relative network address to ensure that
the failure of another node does not delay the ACK beyond its 16 message
target.
2) A NACK message is now typically sent only when a message gap persists
for two consecutive incoming link state messages; this ensures that a
suspected gap is not confirmed until both LANs in a dual LAN network have
had an opportunity to deliver the message, thereby preventing spurious NACKs.
A NACK message can also be generated by the arrival of a single link state
message, if the deferred queue is so big that the current message gap
cannot be the result of "normal" mis-ordering due to the use of dual LANs
(or one LAN using a bonded interface). Since link state messages typically
arrive at different nodes at different times the problem of multiple nodes
issuing identical NACKs simultaneously is inherently avoided.
3) Nodes continue to "peek" at NACK messages sent by other nodes. If
another node requests retransmission of a message gap suspected (but not
yet confirmed) by the peeking node, the peeking node forgets about the
gap and does not generate a duplicate retransmit request. (If the peeking
node subsequently fails to receive the lost message, later link state
messages will cause it to rediscover and confirm the gap and send another
NACK.)
4) Message gap "equality" is now determined by the start of the gap only.
This is sufficient to deal with the most common cases of message loss,
and eliminates the need for complex end of gap computations.
5) A peeking node no longer tries to determine whether it should send a
complementary NACK, since the most common cases of message loss don't
require it to be sent. Consequently, the node no longer examines the
"broadcast tag" field of a NACK message when peeking.
Signed-off-by: Allan Stephens <allan.stephens@windriver.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2011-10-28 02:17:53 +08:00
|
|
|
n_ptr->bclink.oos_state++;
|
2006-01-03 02:04:38 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2012-07-10 18:55:09 +08:00
|
|
|
/**
|
tipc: Major redesign of broadcast link ACK/NACK algorithms
Completely redesigns broadcast link ACK and NACK mechanisms to prevent
spurious retransmit requests in dual LAN networks, and to prevent the
broadcast link from stalling due to the failure of a receiving node to
acknowledge receiving a broadcast message or request its retransmission.
Note: These changes only impact the timing of when ACK and NACK messages
are sent, and not the basic broadcast link protocol itself, so inter-
operability with nodes using the "classic" algorithms is maintained.
The revised algorithms are as follows:
1) An explicit ACK message is still sent after receiving 16 in-sequence
messages, and implicit ACK information continues to be carried in other
unicast link message headers (including link state messages). However,
the timing of explicit ACKs is now based on the receiving node's absolute
network address rather than its relative network address to ensure that
the failure of another node does not delay the ACK beyond its 16 message
target.
2) A NACK message is now typically sent only when a message gap persists
for two consecutive incoming link state messages; this ensures that a
suspected gap is not confirmed until both LANs in a dual LAN network have
had an opportunity to deliver the message, thereby preventing spurious NACKs.
A NACK message can also be generated by the arrival of a single link state
message, if the deferred queue is so big that the current message gap
cannot be the result of "normal" mis-ordering due to the use of dual LANs
(or one LAN using a bonded interface). Since link state messages typically
arrive at different nodes at different times the problem of multiple nodes
issuing identical NACKs simultaneously is inherently avoided.
3) Nodes continue to "peek" at NACK messages sent by other nodes. If
another node requests retransmission of a message gap suspected (but not
yet confirmed) by the peeking node, the peeking node forgets about the
gap and does not generate a duplicate retransmit request. (If the peeking
node subsequently fails to receive the lost message, later link state
messages will cause it to rediscover and confirm the gap and send another
NACK.)
4) Message gap "equality" is now determined by the start of the gap only.
This is sufficient to deal with the most common cases of message loss,
and eliminates the need for complex end of gap computations.
5) A peeking node no longer tries to determine whether it should send a
complementary NACK, since the most common cases of message loss don't
require it to be sent. Consequently, the node no longer examines the
"broadcast tag" field of a NACK message when peeking.
Signed-off-by: Allan Stephens <allan.stephens@windriver.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2011-10-28 02:17:53 +08:00
|
|
|
* bclink_peek_nack - monitor retransmission requests sent by other nodes
|
2006-01-03 02:04:38 +08:00
|
|
|
*
|
tipc: Major redesign of broadcast link ACK/NACK algorithms
Completely redesigns broadcast link ACK and NACK mechanisms to prevent
spurious retransmit requests in dual LAN networks, and to prevent the
broadcast link from stalling due to the failure of a receiving node to
acknowledge receiving a broadcast message or request its retransmission.
Note: These changes only impact the timing of when ACK and NACK messages
are sent, and not the basic broadcast link protocol itself, so inter-
operability with nodes using the "classic" algorithms is maintained.
The revised algorithms are as follows:
1) An explicit ACK message is still sent after receiving 16 in-sequence
messages, and implicit ACK information continues to be carried in other
unicast link message headers (including link state messages). However,
the timing of explicit ACKs is now based on the receiving node's absolute
network address rather than its relative network address to ensure that
the failure of another node does not delay the ACK beyond its 16 message
target.
2) A NACK message is now typically sent only when a message gap persists
for two consecutive incoming link state messages; this ensures that a
suspected gap is not confirmed until both LANs in a dual LAN network have
had an opportunity to deliver the message, thereby preventing spurious NACKs.
A NACK message can also be generated by the arrival of a single link state
message, if the deferred queue is so big that the current message gap
cannot be the result of "normal" mis-ordering due to the use of dual LANs
(or one LAN using a bonded interface). Since link state messages typically
arrive at different nodes at different times the problem of multiple nodes
issuing identical NACKs simultaneously is inherently avoided.
3) Nodes continue to "peek" at NACK messages sent by other nodes. If
another node requests retransmission of a message gap suspected (but not
yet confirmed) by the peeking node, the peeking node forgets about the
gap and does not generate a duplicate retransmit request. (If the peeking
node subsequently fails to receive the lost message, later link state
messages will cause it to rediscover and confirm the gap and send another
NACK.)
4) Message gap "equality" is now determined by the start of the gap only.
This is sufficient to deal with the most common cases of message loss,
and eliminates the need for complex end of gap computations.
5) A peeking node no longer tries to determine whether it should send a
complementary NACK, since the most common cases of message loss don't
require it to be sent. Consequently, the node no longer examines the
"broadcast tag" field of a NACK message when peeking.
Signed-off-by: Allan Stephens <allan.stephens@windriver.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2011-10-28 02:17:53 +08:00
|
|
|
* Delay any upcoming NACK by this node if another node has already
|
|
|
|
* requested the first message this node is going to ask for.
|
2007-02-09 22:25:21 +08:00
|
|
|
*
|
2006-01-18 07:38:21 +08:00
|
|
|
* Only tipc_net_lock set.
|
2006-01-03 02:04:38 +08:00
|
|
|
*/
|
tipc: Major redesign of broadcast link ACK/NACK algorithms
Completely redesigns broadcast link ACK and NACK mechanisms to prevent
spurious retransmit requests in dual LAN networks, and to prevent the
broadcast link from stalling due to the failure of a receiving node to
acknowledge receiving a broadcast message or request its retransmission.
Note: These changes only impact the timing of when ACK and NACK messages
are sent, and not the basic broadcast link protocol itself, so inter-
operability with nodes using the "classic" algorithms is maintained.
The revised algorithms are as follows:
1) An explicit ACK message is still sent after receiving 16 in-sequence
messages, and implicit ACK information continues to be carried in other
unicast link message headers (including link state messages). However,
the timing of explicit ACKs is now based on the receiving node's absolute
network address rather than its relative network address to ensure that
the failure of another node does not delay the ACK beyond its 16 message
target.
2) A NACK message is now typically sent only when a message gap persists
for two consecutive incoming link state messages; this ensures that a
suspected gap is not confirmed until both LANs in a dual LAN network have
had an opportunity to deliver the message, thereby preventing spurious NACKs.
A NACK message can also be generated by the arrival of a single link state
message, if the deferred queue is so big that the current message gap
cannot be the result of "normal" mis-ordering due to the use of dual LANs
(or one LAN using a bonded interface). Since link state messages typically
arrive at different nodes at different times the problem of multiple nodes
issuing identical NACKs simultaneously is inherently avoided.
3) Nodes continue to "peek" at NACK messages sent by other nodes. If
another node requests retransmission of a message gap suspected (but not
yet confirmed) by the peeking node, the peeking node forgets about the
gap and does not generate a duplicate retransmit request. (If the peeking
node subsequently fails to receive the lost message, later link state
messages will cause it to rediscover and confirm the gap and send another
NACK.)
4) Message gap "equality" is now determined by the start of the gap only.
This is sufficient to deal with the most common cases of message loss,
and eliminates the need for complex end of gap computations.
5) A peeking node no longer tries to determine whether it should send a
complementary NACK, since the most common cases of message loss don't
require it to be sent. Consequently, the node no longer examines the
"broadcast tag" field of a NACK message when peeking.
Signed-off-by: Allan Stephens <allan.stephens@windriver.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2011-10-28 02:17:53 +08:00
|
|
|
static void bclink_peek_nack(struct tipc_msg *msg)
|
2006-01-03 02:04:38 +08:00
|
|
|
{
|
tipc: Major redesign of broadcast link ACK/NACK algorithms
Completely redesigns broadcast link ACK and NACK mechanisms to prevent
spurious retransmit requests in dual LAN networks, and to prevent the
broadcast link from stalling due to the failure of a receiving node to
acknowledge receiving a broadcast message or request its retransmission.
Note: These changes only impact the timing of when ACK and NACK messages
are sent, and not the basic broadcast link protocol itself, so inter-
operability with nodes using the "classic" algorithms is maintained.
The revised algorithms are as follows:
1) An explicit ACK message is still sent after receiving 16 in-sequence
messages, and implicit ACK information continues to be carried in other
unicast link message headers (including link state messages). However,
the timing of explicit ACKs is now based on the receiving node's absolute
network address rather than its relative network address to ensure that
the failure of another node does not delay the ACK beyond its 16 message
target.
2) A NACK message is now typically sent only when a message gap persists
for two consecutive incoming link state messages; this ensures that a
suspected gap is not confirmed until both LANs in a dual LAN network have
had an opportunity to deliver the message, thereby preventing spurious NACKs.
A NACK message can also be generated by the arrival of a single link state
message, if the deferred queue is so big that the current message gap
cannot be the result of "normal" mis-ordering due to the use of dual LANs
(or one LAN using a bonded interface). Since link state messages typically
arrive at different nodes at different times the problem of multiple nodes
issuing identical NACKs simultaneously is inherently avoided.
3) Nodes continue to "peek" at NACK messages sent by other nodes. If
another node requests retransmission of a message gap suspected (but not
yet confirmed) by the peeking node, the peeking node forgets about the
gap and does not generate a duplicate retransmit request. (If the peeking
node subsequently fails to receive the lost message, later link state
messages will cause it to rediscover and confirm the gap and send another
NACK.)
4) Message gap "equality" is now determined by the start of the gap only.
This is sufficient to deal with the most common cases of message loss,
and eliminates the need for complex end of gap computations.
5) A peeking node no longer tries to determine whether it should send a
complementary NACK, since the most common cases of message loss don't
require it to be sent. Consequently, the node no longer examines the
"broadcast tag" field of a NACK message when peeking.
Signed-off-by: Allan Stephens <allan.stephens@windriver.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2011-10-28 02:17:53 +08:00
|
|
|
struct tipc_node *n_ptr = tipc_node_find(msg_destnode(msg));
|
2006-01-03 02:04:38 +08:00
|
|
|
|
tipc: Major redesign of broadcast link ACK/NACK algorithms
Completely redesigns broadcast link ACK and NACK mechanisms to prevent
spurious retransmit requests in dual LAN networks, and to prevent the
broadcast link from stalling due to the failure of a receiving node to
acknowledge receiving a broadcast message or request its retransmission.
Note: These changes only impact the timing of when ACK and NACK messages
are sent, and not the basic broadcast link protocol itself, so inter-
operability with nodes using the "classic" algorithms is maintained.
The revised algorithms are as follows:
1) An explicit ACK message is still sent after receiving 16 in-sequence
messages, and implicit ACK information continues to be carried in other
unicast link message headers (including link state messages). However,
the timing of explicit ACKs is now based on the receiving node's absolute
network address rather than its relative network address to ensure that
the failure of another node does not delay the ACK beyond its 16 message
target.
2) A NACK message is now typically sent only when a message gap persists
for two consecutive incoming link state messages; this ensures that a
suspected gap is not confirmed until both LANs in a dual LAN network have
had an opportunity to deliver the message, thereby preventing spurious NACKs.
A NACK message can also be generated by the arrival of a single link state
message, if the deferred queue is so big that the current message gap
cannot be the result of "normal" mis-ordering due to the use of dual LANs
(or one LAN using a bonded interface). Since link state messages typically
arrive at different nodes at different times the problem of multiple nodes
issuing identical NACKs simultaneously is inherently avoided.
3) Nodes continue to "peek" at NACK messages sent by other nodes. If
another node requests retransmission of a message gap suspected (but not
yet confirmed) by the peeking node, the peeking node forgets about the
gap and does not generate a duplicate retransmit request. (If the peeking
node subsequently fails to receive the lost message, later link state
messages will cause it to rediscover and confirm the gap and send another
NACK.)
4) Message gap "equality" is now determined by the start of the gap only.
This is sufficient to deal with the most common cases of message loss,
and eliminates the need for complex end of gap computations.
5) A peeking node no longer tries to determine whether it should send a
complementary NACK, since the most common cases of message loss don't
require it to be sent. Consequently, the node no longer examines the
"broadcast tag" field of a NACK message when peeking.
Signed-off-by: Allan Stephens <allan.stephens@windriver.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2011-10-28 02:17:53 +08:00
|
|
|
if (unlikely(!n_ptr))
|
2006-01-03 02:04:38 +08:00
|
|
|
return;
|
tipc: Major redesign of broadcast link ACK/NACK algorithms
Completely redesigns broadcast link ACK and NACK mechanisms to prevent
spurious retransmit requests in dual LAN networks, and to prevent the
broadcast link from stalling due to the failure of a receiving node to
acknowledge receiving a broadcast message or request its retransmission.
Note: These changes only impact the timing of when ACK and NACK messages
are sent, and not the basic broadcast link protocol itself, so inter-
operability with nodes using the "classic" algorithms is maintained.
The revised algorithms are as follows:
1) An explicit ACK message is still sent after receiving 16 in-sequence
messages, and implicit ACK information continues to be carried in other
unicast link message headers (including link state messages). However,
the timing of explicit ACKs is now based on the receiving node's absolute
network address rather than its relative network address to ensure that
the failure of another node does not delay the ACK beyond its 16 message
target.
2) A NACK message is now typically sent only when a message gap persists
for two consecutive incoming link state messages; this ensures that a
suspected gap is not confirmed until both LANs in a dual LAN network have
had an opportunity to deliver the message, thereby preventing spurious NACKs.
A NACK message can also be generated by the arrival of a single link state
message, if the deferred queue is so big that the current message gap
cannot be the result of "normal" mis-ordering due to the use of dual LANs
(or one LAN using a bonded interface). Since link state messages typically
arrive at different nodes at different times the problem of multiple nodes
issuing identical NACKs simultaneously is inherently avoided.
3) Nodes continue to "peek" at NACK messages sent by other nodes. If
another node requests retransmission of a message gap suspected (but not
yet confirmed) by the peeking node, the peeking node forgets about the
gap and does not generate a duplicate retransmit request. (If the peeking
node subsequently fails to receive the lost message, later link state
messages will cause it to rediscover and confirm the gap and send another
NACK.)
4) Message gap "equality" is now determined by the start of the gap only.
This is sufficient to deal with the most common cases of message loss,
and eliminates the need for complex end of gap computations.
5) A peeking node no longer tries to determine whether it should send a
complementary NACK, since the most common cases of message loss don't
require it to be sent. Consequently, the node no longer examines the
"broadcast tag" field of a NACK message when peeking.
Signed-off-by: Allan Stephens <allan.stephens@windriver.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2011-10-28 02:17:53 +08:00
|
|
|
|
2006-01-18 07:38:21 +08:00
|
|
|
tipc_node_lock(n_ptr);
|
tipc: Major redesign of broadcast link ACK/NACK algorithms
Completely redesigns broadcast link ACK and NACK mechanisms to prevent
spurious retransmit requests in dual LAN networks, and to prevent the
broadcast link from stalling due to the failure of a receiving node to
acknowledge receiving a broadcast message or request its retransmission.
Note: These changes only impact the timing of when ACK and NACK messages
are sent, and not the basic broadcast link protocol itself, so inter-
operability with nodes using the "classic" algorithms is maintained.
The revised algorithms are as follows:
1) An explicit ACK message is still sent after receiving 16 in-sequence
messages, and implicit ACK information continues to be carried in other
unicast link message headers (including link state messages). However,
the timing of explicit ACKs is now based on the receiving node's absolute
network address rather than its relative network address to ensure that
the failure of another node does not delay the ACK beyond its 16 message
target.
2) A NACK message is now typically sent only when a message gap persists
for two consecutive incoming link state messages; this ensures that a
suspected gap is not confirmed until both LANs in a dual LAN network have
had an opportunity to deliver the message, thereby preventing spurious NACKs.
A NACK message can also be generated by the arrival of a single link state
message, if the deferred queue is so big that the current message gap
cannot be the result of "normal" mis-ordering due to the use of dual LANs
(or one LAN using a bonded interface). Since link state messages typically
arrive at different nodes at different times the problem of multiple nodes
issuing identical NACKs simultaneously is inherently avoided.
3) Nodes continue to "peek" at NACK messages sent by other nodes. If
another node requests retransmission of a message gap suspected (but not
yet confirmed) by the peeking node, the peeking node forgets about the
gap and does not generate a duplicate retransmit request. (If the peeking
node subsequently fails to receive the lost message, later link state
messages will cause it to rediscover and confirm the gap and send another
NACK.)
4) Message gap "equality" is now determined by the start of the gap only.
This is sufficient to deal with the most common cases of message loss,
and eliminates the need for complex end of gap computations.
5) A peeking node no longer tries to determine whether it should send a
complementary NACK, since the most common cases of message loss don't
require it to be sent. Consequently, the node no longer examines the
"broadcast tag" field of a NACK message when peeking.
Signed-off-by: Allan Stephens <allan.stephens@windriver.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2011-10-28 02:17:53 +08:00
|
|
|
|
2012-11-16 13:51:30 +08:00
|
|
|
if (n_ptr->bclink.recv_permitted &&
|
tipc: Major redesign of broadcast link ACK/NACK algorithms
Completely redesigns broadcast link ACK and NACK mechanisms to prevent
spurious retransmit requests in dual LAN networks, and to prevent the
broadcast link from stalling due to the failure of a receiving node to
acknowledge receiving a broadcast message or request its retransmission.
Note: These changes only impact the timing of when ACK and NACK messages
are sent, and not the basic broadcast link protocol itself, so inter-
operability with nodes using the "classic" algorithms is maintained.
The revised algorithms are as follows:
1) An explicit ACK message is still sent after receiving 16 in-sequence
messages, and implicit ACK information continues to be carried in other
unicast link message headers (including link state messages). However,
the timing of explicit ACKs is now based on the receiving node's absolute
network address rather than its relative network address to ensure that
the failure of another node does not delay the ACK beyond its 16 message
target.
2) A NACK message is now typically sent only when a message gap persists
for two consecutive incoming link state messages; this ensures that a
suspected gap is not confirmed until both LANs in a dual LAN network have
had an opportunity to deliver the message, thereby preventing spurious NACKs.
A NACK message can also be generated by the arrival of a single link state
message, if the deferred queue is so big that the current message gap
cannot be the result of "normal" mis-ordering due to the use of dual LANs
(or one LAN using a bonded interface). Since link state messages typically
arrive at different nodes at different times the problem of multiple nodes
issuing identical NACKs simultaneously is inherently avoided.
3) Nodes continue to "peek" at NACK messages sent by other nodes. If
another node requests retransmission of a message gap suspected (but not
yet confirmed) by the peeking node, the peeking node forgets about the
gap and does not generate a duplicate retransmit request. (If the peeking
node subsequently fails to receive the lost message, later link state
messages will cause it to rediscover and confirm the gap and send another
NACK.)
4) Message gap "equality" is now determined by the start of the gap only.
This is sufficient to deal with the most common cases of message loss,
and eliminates the need for complex end of gap computations.
5) A peeking node no longer tries to determine whether it should send a
complementary NACK, since the most common cases of message loss don't
require it to be sent. Consequently, the node no longer examines the
"broadcast tag" field of a NACK message when peeking.
Signed-off-by: Allan Stephens <allan.stephens@windriver.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2011-10-28 02:17:53 +08:00
|
|
|
(n_ptr->bclink.last_in != n_ptr->bclink.last_sent) &&
|
|
|
|
(n_ptr->bclink.last_in == msg_bcgap_after(msg)))
|
|
|
|
n_ptr->bclink.oos_state = 2;
|
|
|
|
|
2006-01-18 07:38:21 +08:00
|
|
|
tipc_node_unlock(n_ptr);
|
2006-01-03 02:04:38 +08:00
|
|
|
}
|
|
|
|
|
tipc: Major redesign of broadcast link ACK/NACK algorithms
Completely redesigns broadcast link ACK and NACK mechanisms to prevent
spurious retransmit requests in dual LAN networks, and to prevent the
broadcast link from stalling due to the failure of a receiving node to
acknowledge receiving a broadcast message or request its retransmission.
Note: These changes only impact the timing of when ACK and NACK messages
are sent, and not the basic broadcast link protocol itself, so inter-
operability with nodes using the "classic" algorithms is maintained.
The revised algorithms are as follows:
1) An explicit ACK message is still sent after receiving 16 in-sequence
messages, and implicit ACK information continues to be carried in other
unicast link message headers (including link state messages). However,
the timing of explicit ACKs is now based on the receiving node's absolute
network address rather than its relative network address to ensure that
the failure of another node does not delay the ACK beyond its 16 message
target.
2) A NACK message is now typically sent only when a message gap persists
for two consecutive incoming link state messages; this ensures that a
suspected gap is not confirmed until both LANs in a dual LAN network have
had an opportunity to deliver the message, thereby preventing spurious NACKs.
A NACK message can also be generated by the arrival of a single link state
message, if the deferred queue is so big that the current message gap
cannot be the result of "normal" mis-ordering due to the use of dual LANs
(or one LAN using a bonded interface). Since link state messages typically
arrive at different nodes at different times the problem of multiple nodes
issuing identical NACKs simultaneously is inherently avoided.
3) Nodes continue to "peek" at NACK messages sent by other nodes. If
another node requests retransmission of a message gap suspected (but not
yet confirmed) by the peeking node, the peeking node forgets about the
gap and does not generate a duplicate retransmit request. (If the peeking
node subsequently fails to receive the lost message, later link state
messages will cause it to rediscover and confirm the gap and send another
NACK.)
4) Message gap "equality" is now determined by the start of the gap only.
This is sufficient to deal with the most common cases of message loss,
and eliminates the need for complex end of gap computations.
5) A peeking node no longer tries to determine whether it should send a
complementary NACK, since the most common cases of message loss don't
require it to be sent. Consequently, the node no longer examines the
"broadcast tag" field of a NACK message when peeking.
Signed-off-by: Allan Stephens <allan.stephens@windriver.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2011-10-28 02:17:53 +08:00
|
|
|
/*
|
2014-02-18 16:06:46 +08:00
|
|
|
* tipc_bclink_xmit - broadcast a packet to all nodes in cluster
|
2006-01-03 02:04:38 +08:00
|
|
|
*/
|
2014-02-18 16:06:46 +08:00
|
|
|
int tipc_bclink_xmit(struct sk_buff *buf)
|
2006-01-03 02:04:38 +08:00
|
|
|
{
|
|
|
|
int res;
|
|
|
|
|
|
|
|
spin_lock_bh(&bc_lock);
|
|
|
|
|
2011-10-25 01:05:55 +08:00
|
|
|
if (!bclink->bcast_nodes.count) {
|
|
|
|
res = msg_data_sz(buf_msg(buf));
|
2011-11-05 01:24:29 +08:00
|
|
|
kfree_skb(buf);
|
2011-10-25 01:05:55 +08:00
|
|
|
goto exit;
|
|
|
|
}
|
|
|
|
|
2014-02-18 16:06:46 +08:00
|
|
|
res = __tipc_link_xmit(bcl, buf);
|
2011-10-25 01:27:31 +08:00
|
|
|
if (likely(res >= 0)) {
|
2010-08-17 19:00:09 +08:00
|
|
|
bclink_set_last_sent();
|
2011-10-25 01:27:31 +08:00
|
|
|
bcl->stats.queue_sz_counts++;
|
|
|
|
bcl->stats.accu_queue_sz += bcl->out_queue_size;
|
|
|
|
}
|
2011-10-25 01:05:55 +08:00
|
|
|
exit:
|
2006-01-03 02:04:38 +08:00
|
|
|
spin_unlock_bh(&bc_lock);
|
|
|
|
return res;
|
|
|
|
}
|
|
|
|
|
2012-07-10 18:55:09 +08:00
|
|
|
/**
|
2011-10-28 04:43:09 +08:00
|
|
|
* bclink_accept_pkt - accept an incoming, in-sequence broadcast packet
|
|
|
|
*
|
|
|
|
* Called with both sending node's lock and bc_lock taken.
|
|
|
|
*/
|
|
|
|
static void bclink_accept_pkt(struct tipc_node *node, u32 seqno)
|
|
|
|
{
|
|
|
|
bclink_update_last_sent(node, seqno);
|
|
|
|
node->bclink.last_in = seqno;
|
|
|
|
node->bclink.oos_state = 0;
|
|
|
|
bcl->stats.recv_info++;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Unicast an ACK periodically, ensuring that
|
|
|
|
* all nodes in the cluster don't ACK at the same time
|
|
|
|
*/
|
|
|
|
|
|
|
|
if (((seqno - tipc_own_addr) % TIPC_MIN_LINK_WIN) == 0) {
|
2014-02-18 16:06:46 +08:00
|
|
|
tipc_link_proto_xmit(node->active_links[node->addr & 1],
|
|
|
|
STATE_MSG, 0, 0, 0, 0, 0);
|
2011-10-28 04:43:09 +08:00
|
|
|
bcl->stats.sent_acks++;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2012-07-10 18:55:09 +08:00
|
|
|
/**
|
2014-02-18 16:06:46 +08:00
|
|
|
* tipc_bclink_rcv - receive a broadcast packet, and deliver upwards
|
2007-02-09 22:25:21 +08:00
|
|
|
*
|
2006-01-18 07:38:21 +08:00
|
|
|
* tipc_net_lock is read_locked, no other locks set
|
2006-01-03 02:04:38 +08:00
|
|
|
*/
|
2014-02-18 16:06:46 +08:00
|
|
|
void tipc_bclink_rcv(struct sk_buff *buf)
|
2006-06-26 14:40:01 +08:00
|
|
|
{
|
2006-01-03 02:04:38 +08:00
|
|
|
struct tipc_msg *msg = buf_msg(buf);
|
2011-04-08 01:57:25 +08:00
|
|
|
struct tipc_node *node;
|
2006-01-03 02:04:38 +08:00
|
|
|
u32 next_in;
|
|
|
|
u32 seqno;
|
2011-10-27 03:33:44 +08:00
|
|
|
int deferred;
|
2006-01-03 02:04:38 +08:00
|
|
|
|
2011-04-08 01:57:25 +08:00
|
|
|
/* Screen out unwanted broadcast messages */
|
|
|
|
|
|
|
|
if (msg_mc_netid(msg) != tipc_net_id)
|
|
|
|
goto exit;
|
|
|
|
|
|
|
|
node = tipc_node_find(msg_prevnode(msg));
|
|
|
|
if (unlikely(!node))
|
|
|
|
goto exit;
|
|
|
|
|
|
|
|
tipc_node_lock(node);
|
2012-11-16 13:51:30 +08:00
|
|
|
if (unlikely(!node->bclink.recv_permitted))
|
2011-04-08 01:57:25 +08:00
|
|
|
goto unlock;
|
2006-01-03 02:04:38 +08:00
|
|
|
|
2011-10-27 03:33:44 +08:00
|
|
|
/* Handle broadcast protocol message */
|
|
|
|
|
2006-01-03 02:04:38 +08:00
|
|
|
if (unlikely(msg_user(msg) == BCAST_PROTOCOL)) {
|
2011-04-08 02:57:53 +08:00
|
|
|
if (msg_type(msg) != STATE_MSG)
|
|
|
|
goto unlock;
|
2006-01-03 02:04:38 +08:00
|
|
|
if (msg_destnode(msg) == tipc_own_addr) {
|
2006-01-18 07:38:21 +08:00
|
|
|
tipc_bclink_acknowledge(node, msg_bcast_ack(msg));
|
|
|
|
tipc_node_unlock(node);
|
2006-06-26 14:40:01 +08:00
|
|
|
spin_lock_bh(&bc_lock);
|
2006-01-03 02:04:38 +08:00
|
|
|
bcl->stats.recv_nacks++;
|
2011-01-19 02:53:16 +08:00
|
|
|
bclink->retransmit_to = node;
|
2006-01-03 02:04:38 +08:00
|
|
|
bclink_retransmit_pkt(msg_bcgap_after(msg),
|
|
|
|
msg_bcgap_to(msg));
|
2007-02-09 22:25:21 +08:00
|
|
|
spin_unlock_bh(&bc_lock);
|
2006-01-03 02:04:38 +08:00
|
|
|
} else {
|
2011-04-08 01:57:25 +08:00
|
|
|
tipc_node_unlock(node);
|
tipc: Major redesign of broadcast link ACK/NACK algorithms
Completely redesigns broadcast link ACK and NACK mechanisms to prevent
spurious retransmit requests in dual LAN networks, and to prevent the
broadcast link from stalling due to the failure of a receiving node to
acknowledge receiving a broadcast message or request its retransmission.
Note: These changes only impact the timing of when ACK and NACK messages
are sent, and not the basic broadcast link protocol itself, so inter-
operability with nodes using the "classic" algorithms is maintained.
The revised algorithms are as follows:
1) An explicit ACK message is still sent after receiving 16 in-sequence
messages, and implicit ACK information continues to be carried in other
unicast link message headers (including link state messages). However,
the timing of explicit ACKs is now based on the receiving node's absolute
network address rather than its relative network address to ensure that
the failure of another node does not delay the ACK beyond its 16 message
target.
2) A NACK message is now typically sent only when a message gap persists
for two consecutive incoming link state messages; this ensures that a
suspected gap is not confirmed until both LANs in a dual LAN network have
had an opportunity to deliver the message, thereby preventing spurious NACKs.
A NACK message can also be generated by the arrival of a single link state
message, if the deferred queue is so big that the current message gap
cannot be the result of "normal" mis-ordering due to the use of dual LANs
(or one LAN using a bonded interface). Since link state messages typically
arrive at different nodes at different times the problem of multiple nodes
issuing identical NACKs simultaneously is inherently avoided.
3) Nodes continue to "peek" at NACK messages sent by other nodes. If
another node requests retransmission of a message gap suspected (but not
yet confirmed) by the peeking node, the peeking node forgets about the
gap and does not generate a duplicate retransmit request. (If the peeking
node subsequently fails to receive the lost message, later link state
messages will cause it to rediscover and confirm the gap and send another
NACK.)
4) Message gap "equality" is now determined by the start of the gap only.
This is sufficient to deal with the most common cases of message loss,
and eliminates the need for complex end of gap computations.
5) A peeking node no longer tries to determine whether it should send a
complementary NACK, since the most common cases of message loss don't
require it to be sent. Consequently, the node no longer examines the
"broadcast tag" field of a NACK message when peeking.
Signed-off-by: Allan Stephens <allan.stephens@windriver.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2011-10-28 02:17:53 +08:00
|
|
|
bclink_peek_nack(msg);
|
2006-01-03 02:04:38 +08:00
|
|
|
}
|
2011-04-08 01:57:25 +08:00
|
|
|
goto exit;
|
2006-01-03 02:04:38 +08:00
|
|
|
}
|
|
|
|
|
2011-04-08 01:57:25 +08:00
|
|
|
/* Handle in-sequence broadcast message */
|
|
|
|
|
2006-01-03 02:04:38 +08:00
|
|
|
seqno = msg_seqno(msg);
|
2011-10-27 03:33:44 +08:00
|
|
|
next_in = mod(node->bclink.last_in + 1);
|
2006-01-03 02:04:38 +08:00
|
|
|
|
|
|
|
if (likely(seqno == next_in)) {
|
2011-10-27 03:33:44 +08:00
|
|
|
receive:
|
tipc: Major redesign of broadcast link ACK/NACK algorithms
Completely redesigns broadcast link ACK and NACK mechanisms to prevent
spurious retransmit requests in dual LAN networks, and to prevent the
broadcast link from stalling due to the failure of a receiving node to
acknowledge receiving a broadcast message or request its retransmission.
Note: These changes only impact the timing of when ACK and NACK messages
are sent, and not the basic broadcast link protocol itself, so inter-
operability with nodes using the "classic" algorithms is maintained.
The revised algorithms are as follows:
1) An explicit ACK message is still sent after receiving 16 in-sequence
messages, and implicit ACK information continues to be carried in other
unicast link message headers (including link state messages). However,
the timing of explicit ACKs is now based on the receiving node's absolute
network address rather than its relative network address to ensure that
the failure of another node does not delay the ACK beyond its 16 message
target.
2) A NACK message is now typically sent only when a message gap persists
for two consecutive incoming link state messages; this ensures that a
suspected gap is not confirmed until both LANs in a dual LAN network have
had an opportunity to deliver the message, thereby preventing spurious NACKs.
A NACK message can also be generated by the arrival of a single link state
message, if the deferred queue is so big that the current message gap
cannot be the result of "normal" mis-ordering due to the use of dual LANs
(or one LAN using a bonded interface). Since link state messages typically
arrive at different nodes at different times the problem of multiple nodes
issuing identical NACKs simultaneously is inherently avoided.
3) Nodes continue to "peek" at NACK messages sent by other nodes. If
another node requests retransmission of a message gap suspected (but not
yet confirmed) by the peeking node, the peeking node forgets about the
gap and does not generate a duplicate retransmit request. (If the peeking
node subsequently fails to receive the lost message, later link state
messages will cause it to rediscover and confirm the gap and send another
NACK.)
4) Message gap "equality" is now determined by the start of the gap only.
This is sufficient to deal with the most common cases of message loss,
and eliminates the need for complex end of gap computations.
5) A peeking node no longer tries to determine whether it should send a
complementary NACK, since the most common cases of message loss don't
require it to be sent. Consequently, the node no longer examines the
"broadcast tag" field of a NACK message when peeking.
Signed-off-by: Allan Stephens <allan.stephens@windriver.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2011-10-28 02:17:53 +08:00
|
|
|
/* Deliver message to destination */
|
|
|
|
|
2006-01-03 02:04:38 +08:00
|
|
|
if (likely(msg_isdata(msg))) {
|
2011-10-28 04:43:09 +08:00
|
|
|
spin_lock_bh(&bc_lock);
|
|
|
|
bclink_accept_pkt(node, seqno);
|
2011-10-27 04:13:35 +08:00
|
|
|
spin_unlock_bh(&bc_lock);
|
2006-01-18 07:38:21 +08:00
|
|
|
tipc_node_unlock(node);
|
2011-04-08 02:57:53 +08:00
|
|
|
if (likely(msg_mcast(msg)))
|
2014-02-18 16:06:46 +08:00
|
|
|
tipc_port_mcast_rcv(buf, NULL);
|
2011-04-08 02:57:53 +08:00
|
|
|
else
|
2011-11-05 01:24:29 +08:00
|
|
|
kfree_skb(buf);
|
2006-01-03 02:04:38 +08:00
|
|
|
} else if (msg_user(msg) == MSG_BUNDLER) {
|
2011-10-28 04:43:09 +08:00
|
|
|
spin_lock_bh(&bc_lock);
|
|
|
|
bclink_accept_pkt(node, seqno);
|
2006-01-03 02:04:38 +08:00
|
|
|
bcl->stats.recv_bundles++;
|
|
|
|
bcl->stats.recv_bundled += msg_msgcnt(msg);
|
2011-10-27 04:13:35 +08:00
|
|
|
spin_unlock_bh(&bc_lock);
|
2006-01-18 07:38:21 +08:00
|
|
|
tipc_node_unlock(node);
|
2014-02-18 16:06:46 +08:00
|
|
|
tipc_link_bundle_rcv(buf);
|
2006-01-03 02:04:38 +08:00
|
|
|
} else if (msg_user(msg) == MSG_FRAGMENTER) {
|
tipc: message reassembly using fragment chain
When the first fragment of a long data data message is received on a link, a
reassembly buffer large enough to hold the data from this and all subsequent
fragments of the message is allocated. The payload of each new fragment is
copied into this buffer upon arrival. When the last fragment is received, the
reassembled message is delivered upwards to the port/socket layer.
Not only is this an inefficient approach, but it may also cause bursts of
reassembly failures in low memory situations. since we may fail to allocate
the necessary large buffer in the first place. Furthermore, after 100 subsequent
such failures the link will be reset, something that in reality aggravates the
situation.
To remedy this problem, this patch introduces a different approach. Instead of
allocating a big reassembly buffer, we now append the arriving fragments
to a reassembly chain on the link, and deliver the whole chain up to the
socket layer once the last fragment has been received. This is safe because
the retransmission layer of a TIPC link always delivers packets in strict
uninterrupted order, to the reassembly layer as to all other upper layers.
Hence there can never be more than one fragment chain pending reassembly at
any given time in a link, and we can trust (but still verify) that the
fragments will be chained up in the correct order.
Signed-off-by: Erik Hugne <erik.hugne@ericsson.com>
Reviewed-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2013-11-06 16:28:06 +08:00
|
|
|
int ret;
|
2014-02-14 06:29:05 +08:00
|
|
|
ret = tipc_link_frag_rcv(&node->bclink.reasm_head,
|
|
|
|
&node->bclink.reasm_tail,
|
|
|
|
&buf);
|
tipc: message reassembly using fragment chain
When the first fragment of a long data data message is received on a link, a
reassembly buffer large enough to hold the data from this and all subsequent
fragments of the message is allocated. The payload of each new fragment is
copied into this buffer upon arrival. When the last fragment is received, the
reassembled message is delivered upwards to the port/socket layer.
Not only is this an inefficient approach, but it may also cause bursts of
reassembly failures in low memory situations. since we may fail to allocate
the necessary large buffer in the first place. Furthermore, after 100 subsequent
such failures the link will be reset, something that in reality aggravates the
situation.
To remedy this problem, this patch introduces a different approach. Instead of
allocating a big reassembly buffer, we now append the arriving fragments
to a reassembly chain on the link, and deliver the whole chain up to the
socket layer once the last fragment has been received. This is safe because
the retransmission layer of a TIPC link always delivers packets in strict
uninterrupted order, to the reassembly layer as to all other upper layers.
Hence there can never be more than one fragment chain pending reassembly at
any given time in a link, and we can trust (but still verify) that the
fragments will be chained up in the correct order.
Signed-off-by: Erik Hugne <erik.hugne@ericsson.com>
Reviewed-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2013-11-06 16:28:06 +08:00
|
|
|
if (ret == LINK_REASM_ERROR)
|
2011-10-28 04:43:09 +08:00
|
|
|
goto unlock;
|
|
|
|
spin_lock_bh(&bc_lock);
|
|
|
|
bclink_accept_pkt(node, seqno);
|
2006-01-03 02:04:38 +08:00
|
|
|
bcl->stats.recv_fragments++;
|
tipc: message reassembly using fragment chain
When the first fragment of a long data data message is received on a link, a
reassembly buffer large enough to hold the data from this and all subsequent
fragments of the message is allocated. The payload of each new fragment is
copied into this buffer upon arrival. When the last fragment is received, the
reassembled message is delivered upwards to the port/socket layer.
Not only is this an inefficient approach, but it may also cause bursts of
reassembly failures in low memory situations. since we may fail to allocate
the necessary large buffer in the first place. Furthermore, after 100 subsequent
such failures the link will be reset, something that in reality aggravates the
situation.
To remedy this problem, this patch introduces a different approach. Instead of
allocating a big reassembly buffer, we now append the arriving fragments
to a reassembly chain on the link, and deliver the whole chain up to the
socket layer once the last fragment has been received. This is safe because
the retransmission layer of a TIPC link always delivers packets in strict
uninterrupted order, to the reassembly layer as to all other upper layers.
Hence there can never be more than one fragment chain pending reassembly at
any given time in a link, and we can trust (but still verify) that the
fragments will be chained up in the correct order.
Signed-off-by: Erik Hugne <erik.hugne@ericsson.com>
Reviewed-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2013-11-06 16:28:06 +08:00
|
|
|
if (ret == LINK_REASM_COMPLETE) {
|
2006-01-03 02:04:38 +08:00
|
|
|
bcl->stats.recv_fragmented++;
|
tipc: message reassembly using fragment chain
When the first fragment of a long data data message is received on a link, a
reassembly buffer large enough to hold the data from this and all subsequent
fragments of the message is allocated. The payload of each new fragment is
copied into this buffer upon arrival. When the last fragment is received, the
reassembled message is delivered upwards to the port/socket layer.
Not only is this an inefficient approach, but it may also cause bursts of
reassembly failures in low memory situations. since we may fail to allocate
the necessary large buffer in the first place. Furthermore, after 100 subsequent
such failures the link will be reset, something that in reality aggravates the
situation.
To remedy this problem, this patch introduces a different approach. Instead of
allocating a big reassembly buffer, we now append the arriving fragments
to a reassembly chain on the link, and deliver the whole chain up to the
socket layer once the last fragment has been received. This is safe because
the retransmission layer of a TIPC link always delivers packets in strict
uninterrupted order, to the reassembly layer as to all other upper layers.
Hence there can never be more than one fragment chain pending reassembly at
any given time in a link, and we can trust (but still verify) that the
fragments will be chained up in the correct order.
Signed-off-by: Erik Hugne <erik.hugne@ericsson.com>
Reviewed-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2013-11-06 16:28:06 +08:00
|
|
|
/* Point msg to inner header */
|
|
|
|
msg = buf_msg(buf);
|
2013-11-06 16:28:05 +08:00
|
|
|
spin_unlock_bh(&bc_lock);
|
|
|
|
goto receive;
|
|
|
|
}
|
2011-10-27 04:13:35 +08:00
|
|
|
spin_unlock_bh(&bc_lock);
|
2006-01-18 07:38:21 +08:00
|
|
|
tipc_node_unlock(node);
|
2011-04-08 02:57:53 +08:00
|
|
|
} else if (msg_user(msg) == NAME_DISTRIBUTOR) {
|
2011-10-28 04:43:09 +08:00
|
|
|
spin_lock_bh(&bc_lock);
|
|
|
|
bclink_accept_pkt(node, seqno);
|
2011-10-27 04:13:35 +08:00
|
|
|
spin_unlock_bh(&bc_lock);
|
2011-04-08 02:57:53 +08:00
|
|
|
tipc_node_unlock(node);
|
2014-02-18 16:06:46 +08:00
|
|
|
tipc_named_rcv(buf);
|
2006-01-03 02:04:38 +08:00
|
|
|
} else {
|
2011-10-28 04:43:09 +08:00
|
|
|
spin_lock_bh(&bc_lock);
|
|
|
|
bclink_accept_pkt(node, seqno);
|
2011-10-27 04:13:35 +08:00
|
|
|
spin_unlock_bh(&bc_lock);
|
2006-01-18 07:38:21 +08:00
|
|
|
tipc_node_unlock(node);
|
2011-11-05 01:24:29 +08:00
|
|
|
kfree_skb(buf);
|
2006-01-03 02:04:38 +08:00
|
|
|
}
|
2011-04-08 01:57:25 +08:00
|
|
|
buf = NULL;
|
2011-10-27 03:33:44 +08:00
|
|
|
|
|
|
|
/* Determine new synchronization state */
|
|
|
|
|
2011-04-08 01:57:25 +08:00
|
|
|
tipc_node_lock(node);
|
2011-10-27 03:33:44 +08:00
|
|
|
if (unlikely(!tipc_node_is_up(node)))
|
|
|
|
goto unlock;
|
|
|
|
|
tipc: Major redesign of broadcast link ACK/NACK algorithms
Completely redesigns broadcast link ACK and NACK mechanisms to prevent
spurious retransmit requests in dual LAN networks, and to prevent the
broadcast link from stalling due to the failure of a receiving node to
acknowledge receiving a broadcast message or request its retransmission.
Note: These changes only impact the timing of when ACK and NACK messages
are sent, and not the basic broadcast link protocol itself, so inter-
operability with nodes using the "classic" algorithms is maintained.
The revised algorithms are as follows:
1) An explicit ACK message is still sent after receiving 16 in-sequence
messages, and implicit ACK information continues to be carried in other
unicast link message headers (including link state messages). However,
the timing of explicit ACKs is now based on the receiving node's absolute
network address rather than its relative network address to ensure that
the failure of another node does not delay the ACK beyond its 16 message
target.
2) A NACK message is now typically sent only when a message gap persists
for two consecutive incoming link state messages; this ensures that a
suspected gap is not confirmed until both LANs in a dual LAN network have
had an opportunity to deliver the message, thereby preventing spurious NACKs.
A NACK message can also be generated by the arrival of a single link state
message, if the deferred queue is so big that the current message gap
cannot be the result of "normal" mis-ordering due to the use of dual LANs
(or one LAN using a bonded interface). Since link state messages typically
arrive at different nodes at different times the problem of multiple nodes
issuing identical NACKs simultaneously is inherently avoided.
3) Nodes continue to "peek" at NACK messages sent by other nodes. If
another node requests retransmission of a message gap suspected (but not
yet confirmed) by the peeking node, the peeking node forgets about the
gap and does not generate a duplicate retransmit request. (If the peeking
node subsequently fails to receive the lost message, later link state
messages will cause it to rediscover and confirm the gap and send another
NACK.)
4) Message gap "equality" is now determined by the start of the gap only.
This is sufficient to deal with the most common cases of message loss,
and eliminates the need for complex end of gap computations.
5) A peeking node no longer tries to determine whether it should send a
complementary NACK, since the most common cases of message loss don't
require it to be sent. Consequently, the node no longer examines the
"broadcast tag" field of a NACK message when peeking.
Signed-off-by: Allan Stephens <allan.stephens@windriver.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2011-10-28 02:17:53 +08:00
|
|
|
if (node->bclink.last_in == node->bclink.last_sent)
|
2011-10-27 03:33:44 +08:00
|
|
|
goto unlock;
|
|
|
|
|
tipc: Major redesign of broadcast link ACK/NACK algorithms
Completely redesigns broadcast link ACK and NACK mechanisms to prevent
spurious retransmit requests in dual LAN networks, and to prevent the
broadcast link from stalling due to the failure of a receiving node to
acknowledge receiving a broadcast message or request its retransmission.
Note: These changes only impact the timing of when ACK and NACK messages
are sent, and not the basic broadcast link protocol itself, so inter-
operability with nodes using the "classic" algorithms is maintained.
The revised algorithms are as follows:
1) An explicit ACK message is still sent after receiving 16 in-sequence
messages, and implicit ACK information continues to be carried in other
unicast link message headers (including link state messages). However,
the timing of explicit ACKs is now based on the receiving node's absolute
network address rather than its relative network address to ensure that
the failure of another node does not delay the ACK beyond its 16 message
target.
2) A NACK message is now typically sent only when a message gap persists
for two consecutive incoming link state messages; this ensures that a
suspected gap is not confirmed until both LANs in a dual LAN network have
had an opportunity to deliver the message, thereby preventing spurious NACKs.
A NACK message can also be generated by the arrival of a single link state
message, if the deferred queue is so big that the current message gap
cannot be the result of "normal" mis-ordering due to the use of dual LANs
(or one LAN using a bonded interface). Since link state messages typically
arrive at different nodes at different times the problem of multiple nodes
issuing identical NACKs simultaneously is inherently avoided.
3) Nodes continue to "peek" at NACK messages sent by other nodes. If
another node requests retransmission of a message gap suspected (but not
yet confirmed) by the peeking node, the peeking node forgets about the
gap and does not generate a duplicate retransmit request. (If the peeking
node subsequently fails to receive the lost message, later link state
messages will cause it to rediscover and confirm the gap and send another
NACK.)
4) Message gap "equality" is now determined by the start of the gap only.
This is sufficient to deal with the most common cases of message loss,
and eliminates the need for complex end of gap computations.
5) A peeking node no longer tries to determine whether it should send a
complementary NACK, since the most common cases of message loss don't
require it to be sent. Consequently, the node no longer examines the
"broadcast tag" field of a NACK message when peeking.
Signed-off-by: Allan Stephens <allan.stephens@windriver.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2011-10-28 02:17:53 +08:00
|
|
|
if (!node->bclink.deferred_head) {
|
|
|
|
node->bclink.oos_state = 1;
|
|
|
|
goto unlock;
|
|
|
|
}
|
|
|
|
|
2011-10-27 03:33:44 +08:00
|
|
|
msg = buf_msg(node->bclink.deferred_head);
|
|
|
|
seqno = msg_seqno(msg);
|
|
|
|
next_in = mod(next_in + 1);
|
|
|
|
if (seqno != next_in)
|
|
|
|
goto unlock;
|
|
|
|
|
|
|
|
/* Take in-sequence message from deferred queue & deliver it */
|
|
|
|
|
|
|
|
buf = node->bclink.deferred_head;
|
|
|
|
node->bclink.deferred_head = buf->next;
|
tipc: Major redesign of broadcast link ACK/NACK algorithms
Completely redesigns broadcast link ACK and NACK mechanisms to prevent
spurious retransmit requests in dual LAN networks, and to prevent the
broadcast link from stalling due to the failure of a receiving node to
acknowledge receiving a broadcast message or request its retransmission.
Note: These changes only impact the timing of when ACK and NACK messages
are sent, and not the basic broadcast link protocol itself, so inter-
operability with nodes using the "classic" algorithms is maintained.
The revised algorithms are as follows:
1) An explicit ACK message is still sent after receiving 16 in-sequence
messages, and implicit ACK information continues to be carried in other
unicast link message headers (including link state messages). However,
the timing of explicit ACKs is now based on the receiving node's absolute
network address rather than its relative network address to ensure that
the failure of another node does not delay the ACK beyond its 16 message
target.
2) A NACK message is now typically sent only when a message gap persists
for two consecutive incoming link state messages; this ensures that a
suspected gap is not confirmed until both LANs in a dual LAN network have
had an opportunity to deliver the message, thereby preventing spurious NACKs.
A NACK message can also be generated by the arrival of a single link state
message, if the deferred queue is so big that the current message gap
cannot be the result of "normal" mis-ordering due to the use of dual LANs
(or one LAN using a bonded interface). Since link state messages typically
arrive at different nodes at different times the problem of multiple nodes
issuing identical NACKs simultaneously is inherently avoided.
3) Nodes continue to "peek" at NACK messages sent by other nodes. If
another node requests retransmission of a message gap suspected (but not
yet confirmed) by the peeking node, the peeking node forgets about the
gap and does not generate a duplicate retransmit request. (If the peeking
node subsequently fails to receive the lost message, later link state
messages will cause it to rediscover and confirm the gap and send another
NACK.)
4) Message gap "equality" is now determined by the start of the gap only.
This is sufficient to deal with the most common cases of message loss,
and eliminates the need for complex end of gap computations.
5) A peeking node no longer tries to determine whether it should send a
complementary NACK, since the most common cases of message loss don't
require it to be sent. Consequently, the node no longer examines the
"broadcast tag" field of a NACK message when peeking.
Signed-off-by: Allan Stephens <allan.stephens@windriver.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2011-10-28 02:17:53 +08:00
|
|
|
node->bclink.deferred_size--;
|
2011-10-27 03:33:44 +08:00
|
|
|
goto receive;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Handle out-of-sequence broadcast message */
|
|
|
|
|
|
|
|
if (less(next_in, seqno)) {
|
|
|
|
deferred = tipc_link_defer_pkt(&node->bclink.deferred_head,
|
|
|
|
&node->bclink.deferred_tail,
|
|
|
|
buf);
|
tipc: Major redesign of broadcast link ACK/NACK algorithms
Completely redesigns broadcast link ACK and NACK mechanisms to prevent
spurious retransmit requests in dual LAN networks, and to prevent the
broadcast link from stalling due to the failure of a receiving node to
acknowledge receiving a broadcast message or request its retransmission.
Note: These changes only impact the timing of when ACK and NACK messages
are sent, and not the basic broadcast link protocol itself, so inter-
operability with nodes using the "classic" algorithms is maintained.
The revised algorithms are as follows:
1) An explicit ACK message is still sent after receiving 16 in-sequence
messages, and implicit ACK information continues to be carried in other
unicast link message headers (including link state messages). However,
the timing of explicit ACKs is now based on the receiving node's absolute
network address rather than its relative network address to ensure that
the failure of another node does not delay the ACK beyond its 16 message
target.
2) A NACK message is now typically sent only when a message gap persists
for two consecutive incoming link state messages; this ensures that a
suspected gap is not confirmed until both LANs in a dual LAN network have
had an opportunity to deliver the message, thereby preventing spurious NACKs.
A NACK message can also be generated by the arrival of a single link state
message, if the deferred queue is so big that the current message gap
cannot be the result of "normal" mis-ordering due to the use of dual LANs
(or one LAN using a bonded interface). Since link state messages typically
arrive at different nodes at different times the problem of multiple nodes
issuing identical NACKs simultaneously is inherently avoided.
3) Nodes continue to "peek" at NACK messages sent by other nodes. If
another node requests retransmission of a message gap suspected (but not
yet confirmed) by the peeking node, the peeking node forgets about the
gap and does not generate a duplicate retransmit request. (If the peeking
node subsequently fails to receive the lost message, later link state
messages will cause it to rediscover and confirm the gap and send another
NACK.)
4) Message gap "equality" is now determined by the start of the gap only.
This is sufficient to deal with the most common cases of message loss,
and eliminates the need for complex end of gap computations.
5) A peeking node no longer tries to determine whether it should send a
complementary NACK, since the most common cases of message loss don't
require it to be sent. Consequently, the node no longer examines the
"broadcast tag" field of a NACK message when peeking.
Signed-off-by: Allan Stephens <allan.stephens@windriver.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2011-10-28 02:17:53 +08:00
|
|
|
node->bclink.deferred_size += deferred;
|
|
|
|
bclink_update_last_sent(node, seqno);
|
2011-04-08 01:57:25 +08:00
|
|
|
buf = NULL;
|
2011-10-27 03:33:44 +08:00
|
|
|
} else
|
|
|
|
deferred = 0;
|
|
|
|
|
2011-10-27 04:13:35 +08:00
|
|
|
spin_lock_bh(&bc_lock);
|
|
|
|
|
2011-10-27 03:33:44 +08:00
|
|
|
if (deferred)
|
|
|
|
bcl->stats.deferred_recv++;
|
2011-10-27 03:57:26 +08:00
|
|
|
else
|
|
|
|
bcl->stats.duplicates++;
|
2011-10-27 03:33:44 +08:00
|
|
|
|
2011-10-27 04:13:35 +08:00
|
|
|
spin_unlock_bh(&bc_lock);
|
|
|
|
|
2011-04-08 01:57:25 +08:00
|
|
|
unlock:
|
2006-01-18 07:38:21 +08:00
|
|
|
tipc_node_unlock(node);
|
2011-04-08 01:57:25 +08:00
|
|
|
exit:
|
2011-11-05 01:24:29 +08:00
|
|
|
kfree_skb(buf);
|
2006-01-03 02:04:38 +08:00
|
|
|
}
|
|
|
|
|
2008-09-03 14:38:32 +08:00
|
|
|
u32 tipc_bclink_acks_missing(struct tipc_node *n_ptr)
|
2006-01-03 02:04:38 +08:00
|
|
|
{
|
2012-11-16 13:51:30 +08:00
|
|
|
return (n_ptr->bclink.recv_permitted &&
|
2006-01-18 07:38:21 +08:00
|
|
|
(tipc_bclink_get_last_sent() != n_ptr->bclink.acked));
|
2006-01-03 02:04:38 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/**
|
2006-01-18 07:38:21 +08:00
|
|
|
* tipc_bcbearer_send - send a packet through the broadcast pseudo-bearer
|
2007-02-09 22:25:21 +08:00
|
|
|
*
|
2011-04-07 22:44:54 +08:00
|
|
|
* Send packet over as many bearers as necessary to reach all nodes
|
|
|
|
* that have joined the broadcast link.
|
2007-02-09 22:25:21 +08:00
|
|
|
*
|
2011-04-07 22:44:54 +08:00
|
|
|
* Returns 0 (packet sent successfully) under all circumstances,
|
|
|
|
* since the broadcast link's pseudo-bearer never blocks
|
2006-01-03 02:04:38 +08:00
|
|
|
*/
|
2013-06-17 22:54:47 +08:00
|
|
|
static int tipc_bcbearer_send(struct sk_buff *buf, struct tipc_bearer *unused1,
|
2006-03-21 14:37:52 +08:00
|
|
|
struct tipc_media_addr *unused2)
|
2006-01-03 02:04:38 +08:00
|
|
|
{
|
|
|
|
int bp_index;
|
|
|
|
|
2013-05-01 20:04:44 +08:00
|
|
|
/* Prepare broadcast link message for reliable transmission,
|
2011-04-07 22:44:54 +08:00
|
|
|
* if first time trying to send it;
|
|
|
|
* preparation is skipped for broadcast link protocol messages
|
|
|
|
* since they are sent in an unreliable manner and don't need it
|
|
|
|
*/
|
2006-01-03 02:04:38 +08:00
|
|
|
if (likely(!msg_non_seq(buf_msg(buf)))) {
|
|
|
|
struct tipc_msg *msg;
|
|
|
|
|
2011-10-24 23:18:12 +08:00
|
|
|
bcbuf_set_acks(buf, bclink->bcast_nodes.count);
|
2006-01-03 02:04:38 +08:00
|
|
|
msg = buf_msg(buf);
|
2008-06-05 08:54:48 +08:00
|
|
|
msg_set_non_seq(msg, 1);
|
2006-01-03 02:04:38 +08:00
|
|
|
msg_set_mc_netid(msg, tipc_net_id);
|
2010-08-17 19:00:10 +08:00
|
|
|
bcl->stats.sent_info++;
|
2011-05-24 01:14:18 +08:00
|
|
|
|
2011-10-24 23:18:12 +08:00
|
|
|
if (WARN_ON(!bclink->bcast_nodes.count)) {
|
2011-05-24 01:14:18 +08:00
|
|
|
dump_stack();
|
|
|
|
return 0;
|
|
|
|
}
|
2006-01-03 02:04:38 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/* Send buffer over bearers until all targets reached */
|
2011-10-24 23:18:12 +08:00
|
|
|
bcbearer->remains = bclink->bcast_nodes;
|
2006-01-03 02:04:38 +08:00
|
|
|
|
|
|
|
for (bp_index = 0; bp_index < MAX_BEARERS; bp_index++) {
|
2011-01-08 02:00:11 +08:00
|
|
|
struct tipc_bearer *p = bcbearer->bpairs[bp_index].primary;
|
|
|
|
struct tipc_bearer *s = bcbearer->bpairs[bp_index].secondary;
|
2013-05-01 20:04:45 +08:00
|
|
|
struct tipc_bearer *b = p;
|
tipc: pskb_copy() buffers when sending on more than one bearer
When sending packets, TIPC bearers use skb_clone() before writing their
hardware header. This will however NOT copy the data buffer.
So when the same packet is sent over multiple bearers (to reach multiple
nodes), the same socket buffer data will be treated by multiple
tipc_media drivers which will write their own hardware header through
dev_hard_header().
Most of the time this is not a problem, because by the time the
packet is processed by the second media, it has already been sent over
the first one. However, when the first transmission is delayed (e.g.
because of insufficient bandwidth or through a shaper), the next bearer
will overwrite the hardware header, resulting in the packet being sent:
a) with the wrong source address, when bearers of the same type,
e.g. ethernet, are involved
b) with a completely corrupt header, or even dropped, when bearers of
different types are involved.
So when the same socket buffer is to be sent multiple times, send a
pskb_copy() instead (from the second instance on), and release it
afterwards (the bearer will skb_clone() it anyway).
Signed-off-by: Gerlando Falauto <gerlando.falauto@keymile.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2013-05-01 20:04:46 +08:00
|
|
|
struct sk_buff *tbuf;
|
2006-01-03 02:04:38 +08:00
|
|
|
|
|
|
|
if (!p)
|
2013-05-01 20:04:44 +08:00
|
|
|
break; /* No more bearers to try */
|
2006-01-03 02:04:38 +08:00
|
|
|
|
2013-05-01 20:04:45 +08:00
|
|
|
tipc_nmap_diff(&bcbearer->remains, &b->nodes,
|
2013-05-01 20:04:44 +08:00
|
|
|
&bcbearer->remains_new);
|
2006-06-26 14:53:20 +08:00
|
|
|
if (bcbearer->remains_new.count == bcbearer->remains.count)
|
2013-05-01 20:04:44 +08:00
|
|
|
continue; /* Nothing added by bearer pair */
|
2006-01-03 02:04:38 +08:00
|
|
|
|
tipc: pskb_copy() buffers when sending on more than one bearer
When sending packets, TIPC bearers use skb_clone() before writing their
hardware header. This will however NOT copy the data buffer.
So when the same packet is sent over multiple bearers (to reach multiple
nodes), the same socket buffer data will be treated by multiple
tipc_media drivers which will write their own hardware header through
dev_hard_header().
Most of the time this is not a problem, because by the time the
packet is processed by the second media, it has already been sent over
the first one. However, when the first transmission is delayed (e.g.
because of insufficient bandwidth or through a shaper), the next bearer
will overwrite the hardware header, resulting in the packet being sent:
a) with the wrong source address, when bearers of the same type,
e.g. ethernet, are involved
b) with a completely corrupt header, or even dropped, when bearers of
different types are involved.
So when the same socket buffer is to be sent multiple times, send a
pskb_copy() instead (from the second instance on), and release it
afterwards (the bearer will skb_clone() it anyway).
Signed-off-by: Gerlando Falauto <gerlando.falauto@keymile.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2013-05-01 20:04:46 +08:00
|
|
|
if (bp_index == 0) {
|
|
|
|
/* Use original buffer for first bearer */
|
|
|
|
tipc_bearer_send(b, buf, &b->bcast_addr);
|
|
|
|
} else {
|
|
|
|
/* Avoid concurrent buffer access */
|
|
|
|
tbuf = pskb_copy(buf, GFP_ATOMIC);
|
|
|
|
if (!tbuf)
|
|
|
|
break;
|
|
|
|
tipc_bearer_send(b, tbuf, &b->bcast_addr);
|
|
|
|
kfree_skb(tbuf); /* Bearer keeps a clone */
|
|
|
|
}
|
2010-03-15 16:02:24 +08:00
|
|
|
|
2013-05-01 20:04:44 +08:00
|
|
|
/* Swap bearers for next packet */
|
2010-03-15 16:02:24 +08:00
|
|
|
if (s) {
|
|
|
|
bcbearer->bpairs[bp_index].primary = s;
|
|
|
|
bcbearer->bpairs[bp_index].secondary = p;
|
2006-01-03 02:04:38 +08:00
|
|
|
}
|
|
|
|
|
2006-06-26 14:53:20 +08:00
|
|
|
if (bcbearer->remains_new.count == 0)
|
2013-05-01 20:04:44 +08:00
|
|
|
break; /* All targets reached */
|
2006-01-03 02:04:38 +08:00
|
|
|
|
2006-06-26 14:53:20 +08:00
|
|
|
bcbearer->remains = bcbearer->remains_new;
|
2006-01-03 02:04:38 +08:00
|
|
|
}
|
2007-02-09 22:25:21 +08:00
|
|
|
|
2011-04-07 22:44:54 +08:00
|
|
|
return 0;
|
2006-01-03 02:04:38 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
2006-01-18 07:38:21 +08:00
|
|
|
* tipc_bcbearer_sort - create sets of bearer pairs used by broadcast bearer
|
2006-01-03 02:04:38 +08:00
|
|
|
*/
|
2006-01-18 07:38:21 +08:00
|
|
|
void tipc_bcbearer_sort(void)
|
2006-01-03 02:04:38 +08:00
|
|
|
{
|
2011-12-30 09:55:27 +08:00
|
|
|
struct tipc_bcbearer_pair *bp_temp = bcbearer->bpairs_temp;
|
|
|
|
struct tipc_bcbearer_pair *bp_curr;
|
2006-01-03 02:04:38 +08:00
|
|
|
int b_index;
|
|
|
|
int pri;
|
|
|
|
|
|
|
|
spin_lock_bh(&bc_lock);
|
|
|
|
|
|
|
|
/* Group bearers by priority (can assume max of two per priority) */
|
|
|
|
memset(bp_temp, 0, sizeof(bcbearer->bpairs_temp));
|
|
|
|
|
|
|
|
for (b_index = 0; b_index < MAX_BEARERS; b_index++) {
|
2011-01-08 02:00:11 +08:00
|
|
|
struct tipc_bearer *b = &tipc_bearers[b_index];
|
2006-01-03 02:04:38 +08:00
|
|
|
|
|
|
|
if (!b->active || !b->nodes.count)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
if (!bp_temp[b->priority].primary)
|
|
|
|
bp_temp[b->priority].primary = b;
|
|
|
|
else
|
|
|
|
bp_temp[b->priority].secondary = b;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Create array of bearer pairs for broadcasting */
|
|
|
|
bp_curr = bcbearer->bpairs;
|
|
|
|
memset(bcbearer->bpairs, 0, sizeof(bcbearer->bpairs));
|
|
|
|
|
2006-01-14 05:22:22 +08:00
|
|
|
for (pri = TIPC_MAX_LINK_PRI; pri >= 0; pri--) {
|
2006-01-03 02:04:38 +08:00
|
|
|
|
|
|
|
if (!bp_temp[pri].primary)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
bp_curr->primary = bp_temp[pri].primary;
|
|
|
|
|
|
|
|
if (bp_temp[pri].secondary) {
|
2006-01-18 07:38:21 +08:00
|
|
|
if (tipc_nmap_equal(&bp_temp[pri].primary->nodes,
|
|
|
|
&bp_temp[pri].secondary->nodes)) {
|
2006-01-03 02:04:38 +08:00
|
|
|
bp_curr->secondary = bp_temp[pri].secondary;
|
|
|
|
} else {
|
|
|
|
bp_curr++;
|
|
|
|
bp_curr->primary = bp_temp[pri].secondary;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
bp_curr++;
|
|
|
|
}
|
|
|
|
|
|
|
|
spin_unlock_bh(&bc_lock);
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2006-01-18 07:38:21 +08:00
|
|
|
int tipc_bclink_stats(char *buf, const u32 buf_size)
|
2006-01-03 02:04:38 +08:00
|
|
|
{
|
2012-06-29 12:50:23 +08:00
|
|
|
int ret;
|
|
|
|
struct tipc_stats *s;
|
2006-01-03 02:04:38 +08:00
|
|
|
|
|
|
|
if (!bcl)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
spin_lock_bh(&bc_lock);
|
|
|
|
|
2012-06-29 12:50:23 +08:00
|
|
|
s = &bcl->stats;
|
|
|
|
|
|
|
|
ret = tipc_snprintf(buf, buf_size, "Link <%s>\n"
|
|
|
|
" Window:%u packets\n",
|
|
|
|
bcl->name, bcl->queue_limit[0]);
|
|
|
|
ret += tipc_snprintf(buf + ret, buf_size - ret,
|
|
|
|
" RX packets:%u fragments:%u/%u bundles:%u/%u\n",
|
|
|
|
s->recv_info, s->recv_fragments,
|
|
|
|
s->recv_fragmented, s->recv_bundles,
|
|
|
|
s->recv_bundled);
|
|
|
|
ret += tipc_snprintf(buf + ret, buf_size - ret,
|
|
|
|
" TX packets:%u fragments:%u/%u bundles:%u/%u\n",
|
|
|
|
s->sent_info, s->sent_fragments,
|
|
|
|
s->sent_fragmented, s->sent_bundles,
|
|
|
|
s->sent_bundled);
|
|
|
|
ret += tipc_snprintf(buf + ret, buf_size - ret,
|
|
|
|
" RX naks:%u defs:%u dups:%u\n",
|
|
|
|
s->recv_nacks, s->deferred_recv, s->duplicates);
|
|
|
|
ret += tipc_snprintf(buf + ret, buf_size - ret,
|
|
|
|
" TX naks:%u acks:%u dups:%u\n",
|
|
|
|
s->sent_nacks, s->sent_acks, s->retransmitted);
|
|
|
|
ret += tipc_snprintf(buf + ret, buf_size - ret,
|
2012-11-15 11:34:45 +08:00
|
|
|
" Congestion link:%u Send queue max:%u avg:%u\n",
|
|
|
|
s->link_congs, s->max_queue_sz,
|
2012-06-29 12:50:23 +08:00
|
|
|
s->queue_sz_counts ?
|
|
|
|
(s->accu_queue_sz / s->queue_sz_counts) : 0);
|
2006-01-03 02:04:38 +08:00
|
|
|
|
|
|
|
spin_unlock_bh(&bc_lock);
|
2012-06-29 12:50:23 +08:00
|
|
|
return ret;
|
2006-01-03 02:04:38 +08:00
|
|
|
}
|
|
|
|
|
2006-01-18 07:38:21 +08:00
|
|
|
int tipc_bclink_reset_stats(void)
|
2006-01-03 02:04:38 +08:00
|
|
|
{
|
|
|
|
if (!bcl)
|
|
|
|
return -ENOPROTOOPT;
|
|
|
|
|
|
|
|
spin_lock_bh(&bc_lock);
|
|
|
|
memset(&bcl->stats, 0, sizeof(bcl->stats));
|
|
|
|
spin_unlock_bh(&bc_lock);
|
2008-07-15 13:44:01 +08:00
|
|
|
return 0;
|
2006-01-03 02:04:38 +08:00
|
|
|
}
|
|
|
|
|
2006-01-18 07:38:21 +08:00
|
|
|
int tipc_bclink_set_queue_limits(u32 limit)
|
2006-01-03 02:04:38 +08:00
|
|
|
{
|
|
|
|
if (!bcl)
|
|
|
|
return -ENOPROTOOPT;
|
|
|
|
if ((limit < TIPC_MIN_LINK_WIN) || (limit > TIPC_MAX_LINK_WIN))
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
spin_lock_bh(&bc_lock);
|
2006-01-18 07:38:21 +08:00
|
|
|
tipc_link_set_queue_limits(bcl, limit);
|
2006-01-03 02:04:38 +08:00
|
|
|
spin_unlock_bh(&bc_lock);
|
2008-07-15 13:44:01 +08:00
|
|
|
return 0;
|
2006-01-03 02:04:38 +08:00
|
|
|
}
|
|
|
|
|
2011-10-24 22:29:26 +08:00
|
|
|
void tipc_bclink_init(void)
|
2006-01-03 02:04:38 +08:00
|
|
|
{
|
|
|
|
bcbearer->bearer.media = &bcbearer->media;
|
2006-01-18 07:38:21 +08:00
|
|
|
bcbearer->media.send_msg = tipc_bcbearer_send;
|
2011-04-07 22:22:31 +08:00
|
|
|
sprintf(bcbearer->media.name, "tipc-broadcast");
|
2006-01-03 02:04:38 +08:00
|
|
|
|
|
|
|
INIT_LIST_HEAD(&bcl->waiting_ports);
|
|
|
|
bcl->next_out_no = 1;
|
2006-06-27 17:53:55 +08:00
|
|
|
spin_lock_init(&bclink->node.lock);
|
2006-01-03 02:04:38 +08:00
|
|
|
bcl->owner = &bclink->node;
|
2007-02-09 22:25:21 +08:00
|
|
|
bcl->max_pkt = MAX_PKT_DEFAULT_MCAST;
|
2006-01-18 07:38:21 +08:00
|
|
|
tipc_link_set_queue_limits(bcl, BCLINK_WIN_DEFAULT);
|
2006-01-03 02:04:38 +08:00
|
|
|
bcl->b_ptr = &bcbearer->bearer;
|
|
|
|
bcl->state = WORKING_WORKING;
|
2009-03-19 10:11:29 +08:00
|
|
|
strlcpy(bcl->name, tipc_bclink_name, TIPC_MAX_LINK_NAME);
|
2006-01-03 02:04:38 +08:00
|
|
|
}
|
|
|
|
|
2006-01-18 07:38:21 +08:00
|
|
|
void tipc_bclink_stop(void)
|
2006-01-03 02:04:38 +08:00
|
|
|
{
|
|
|
|
spin_lock_bh(&bc_lock);
|
2014-01-08 06:02:44 +08:00
|
|
|
tipc_link_purge_queues(bcl);
|
2006-01-03 02:04:38 +08:00
|
|
|
spin_unlock_bh(&bc_lock);
|
2011-10-24 22:29:26 +08:00
|
|
|
|
|
|
|
memset(bclink, 0, sizeof(*bclink));
|
|
|
|
memset(bcbearer, 0, sizeof(*bcbearer));
|
2006-01-03 02:04:38 +08:00
|
|
|
}
|
|
|
|
|
2010-05-11 22:30:14 +08:00
|
|
|
|
|
|
|
/**
|
|
|
|
* tipc_nmap_add - add a node to a node map
|
|
|
|
*/
|
|
|
|
void tipc_nmap_add(struct tipc_node_map *nm_ptr, u32 node)
|
|
|
|
{
|
|
|
|
int n = tipc_node(node);
|
|
|
|
int w = n / WSIZE;
|
|
|
|
u32 mask = (1 << (n % WSIZE));
|
|
|
|
|
|
|
|
if ((nm_ptr->map[w] & mask) == 0) {
|
|
|
|
nm_ptr->count++;
|
|
|
|
nm_ptr->map[w] |= mask;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* tipc_nmap_remove - remove a node from a node map
|
|
|
|
*/
|
|
|
|
void tipc_nmap_remove(struct tipc_node_map *nm_ptr, u32 node)
|
|
|
|
{
|
|
|
|
int n = tipc_node(node);
|
|
|
|
int w = n / WSIZE;
|
|
|
|
u32 mask = (1 << (n % WSIZE));
|
|
|
|
|
|
|
|
if ((nm_ptr->map[w] & mask) != 0) {
|
|
|
|
nm_ptr->map[w] &= ~mask;
|
|
|
|
nm_ptr->count--;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* tipc_nmap_diff - find differences between node maps
|
|
|
|
* @nm_a: input node map A
|
|
|
|
* @nm_b: input node map B
|
|
|
|
* @nm_diff: output node map A-B (i.e. nodes of A that are not in B)
|
|
|
|
*/
|
2010-10-13 21:20:35 +08:00
|
|
|
static void tipc_nmap_diff(struct tipc_node_map *nm_a,
|
|
|
|
struct tipc_node_map *nm_b,
|
|
|
|
struct tipc_node_map *nm_diff)
|
2010-05-11 22:30:14 +08:00
|
|
|
{
|
|
|
|
int stop = ARRAY_SIZE(nm_a->map);
|
|
|
|
int w;
|
|
|
|
int b;
|
|
|
|
u32 map;
|
|
|
|
|
|
|
|
memset(nm_diff, 0, sizeof(*nm_diff));
|
|
|
|
for (w = 0; w < stop; w++) {
|
|
|
|
map = nm_a->map[w] ^ (nm_a->map[w] & nm_b->map[w]);
|
|
|
|
nm_diff->map[w] = map;
|
|
|
|
if (map != 0) {
|
|
|
|
for (b = 0 ; b < WSIZE; b++) {
|
|
|
|
if (map & (1 << b))
|
|
|
|
nm_diff->count++;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
2010-05-11 22:30:15 +08:00
|
|
|
|
|
|
|
/**
|
|
|
|
* tipc_port_list_add - add a port to a port list, ensuring no duplicates
|
|
|
|
*/
|
2011-12-30 09:33:30 +08:00
|
|
|
void tipc_port_list_add(struct tipc_port_list *pl_ptr, u32 port)
|
2010-05-11 22:30:15 +08:00
|
|
|
{
|
2011-12-30 09:33:30 +08:00
|
|
|
struct tipc_port_list *item = pl_ptr;
|
2010-05-11 22:30:15 +08:00
|
|
|
int i;
|
|
|
|
int item_sz = PLSIZE;
|
|
|
|
int cnt = pl_ptr->count;
|
|
|
|
|
|
|
|
for (; ; cnt -= item_sz, item = item->next) {
|
|
|
|
if (cnt < PLSIZE)
|
|
|
|
item_sz = cnt;
|
|
|
|
for (i = 0; i < item_sz; i++)
|
|
|
|
if (item->ports[i] == port)
|
|
|
|
return;
|
|
|
|
if (i < PLSIZE) {
|
|
|
|
item->ports[i] = port;
|
|
|
|
pl_ptr->count++;
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
if (!item->next) {
|
|
|
|
item->next = kmalloc(sizeof(*item), GFP_ATOMIC);
|
|
|
|
if (!item->next) {
|
2012-06-29 12:16:37 +08:00
|
|
|
pr_warn("Incomplete multicast delivery, no memory\n");
|
2010-05-11 22:30:15 +08:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
item->next->next = NULL;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* tipc_port_list_free - free dynamically created entries in port_list chain
|
|
|
|
*
|
|
|
|
*/
|
2011-12-30 09:33:30 +08:00
|
|
|
void tipc_port_list_free(struct tipc_port_list *pl_ptr)
|
2010-05-11 22:30:15 +08:00
|
|
|
{
|
2011-12-30 09:33:30 +08:00
|
|
|
struct tipc_port_list *item;
|
|
|
|
struct tipc_port_list *next;
|
2010-05-11 22:30:15 +08:00
|
|
|
|
|
|
|
for (item = pl_ptr->next; item; item = next) {
|
|
|
|
next = item->next;
|
|
|
|
kfree(item);
|
|
|
|
}
|
|
|
|
}
|