2006-01-02 21:04:38 +03:00
/*
* net / tipc / bcast . c : TIPC broadcast code
2007-02-09 17:25:21 +03:00
*
2014-07-17 04:41:00 +04:00
* Copyright ( c ) 2004 - 2006 , 2014 , Ericsson AB
2006-01-02 21:04:38 +03:00
* Copyright ( c ) 2004 , Intel Corporation .
2011-01-07 21:00:11 +03:00
* Copyright ( c ) 2005 , 2010 - 2011 , Wind River Systems
2006-01-02 21:04:38 +03:00
* All rights reserved .
*
2006-01-11 15:30:43 +03:00
* Redistribution and use in source and binary forms , with or without
2006-01-02 21:04:38 +03:00
* modification , are permitted provided that the following conditions are met :
*
2006-01-11 15:30:43 +03: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-02 21:04:38 +03:00
*
2006-01-11 15:30:43 +03: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-02 21:04:38 +03:00
* POSSIBILITY OF SUCH DAMAGE .
*/
# include "core.h"
# include "link.h"
2014-07-17 04:41:00 +04:00
# include "socket.h"
# include "msg.h"
2006-01-02 21:04:38 +03:00
# include "bcast.h"
2011-04-07 22:57:53 +04:00
# include "name_distr.h"
2006-01-02 21:04:38 +03:00
2014-03-27 08:54:35 +04:00
# define MAX_PKT_DEFAULT_MCAST 1500 /* bcast link max packet size (fixed) */
# define BCLINK_WIN_DEFAULT 20 /* bcast link window size (default) */
# define BCBEARER MAX_BEARERS
2006-01-02 21:04:38 +03:00
/**
2011-12-30 05:55:27 +04:00
* struct tipc_bcbearer_pair - a pair of bearers used by broadcast link
2006-01-02 21:04:38 +03:00
* @ primary : pointer to primary bearer
* @ secondary : pointer to secondary bearer
2007-02-09 17:25:21 +03:00
*
* Bearers must have same priority and same set of reachable destinations
2006-01-02 21:04:38 +03:00
* to be paired .
*/
2011-12-30 05:55:27 +04:00
struct tipc_bcbearer_pair {
2011-01-07 21:00:11 +03:00
struct tipc_bearer * primary ;
struct tipc_bearer * secondary ;
2006-01-02 21:04:38 +03:00
} ;
/**
2011-12-30 05:55:27 +04:00
* struct tipc_bcbearer - bearer used by broadcast link
2006-01-02 21:04:38 +03:00
* @ bearer : ( non - standard ) broadcast bearer structure
* @ media : ( non - standard ) broadcast media structure
* @ bpairs : array of bearer pairs
2006-06-26 10:53:20 +04: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 17:25:21 +03:00
*
2006-06-26 10:53:20 +04: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
2014-05-05 04:56:15 +04:00
* prevented through use of the spinlock " bclink_lock " .
2006-01-02 21:04:38 +03:00
*/
2011-12-30 05:55:27 +04:00
struct tipc_bcbearer {
2011-01-07 21:00:11 +03:00
struct tipc_bearer bearer ;
2011-12-30 05:19:42 +04:00
struct tipc_media media ;
2011-12-30 05:55:27 +04:00
struct tipc_bcbearer_pair bpairs [ MAX_BEARERS ] ;
struct tipc_bcbearer_pair bpairs_temp [ TIPC_MAX_LINK_PRI + 1 ] ;
2008-09-03 10:38:32 +04:00
struct tipc_node_map remains ;
struct tipc_node_map remains_new ;
2006-01-02 21:04:38 +03:00
} ;
/**
2011-12-30 05:52:18 +04:00
* struct tipc_bclink - link used for broadcast messages
2014-05-05 04:56:15 +04:00
* @ lock : spinlock governing access to structure
2006-01-02 21:04:38 +03:00
* @ link : ( non - standard ) broadcast link structure
* @ node : ( non - standard ) node structure representing b ' cast link ' s peer node
2014-05-05 04:56:17 +04:00
* @ flags : represent bclink states
2011-10-24 19:18:12 +04:00
* @ bcast_nodes : map of broadcast - capable nodes
2011-01-18 21:53:16 +03:00
* @ retransmit_to : node that most recently requested a retransmit
2007-02-09 17:25:21 +03:00
*
2006-01-02 21:04:38 +03:00
* Handles sequence numbering , fragmentation , bundling , etc .
*/
2011-12-30 05:52:18 +04:00
struct tipc_bclink {
2014-05-05 04:56:15 +04:00
spinlock_t lock ;
2011-12-30 05:58:42 +04:00
struct tipc_link link ;
2008-09-03 10:38:32 +04:00
struct tipc_node node ;
2014-05-05 04:56:17 +04:00
unsigned int flags ;
2011-10-24 19:18:12 +04:00
struct tipc_node_map bcast_nodes ;
2011-01-18 21:53:16 +03:00
struct tipc_node * retransmit_to ;
2006-01-02 21:04:38 +03:00
} ;
2014-05-05 04:56:16 +04:00
static struct tipc_bcbearer * bcbearer ;
static struct tipc_bclink * bclink ;
static struct tipc_link * bcl ;
2006-01-02 21:04:38 +03:00
2010-05-11 18:30:07 +04:00
const char tipc_bclink_name [ ] = " broadcast-link " ;
2006-01-02 21:04:38 +03:00
2010-10-13 17:20:35 +04:00
static void tipc_nmap_diff ( struct tipc_node_map * nm_a ,
struct tipc_node_map * nm_b ,
struct tipc_node_map * nm_diff ) ;
2014-04-21 06:55:51 +04:00
static void tipc_nmap_add ( struct tipc_node_map * nm_ptr , u32 node ) ;
static void tipc_nmap_remove ( struct tipc_node_map * nm_ptr , u32 node ) ;
2006-01-02 21:04:38 +03:00
2014-05-05 04:56:15 +04:00
static void tipc_bclink_lock ( void )
{
spin_lock_bh ( & bclink - > lock ) ;
}
static void tipc_bclink_unlock ( void )
{
2014-05-05 04:56:17 +04:00
struct tipc_node * node = NULL ;
if ( likely ( ! bclink - > flags ) ) {
spin_unlock_bh ( & bclink - > lock ) ;
return ;
}
if ( bclink - > flags & TIPC_BCLINK_RESET ) {
bclink - > flags & = ~ TIPC_BCLINK_RESET ;
node = tipc_bclink_retransmit_to ( ) ;
}
2014-05-05 04:56:15 +04:00
spin_unlock_bh ( & bclink - > lock ) ;
2014-05-05 04:56:17 +04:00
if ( node )
tipc_link_reset_all ( node ) ;
}
2014-07-17 04:41:00 +04:00
uint tipc_bclink_get_mtu ( void )
{
return MAX_PKT_DEFAULT_MCAST ;
}
2014-05-05 04:56:17 +04:00
void tipc_bclink_set_flags ( unsigned int flags )
{
bclink - > flags | = flags ;
2014-05-05 04:56:15 +04:00
}
2006-03-21 09:37:04 +03:00
static u32 bcbuf_acks ( struct sk_buff * buf )
2006-01-02 21:04:38 +03:00
{
2006-01-13 00:22:32 +03:00
return ( u32 ) ( unsigned long ) TIPC_SKB_CB ( buf ) - > handle ;
2006-01-02 21:04:38 +03:00
}
2006-03-21 09:37:04 +03:00
static void bcbuf_set_acks ( struct sk_buff * buf , u32 acks )
2006-01-02 21:04:38 +03:00
{
2006-01-13 00:22:32 +03:00
TIPC_SKB_CB ( buf ) - > handle = ( void * ) ( unsigned long ) acks ;
2006-01-02 21:04:38 +03:00
}
2006-03-21 09:37:04 +03:00
static void bcbuf_decr_acks ( struct sk_buff * buf )
2006-01-02 21:04:38 +03:00
{
bcbuf_set_acks ( buf , bcbuf_acks ( buf ) - 1 ) ;
}
2011-10-24 19:18:12 +04:00
void tipc_bclink_add_node ( u32 addr )
{
2014-05-05 04:56:15 +04:00
tipc_bclink_lock ( ) ;
2011-10-24 19:18:12 +04:00
tipc_nmap_add ( & bclink - > bcast_nodes , addr ) ;
2014-05-05 04:56:15 +04:00
tipc_bclink_unlock ( ) ;
2011-10-24 19:18:12 +04:00
}
void tipc_bclink_remove_node ( u32 addr )
{
2014-05-05 04:56:15 +04:00
tipc_bclink_lock ( ) ;
2011-10-24 19:18:12 +04:00
tipc_nmap_remove ( & bclink - > bcast_nodes , addr ) ;
2014-05-05 04:56:15 +04:00
tipc_bclink_unlock ( ) ;
2011-10-24 19:18:12 +04:00
}
2006-01-02 21:04:38 +03:00
2010-08-17 15:00:09 +04: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-27 22:17:53 +04:00
static void bclink_update_last_sent ( struct tipc_node * node , u32 seqno )
2006-01-02 21:04:38 +03: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-27 22:17:53 +04:00
node - > bclink . last_sent = less_eq ( node - > bclink . last_sent , seqno ) ?
seqno : node - > bclink . last_sent ;
2006-01-02 21:04:38 +03:00
}
2012-07-10 14:55:09 +04:00
/**
2011-01-18 21:53:16 +03:00
* tipc_bclink_retransmit_to - get most recent node to request retransmission
*
2014-05-05 04:56:15 +04:00
* Called with bclink_lock locked
2011-01-18 21:53:16 +03:00
*/
struct tipc_node * tipc_bclink_retransmit_to ( void )
{
return bclink - > retransmit_to ;
}
2007-02-09 17:25:21 +03:00
/**
2006-01-02 21:04:38 +03: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 17:25:21 +03:00
*
2014-05-05 04:56:15 +04:00
* Called with bclink_lock locked
2006-01-02 21:04:38 +03:00
*/
static void bclink_retransmit_pkt ( u32 after , u32 to )
{
struct sk_buff * buf ;
buf = bcl - > first_out ;
2010-12-31 21:59:35 +03:00
while ( buf & & less_eq ( buf_seqno ( buf ) , after ) )
2007-02-09 17:25:21 +03:00
buf = buf - > next ;
2006-06-26 10:40:01 +04:00
tipc_link_retransmit ( bcl , buf , mod ( to - after ) ) ;
2006-01-02 21:04:38 +03:00
}
2007-02-09 17:25:21 +03:00
/**
2006-01-18 02:38:21 +03:00
* tipc_bclink_acknowledge - handle acknowledgement of broadcast packets
2006-01-02 21:04:38 +03:00
* @ n_ptr : node that sent acknowledgement info
* @ acked : broadcast sequence # that has been acknowledged
2007-02-09 17:25:21 +03:00
*
2014-05-05 04:56:15 +04:00
* Node is locked , bclink_lock unlocked .
2006-01-02 21:04:38 +03:00
*/
2008-09-03 10:38:32 +04:00
void tipc_bclink_acknowledge ( struct tipc_node * n_ptr , u32 acked )
2006-01-02 21:04:38 +03:00
{
struct sk_buff * crs ;
struct sk_buff * next ;
unsigned int released = 0 ;
2014-05-05 04:56:15 +04:00
tipc_bclink_lock ( ) ;
2011-10-24 23:26:24 +04:00
/* Bail out if tx queue is empty (no clean up is required) */
2006-01-02 21:04:38 +03:00
crs = bcl - > first_out ;
2011-10-24 23:26:24 +04: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 */
2010-12-31 21:59:35 +03:00
while ( crs & & less_eq ( buf_seqno ( crs ) , n_ptr - > bclink . acked ) )
2006-01-02 21:04:38 +03:00
crs = crs - > next ;
/* Update packets that node is now acknowledging */
while ( crs & & less_eq ( buf_seqno ( crs ) , acked ) ) {
next = crs - > next ;
2011-10-24 22:59:20 +04: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-02 21:04:38 +03:00
if ( bcbuf_acks ( crs ) = = 0 ) {
bcl - > first_out = next ;
bcl - > out_queue_size - - ;
2011-11-04 21:24:29 +04:00
kfree_skb ( crs ) ;
2006-01-02 21:04:38 +03:00
released = 1 ;
}
crs = next ;
}
n_ptr - > bclink . acked = acked ;
/* Try resolving broadcast link congestion, if necessary */
2010-08-17 15:00:09 +04:00
if ( unlikely ( bcl - > next_out ) ) {
2006-01-18 02:38:21 +03:00
tipc_link_push_queue ( bcl ) ;
2010-08-17 15:00:09 +04:00
bclink_set_last_sent ( ) ;
}
2014-08-23 02:09:07 +04:00
if ( unlikely ( released & & ! skb_queue_empty ( & bcl - > waiting_sks ) ) )
bclink - > node . action_flags | = TIPC_WAKEUP_USERS ;
2011-10-24 23:26:24 +04:00
exit :
2014-05-05 04:56:15 +04:00
tipc_bclink_unlock ( ) ;
2006-01-02 21:04:38 +03:00
}
2012-07-10 14:55:09 +04: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-27 22:17:53 +04:00
* tipc_bclink_update_link_state - update broadcast link state
2007-02-09 17:25:21 +03:00
*
tipc: purge tipc_net_lock lock
Now tipc routing hierarchy comprises the structures 'node', 'link'and
'bearer'. The whole hierarchy is protected by a big read/write lock,
tipc_net_lock, to ensure that nothing is added or removed while code
is accessing any of these structures. Obviously the locking policy
makes node, link and bearer components closely bound together so that
their relationship becomes unnecessarily complex. In the worst case,
such locking policy not only has a negative influence on performance,
but also it's prone to lead to deadlock occasionally.
In order o decouple the complex relationship between bearer and node
as well as link, the locking policy is adjusted as follows:
- Bearer level
RTNL lock is used on update side, and RCU is used on read side.
Meanwhile, all bearer instances including broadcast bearer are
saved into bearer_list array.
- Node and link level
All node instances are saved into two tipc_node_list and node_htable
lists. The two lists are protected by node_list_lock on write side,
and they are guarded with RCU lock on read side. All members in node
structure including link instances are protected by node spin lock.
- The relationship between bearer and node
When link accesses bearer, it first needs to find the bearer with
its bearer identity from the bearer_list array. When bearer accesses
node, it can iterate the node_htable hash list with the node
address to find the corresponding node.
In the new locking policy, every component has its private locking
solution and the relationship between bearer and node is very simple,
that is, they can find each other with node address or bearer identity
from node_htable hash list or bearer_list array.
Until now above all changes have been done, so tipc_net_lock can be
removed safely.
Signed-off-by: Ying Xue <ying.xue@windriver.com>
Reviewed-by: Jon Maloy <jon.maloy@ericsson.com>
Reviewed-by: Erik Hugne <erik.hugne@ericsson.com>
Tested-by: Erik Hugne <erik.hugne@ericsson.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2014-04-21 06:55:48 +04:00
* RCU and node lock set
2006-01-02 21:04:38 +03: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-27 22:17:53 +04:00
void tipc_bclink_update_link_state ( struct tipc_node * n_ptr , u32 last_sent )
2006-01-02 21:04:38 +03: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-27 22:17:53 +04:00
struct sk_buff * buf ;
2006-01-02 21:04:38 +03: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-27 22:17:53 +04:00
/* Ignore "stale" link state info */
2006-01-02 21:04:38 +03: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-27 22:17:53 +04:00
if ( less_eq ( last_sent , n_ptr - > bclink . last_in ) )
return ;
2006-01-02 21:04:38 +03: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-27 22:17:53 +04: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-02 21:04:38 +03: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-27 22:17:53 +04:00
if ( n_ptr - > bclink . oos_state & 0x1 )
2006-01-02 21:04:38 +03: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-27 22:17:53 +04:00
/* Send NACK */
2010-10-13 17:20:35 +04:00
buf = tipc_buf_acquire ( INT_H_SIZE ) ;
2006-01-02 21:04:38 +03: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-27 22:17:53 +04:00
struct tipc_msg * msg = buf_msg ( buf ) ;
2010-05-11 18:30:12 +04: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-27 22:17:53 +04:00
INT_H_SIZE , n_ptr - > addr ) ;
2011-01-26 00:12:39 +03:00
msg_set_non_seq ( msg , 1 ) ;
2006-01-02 21:04:38 +03: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-27 22:17:53 +04: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-02 21:04:38 +03:00
2014-05-05 04:56:15 +04:00
tipc_bclink_lock ( ) ;
tipc: decouple the relationship between bearer and link
Currently on both paths of message transmission and reception, the
read lock of tipc_net_lock must be held before bearer is accessed,
while the write lock of tipc_net_lock has to be taken before bearer
is configured. Although it can ensure that bearer is always valid on
the two data paths, link and bearer is closely bound together.
So as the part of effort of removing tipc_net_lock, the locking
policy of bearer protection will be adjusted as below: on the two
data paths, RCU is used, and on the configuration path of bearer,
RTNL lock is applied.
Now RCU just covers the path of message reception. To make it possible
to protect the path of message transmission with RCU, link should not
use its stored bearer pointer to access bearer, but it should use the
bearer identity of its attached bearer as index to get bearer instance
from bearer_list array, which can help us decouple the relationship
between bearer and link. As a result, bearer on the path of message
transmission can be safely protected by RCU when we access bearer_list
array within RCU lock protection.
Signed-off-by: Ying Xue <ying.xue@windriver.com>
Reviewed-by: Jon Maloy <jon.maloy@ericsson.com>
Reviewed-by: Erik Hugne <erik.hugne@ericsson.com>
Tested-by: Erik Hugne <erik.hugne@ericsson.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2014-04-21 06:55:46 +04:00
tipc_bearer_send ( MAX_BEARERS , buf , NULL ) ;
2011-04-07 23:47:48 +04:00
bcl - > stats . sent_nacks + + ;
2014-05-05 04:56:15 +04:00
tipc_bclink_unlock ( ) ;
2011-11-04 21:24:29 +04:00
kfree_skb ( buf ) ;
2006-01-02 21:04:38 +03: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-27 22:17:53 +04:00
n_ptr - > bclink . oos_state + + ;
2006-01-02 21:04:38 +03:00
}
}
2012-07-10 14:55:09 +04: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-27 22:17:53 +04:00
* bclink_peek_nack - monitor retransmission requests sent by other nodes
2006-01-02 21:04:38 +03: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-27 22:17:53 +04:00
* Delay any upcoming NACK by this node if another node has already
* requested the first message this node is going to ask for .
2006-01-02 21:04:38 +03: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-27 22:17:53 +04:00
static void bclink_peek_nack ( struct tipc_msg * msg )
2006-01-02 21:04:38 +03: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-27 22:17:53 +04:00
struct tipc_node * n_ptr = tipc_node_find ( msg_destnode ( msg ) ) ;
2006-01-02 21:04:38 +03: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-27 22:17:53 +04:00
if ( unlikely ( ! n_ptr ) )
2006-01-02 21:04:38 +03: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-27 22:17:53 +04:00
2006-01-18 02:38:21 +03: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-27 22:17:53 +04:00
2012-11-16 09:51:30 +04: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-27 22:17:53 +04: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 02:38:21 +03:00
tipc_node_unlock ( n_ptr ) ;
2006-01-02 21:04:38 +03:00
}
2014-07-17 04:41:03 +04:00
/* tipc_bclink_xmit - broadcast buffer chain to all nodes in cluster
* and to identified node local sockets
2014-07-17 04:41:00 +04:00
* @ buf : chain of buffers containing message
* Consumes the buffer chain , except when returning - ELINKCONG
* Returns 0 if success , otherwise errno : - ELINKCONG , - EHOSTUNREACH , - EMSGSIZE
*/
2014-07-17 04:41:03 +04:00
int tipc_bclink_xmit ( struct sk_buff * buf )
2014-07-17 04:41:00 +04:00
{
int rc = 0 ;
int bc = 0 ;
struct sk_buff * clbuf ;
/* Prepare clone of message for local node */
clbuf = tipc_msg_reassemble ( buf ) ;
if ( unlikely ( ! clbuf ) ) {
kfree_skb_list ( buf ) ;
return - EHOSTUNREACH ;
}
/* Broadcast to all other nodes */
if ( likely ( bclink ) ) {
tipc_bclink_lock ( ) ;
if ( likely ( bclink - > bcast_nodes . count ) ) {
rc = __tipc_link_xmit ( bcl , buf ) ;
if ( likely ( ! rc ) ) {
bclink_set_last_sent ( ) ;
bcl - > stats . queue_sz_counts + + ;
bcl - > stats . accu_queue_sz + = bcl - > out_queue_size ;
}
bc = 1 ;
}
tipc_bclink_unlock ( ) ;
}
if ( unlikely ( ! bc ) )
kfree_skb_list ( buf ) ;
/* Deliver message clone */
if ( likely ( ! rc ) )
tipc_sk_mcast_rcv ( clbuf ) ;
else
kfree_skb ( clbuf ) ;
return rc ;
}
2012-07-10 14:55:09 +04:00
/**
2011-10-28 00:43:09 +04:00
* bclink_accept_pkt - accept an incoming , in - sequence broadcast packet
*
2014-05-05 04:56:15 +04:00
* Called with both sending node ' s lock and bclink_lock taken .
2011-10-28 00:43:09 +04:00
*/
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 12:06:46 +04:00
tipc_link_proto_xmit ( node - > active_links [ node - > addr & 1 ] ,
STATE_MSG , 0 , 0 , 0 , 0 , 0 ) ;
2011-10-28 00:43:09 +04:00
bcl - > stats . sent_acks + + ;
}
}
2012-07-10 14:55:09 +04:00
/**
2014-02-18 12:06:46 +04:00
* tipc_bclink_rcv - receive a broadcast packet , and deliver upwards
2007-02-09 17:25:21 +03:00
*
tipc: purge tipc_net_lock lock
Now tipc routing hierarchy comprises the structures 'node', 'link'and
'bearer'. The whole hierarchy is protected by a big read/write lock,
tipc_net_lock, to ensure that nothing is added or removed while code
is accessing any of these structures. Obviously the locking policy
makes node, link and bearer components closely bound together so that
their relationship becomes unnecessarily complex. In the worst case,
such locking policy not only has a negative influence on performance,
but also it's prone to lead to deadlock occasionally.
In order o decouple the complex relationship between bearer and node
as well as link, the locking policy is adjusted as follows:
- Bearer level
RTNL lock is used on update side, and RCU is used on read side.
Meanwhile, all bearer instances including broadcast bearer are
saved into bearer_list array.
- Node and link level
All node instances are saved into two tipc_node_list and node_htable
lists. The two lists are protected by node_list_lock on write side,
and they are guarded with RCU lock on read side. All members in node
structure including link instances are protected by node spin lock.
- The relationship between bearer and node
When link accesses bearer, it first needs to find the bearer with
its bearer identity from the bearer_list array. When bearer accesses
node, it can iterate the node_htable hash list with the node
address to find the corresponding node.
In the new locking policy, every component has its private locking
solution and the relationship between bearer and node is very simple,
that is, they can find each other with node address or bearer identity
from node_htable hash list or bearer_list array.
Until now above all changes have been done, so tipc_net_lock can be
removed safely.
Signed-off-by: Ying Xue <ying.xue@windriver.com>
Reviewed-by: Jon Maloy <jon.maloy@ericsson.com>
Reviewed-by: Erik Hugne <erik.hugne@ericsson.com>
Tested-by: Erik Hugne <erik.hugne@ericsson.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2014-04-21 06:55:48 +04:00
* RCU is locked , no other locks set
2006-01-02 21:04:38 +03:00
*/
2014-02-18 12:06:46 +04:00
void tipc_bclink_rcv ( struct sk_buff * buf )
2006-06-26 10:40:01 +04:00
{
2006-01-02 21:04:38 +03:00
struct tipc_msg * msg = buf_msg ( buf ) ;
2011-04-07 21:57:25 +04:00
struct tipc_node * node ;
2006-01-02 21:04:38 +03:00
u32 next_in ;
u32 seqno ;
2014-07-17 04:41:01 +04:00
int deferred = 0 ;
2006-01-02 21:04:38 +03:00
2011-04-07 21:57:25 +04: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 09:51:30 +04:00
if ( unlikely ( ! node - > bclink . recv_permitted ) )
2011-04-07 21:57:25 +04:00
goto unlock ;
2006-01-02 21:04:38 +03:00
2011-10-26 23:33:44 +04:00
/* Handle broadcast protocol message */
2006-01-02 21:04:38 +03:00
if ( unlikely ( msg_user ( msg ) = = BCAST_PROTOCOL ) ) {
2011-04-07 22:57:53 +04:00
if ( msg_type ( msg ) ! = STATE_MSG )
goto unlock ;
2006-01-02 21:04:38 +03:00
if ( msg_destnode ( msg ) = = tipc_own_addr ) {
2006-01-18 02:38:21 +03:00
tipc_bclink_acknowledge ( node , msg_bcast_ack ( msg ) ) ;
tipc_node_unlock ( node ) ;
2014-05-05 04:56:15 +04:00
tipc_bclink_lock ( ) ;
2006-01-02 21:04:38 +03:00
bcl - > stats . recv_nacks + + ;
2011-01-18 21:53:16 +03:00
bclink - > retransmit_to = node ;
2006-01-02 21:04:38 +03:00
bclink_retransmit_pkt ( msg_bcgap_after ( msg ) ,
msg_bcgap_to ( msg ) ) ;
2014-05-05 04:56:15 +04:00
tipc_bclink_unlock ( ) ;
2006-01-02 21:04:38 +03:00
} else {
2011-04-07 21:57:25 +04: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-27 22:17:53 +04:00
bclink_peek_nack ( msg ) ;
2006-01-02 21:04:38 +03:00
}
2011-04-07 21:57:25 +04:00
goto exit ;
2006-01-02 21:04:38 +03:00
}
2011-04-07 21:57:25 +04:00
/* Handle in-sequence broadcast message */
2006-01-02 21:04:38 +03:00
seqno = msg_seqno ( msg ) ;
2011-10-26 23:33:44 +04:00
next_in = mod ( node - > bclink . last_in + 1 ) ;
2006-01-02 21:04:38 +03:00
if ( likely ( seqno = = next_in ) ) {
2011-10-26 23:33:44 +04: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-27 22:17:53 +04:00
/* Deliver message to destination */
2006-01-02 21:04:38 +03:00
if ( likely ( msg_isdata ( msg ) ) ) {
2014-05-05 04:56:15 +04:00
tipc_bclink_lock ( ) ;
2011-10-28 00:43:09 +04:00
bclink_accept_pkt ( node , seqno ) ;
2014-05-05 04:56:15 +04:00
tipc_bclink_unlock ( ) ;
2006-01-18 02:38:21 +03:00
tipc_node_unlock ( node ) ;
2011-04-07 22:57:53 +04:00
if ( likely ( msg_mcast ( msg ) ) )
2014-07-17 04:41:01 +04:00
tipc_sk_mcast_rcv ( buf ) ;
2011-04-07 22:57:53 +04:00
else
2011-11-04 21:24:29 +04:00
kfree_skb ( buf ) ;
2006-01-02 21:04:38 +03:00
} else if ( msg_user ( msg ) = = MSG_BUNDLER ) {
2014-05-05 04:56:15 +04:00
tipc_bclink_lock ( ) ;
2011-10-28 00:43:09 +04:00
bclink_accept_pkt ( node , seqno ) ;
2006-01-02 21:04:38 +03:00
bcl - > stats . recv_bundles + + ;
bcl - > stats . recv_bundled + = msg_msgcnt ( msg ) ;
2014-05-05 04:56:15 +04:00
tipc_bclink_unlock ( ) ;
2006-01-18 02:38:21 +03:00
tipc_node_unlock ( node ) ;
2014-02-18 12:06:46 +04:00
tipc_link_bundle_rcv ( buf ) ;
2006-01-02 21:04:38 +03:00
} else if ( msg_user ( msg ) = = MSG_FRAGMENTER ) {
2014-05-14 13:39:12 +04:00
tipc_buf_append ( & node - > bclink . reasm_buf , & buf ) ;
if ( unlikely ( ! buf & & ! node - > bclink . reasm_buf ) )
2011-10-28 00:43:09 +04:00
goto unlock ;
2014-05-05 04:56:15 +04:00
tipc_bclink_lock ( ) ;
2011-10-28 00:43:09 +04:00
bclink_accept_pkt ( node , seqno ) ;
2006-01-02 21:04:38 +03:00
bcl - > stats . recv_fragments + + ;
2014-05-14 13:39:12 +04:00
if ( buf ) {
2006-01-02 21:04:38 +03: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 12:28:06 +04:00
msg = buf_msg ( buf ) ;
2014-05-05 04:56:15 +04:00
tipc_bclink_unlock ( ) ;
2013-11-06 12:28:05 +04:00
goto receive ;
}
2014-05-05 04:56:15 +04:00
tipc_bclink_unlock ( ) ;
2006-01-18 02:38:21 +03:00
tipc_node_unlock ( node ) ;
2011-04-07 22:57:53 +04:00
} else if ( msg_user ( msg ) = = NAME_DISTRIBUTOR ) {
2014-05-05 04:56:15 +04:00
tipc_bclink_lock ( ) ;
2011-10-28 00:43:09 +04:00
bclink_accept_pkt ( node , seqno ) ;
2014-05-05 04:56:15 +04:00
tipc_bclink_unlock ( ) ;
2011-04-07 22:57:53 +04:00
tipc_node_unlock ( node ) ;
2014-02-18 12:06:46 +04:00
tipc_named_rcv ( buf ) ;
2006-01-02 21:04:38 +03:00
} else {
2014-05-05 04:56:15 +04:00
tipc_bclink_lock ( ) ;
2011-10-28 00:43:09 +04:00
bclink_accept_pkt ( node , seqno ) ;
2014-05-05 04:56:15 +04:00
tipc_bclink_unlock ( ) ;
2006-01-18 02:38:21 +03:00
tipc_node_unlock ( node ) ;
2011-11-04 21:24:29 +04:00
kfree_skb ( buf ) ;
2006-01-02 21:04:38 +03:00
}
2011-04-07 21:57:25 +04:00
buf = NULL ;
2011-10-26 23:33:44 +04:00
/* Determine new synchronization state */
2011-04-07 21:57:25 +04:00
tipc_node_lock ( node ) ;
2011-10-26 23:33:44 +04: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-27 22:17:53 +04:00
if ( node - > bclink . last_in = = node - > bclink . last_sent )
2011-10-26 23:33:44 +04: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-27 22:17:53 +04:00
if ( ! node - > bclink . deferred_head ) {
node - > bclink . oos_state = 1 ;
goto unlock ;
}
2011-10-26 23:33:44 +04: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 ;
2014-07-11 16:45:27 +04:00
buf - > next = NULL ;
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-27 22:17:53 +04:00
node - > bclink . deferred_size - - ;
2011-10-26 23:33:44 +04: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-27 22:17:53 +04:00
node - > bclink . deferred_size + = deferred ;
bclink_update_last_sent ( node , seqno ) ;
2011-04-07 21:57:25 +04:00
buf = NULL ;
2014-07-17 04:41:01 +04:00
}
2011-10-26 23:33:44 +04:00
2014-05-05 04:56:15 +04:00
tipc_bclink_lock ( ) ;
2011-10-27 00:13:35 +04:00
2011-10-26 23:33:44 +04:00
if ( deferred )
bcl - > stats . deferred_recv + + ;
2011-10-26 23:57:26 +04:00
else
bcl - > stats . duplicates + + ;
2011-10-26 23:33:44 +04:00
2014-05-05 04:56:15 +04:00
tipc_bclink_unlock ( ) ;
2011-10-27 00:13:35 +04:00
2011-04-07 21:57:25 +04:00
unlock :
2006-01-18 02:38:21 +03:00
tipc_node_unlock ( node ) ;
2011-04-07 21:57:25 +04:00
exit :
2011-11-04 21:24:29 +04:00
kfree_skb ( buf ) ;
2006-01-02 21:04:38 +03:00
}
2008-09-03 10:38:32 +04:00
u32 tipc_bclink_acks_missing ( struct tipc_node * n_ptr )
2006-01-02 21:04:38 +03:00
{
2012-11-16 09:51:30 +04:00
return ( n_ptr - > bclink . recv_permitted & &
2006-01-18 02:38:21 +03:00
( tipc_bclink_get_last_sent ( ) ! = n_ptr - > bclink . acked ) ) ;
2006-01-02 21:04:38 +03:00
}
/**
2006-01-18 02:38:21 +03:00
* tipc_bcbearer_send - send a packet through the broadcast pseudo - bearer
2007-02-09 17:25:21 +03:00
*
2011-04-07 18:44:54 +04:00
* Send packet over as many bearers as necessary to reach all nodes
* that have joined the broadcast link .
2007-02-09 17:25:21 +03:00
*
2011-04-07 18:44:54 +04:00
* Returns 0 ( packet sent successfully ) under all circumstances ,
* since the broadcast link ' s pseudo - bearer never blocks
2006-01-02 21:04:38 +03:00
*/
2013-06-17 18:54:47 +04:00
static int tipc_bcbearer_send ( struct sk_buff * buf , struct tipc_bearer * unused1 ,
2006-03-21 09:37:52 +03:00
struct tipc_media_addr * unused2 )
2006-01-02 21:04:38 +03:00
{
int bp_index ;
tipc: ensure sequential message delivery across dual bearers
When we run broadcast packets over dual bearers/interfaces, the
current transmission code is flipping bearers between each sent
packet, with the purpose of leveraging the double bandwidth
available. The receiving bclink is resequencing the packets if
needed, so all messages are delivered upwards from the broadcast
link in the correct order, even if they may arrive in concurrent
interrupts.
However, at the moment of delivery upwards to the socket, we release
all spinlocks (bclink_lock, node_lock), so it is still possible
that arriving messages bypass each other before they reach the socket
queue.
We fix this by applying the same technique we are using for unicast
traffic. We use a link selector (i.e., the last bit of sending port
number) to ensure that messages from the same sender socket always are
sent over the same bearer. This guarantees sequential delivery between
socket pairs, which is sufficient to satisfy the protocol spec, as well
as all known user requirements.
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Reviewed-by: Erik Hugne <erik.hugne@ericsson.com>
Reviewed-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2014-07-17 04:41:04 +04:00
struct tipc_msg * msg = buf_msg ( buf ) ;
2006-01-02 21:04:38 +03:00
2013-05-01 16:04:44 +04:00
/* Prepare broadcast link message for reliable transmission,
2011-04-07 18:44:54 +04: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-02 21:04:38 +03:00
if ( likely ( ! msg_non_seq ( buf_msg ( buf ) ) ) ) {
2011-10-24 19:18:12 +04:00
bcbuf_set_acks ( buf , bclink - > bcast_nodes . count ) ;
2008-06-05 04:54:48 +04:00
msg_set_non_seq ( msg , 1 ) ;
2006-01-02 21:04:38 +03:00
msg_set_mc_netid ( msg , tipc_net_id ) ;
2010-08-17 15:00:10 +04:00
bcl - > stats . sent_info + + ;
2011-05-23 21:14:18 +04:00
2011-10-24 19:18:12 +04:00
if ( WARN_ON ( ! bclink - > bcast_nodes . count ) ) {
2011-05-23 21:14:18 +04:00
dump_stack ( ) ;
return 0 ;
}
2006-01-02 21:04:38 +03:00
}
/* Send buffer over bearers until all targets reached */
2011-10-24 19:18:12 +04:00
bcbearer - > remains = bclink - > bcast_nodes ;
2006-01-02 21:04:38 +03:00
for ( bp_index = 0 ; bp_index < MAX_BEARERS ; bp_index + + ) {
2011-01-07 21:00:11 +03:00
struct tipc_bearer * p = bcbearer - > bpairs [ bp_index ] . primary ;
struct tipc_bearer * s = bcbearer - > bpairs [ bp_index ] . secondary ;
tipc: ensure sequential message delivery across dual bearers
When we run broadcast packets over dual bearers/interfaces, the
current transmission code is flipping bearers between each sent
packet, with the purpose of leveraging the double bandwidth
available. The receiving bclink is resequencing the packets if
needed, so all messages are delivered upwards from the broadcast
link in the correct order, even if they may arrive in concurrent
interrupts.
However, at the moment of delivery upwards to the socket, we release
all spinlocks (bclink_lock, node_lock), so it is still possible
that arriving messages bypass each other before they reach the socket
queue.
We fix this by applying the same technique we are using for unicast
traffic. We use a link selector (i.e., the last bit of sending port
number) to ensure that messages from the same sender socket always are
sent over the same bearer. This guarantees sequential delivery between
socket pairs, which is sufficient to satisfy the protocol spec, as well
as all known user requirements.
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Reviewed-by: Erik Hugne <erik.hugne@ericsson.com>
Reviewed-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2014-07-17 04:41:04 +04:00
struct tipc_bearer * bp [ 2 ] = { p , s } ;
struct tipc_bearer * b = bp [ msg_link_selector ( msg ) ] ;
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 16:04:46 +04:00
struct sk_buff * tbuf ;
2006-01-02 21:04:38 +03:00
if ( ! p )
2013-05-01 16:04:44 +04:00
break ; /* No more bearers to try */
tipc: ensure sequential message delivery across dual bearers
When we run broadcast packets over dual bearers/interfaces, the
current transmission code is flipping bearers between each sent
packet, with the purpose of leveraging the double bandwidth
available. The receiving bclink is resequencing the packets if
needed, so all messages are delivered upwards from the broadcast
link in the correct order, even if they may arrive in concurrent
interrupts.
However, at the moment of delivery upwards to the socket, we release
all spinlocks (bclink_lock, node_lock), so it is still possible
that arriving messages bypass each other before they reach the socket
queue.
We fix this by applying the same technique we are using for unicast
traffic. We use a link selector (i.e., the last bit of sending port
number) to ensure that messages from the same sender socket always are
sent over the same bearer. This guarantees sequential delivery between
socket pairs, which is sufficient to satisfy the protocol spec, as well
as all known user requirements.
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Reviewed-by: Erik Hugne <erik.hugne@ericsson.com>
Reviewed-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2014-07-17 04:41:04 +04:00
if ( ! b )
b = p ;
2013-05-01 16:04:45 +04:00
tipc_nmap_diff ( & bcbearer - > remains , & b - > nodes ,
2013-05-01 16:04:44 +04:00
& bcbearer - > remains_new ) ;
2006-06-26 10:53:20 +04:00
if ( bcbearer - > remains_new . count = = bcbearer - > remains . count )
2013-05-01 16:04:44 +04:00
continue ; /* Nothing added by bearer pair */
2006-01-02 21:04:38 +03: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 16:04:46 +04:00
if ( bp_index = = 0 ) {
/* Use original buffer for first bearer */
tipc: decouple the relationship between bearer and link
Currently on both paths of message transmission and reception, the
read lock of tipc_net_lock must be held before bearer is accessed,
while the write lock of tipc_net_lock has to be taken before bearer
is configured. Although it can ensure that bearer is always valid on
the two data paths, link and bearer is closely bound together.
So as the part of effort of removing tipc_net_lock, the locking
policy of bearer protection will be adjusted as below: on the two
data paths, RCU is used, and on the configuration path of bearer,
RTNL lock is applied.
Now RCU just covers the path of message reception. To make it possible
to protect the path of message transmission with RCU, link should not
use its stored bearer pointer to access bearer, but it should use the
bearer identity of its attached bearer as index to get bearer instance
from bearer_list array, which can help us decouple the relationship
between bearer and link. As a result, bearer on the path of message
transmission can be safely protected by RCU when we access bearer_list
array within RCU lock protection.
Signed-off-by: Ying Xue <ying.xue@windriver.com>
Reviewed-by: Jon Maloy <jon.maloy@ericsson.com>
Reviewed-by: Erik Hugne <erik.hugne@ericsson.com>
Tested-by: Erik Hugne <erik.hugne@ericsson.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2014-04-21 06:55:46 +04:00
tipc_bearer_send ( b - > identity , buf , & b - > bcast_addr ) ;
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 16:04:46 +04:00
} else {
/* Avoid concurrent buffer access */
2014-06-12 02:36:26 +04:00
tbuf = pskb_copy_for_clone ( buf , GFP_ATOMIC ) ;
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 16:04:46 +04:00
if ( ! tbuf )
break ;
tipc: decouple the relationship between bearer and link
Currently on both paths of message transmission and reception, the
read lock of tipc_net_lock must be held before bearer is accessed,
while the write lock of tipc_net_lock has to be taken before bearer
is configured. Although it can ensure that bearer is always valid on
the two data paths, link and bearer is closely bound together.
So as the part of effort of removing tipc_net_lock, the locking
policy of bearer protection will be adjusted as below: on the two
data paths, RCU is used, and on the configuration path of bearer,
RTNL lock is applied.
Now RCU just covers the path of message reception. To make it possible
to protect the path of message transmission with RCU, link should not
use its stored bearer pointer to access bearer, but it should use the
bearer identity of its attached bearer as index to get bearer instance
from bearer_list array, which can help us decouple the relationship
between bearer and link. As a result, bearer on the path of message
transmission can be safely protected by RCU when we access bearer_list
array within RCU lock protection.
Signed-off-by: Ying Xue <ying.xue@windriver.com>
Reviewed-by: Jon Maloy <jon.maloy@ericsson.com>
Reviewed-by: Erik Hugne <erik.hugne@ericsson.com>
Tested-by: Erik Hugne <erik.hugne@ericsson.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2014-04-21 06:55:46 +04:00
tipc_bearer_send ( b - > identity , tbuf , & b - > bcast_addr ) ;
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 16:04:46 +04:00
kfree_skb ( tbuf ) ; /* Bearer keeps a clone */
}
2006-06-26 10:53:20 +04:00
if ( bcbearer - > remains_new . count = = 0 )
2013-05-01 16:04:44 +04:00
break ; /* All targets reached */
2006-01-02 21:04:38 +03:00
2006-06-26 10:53:20 +04:00
bcbearer - > remains = bcbearer - > remains_new ;
2006-01-02 21:04:38 +03:00
}
2007-02-09 17:25:21 +03:00
2011-04-07 18:44:54 +04:00
return 0 ;
2006-01-02 21:04:38 +03:00
}
/**
2006-01-18 02:38:21 +03:00
* tipc_bcbearer_sort - create sets of bearer pairs used by broadcast bearer
2006-01-02 21:04:38 +03:00
*/
2014-04-21 06:55:51 +04:00
void tipc_bcbearer_sort ( struct tipc_node_map * nm_ptr , u32 node , bool action )
2006-01-02 21:04:38 +03:00
{
2011-12-30 05:55:27 +04:00
struct tipc_bcbearer_pair * bp_temp = bcbearer - > bpairs_temp ;
struct tipc_bcbearer_pair * bp_curr ;
2014-04-21 06:55:45 +04:00
struct tipc_bearer * b ;
2006-01-02 21:04:38 +03:00
int b_index ;
int pri ;
2014-05-05 04:56:15 +04:00
tipc_bclink_lock ( ) ;
2006-01-02 21:04:38 +03:00
2014-04-21 06:55:51 +04:00
if ( action )
tipc_nmap_add ( nm_ptr , node ) ;
else
tipc_nmap_remove ( nm_ptr , node ) ;
2006-01-02 21:04:38 +03:00
/* Group bearers by priority (can assume max of two per priority) */
memset ( bp_temp , 0 , sizeof ( bcbearer - > bpairs_temp ) ) ;
2014-04-21 06:55:45 +04:00
rcu_read_lock ( ) ;
2006-01-02 21:04:38 +03:00
for ( b_index = 0 ; b_index < MAX_BEARERS ; b_index + + ) {
2014-04-21 06:55:45 +04:00
b = rcu_dereference_rtnl ( bearer_list [ b_index ] ) ;
2014-03-27 08:54:34 +04:00
if ( ! b | | ! b - > nodes . count )
2006-01-02 21:04:38 +03:00
continue ;
if ( ! bp_temp [ b - > priority ] . primary )
bp_temp [ b - > priority ] . primary = b ;
else
bp_temp [ b - > priority ] . secondary = b ;
}
2014-04-21 06:55:45 +04:00
rcu_read_unlock ( ) ;
2006-01-02 21:04:38 +03:00
/* Create array of bearer pairs for broadcasting */
bp_curr = bcbearer - > bpairs ;
memset ( bcbearer - > bpairs , 0 , sizeof ( bcbearer - > bpairs ) ) ;
2006-01-14 00:22:22 +03:00
for ( pri = TIPC_MAX_LINK_PRI ; pri > = 0 ; pri - - ) {
2006-01-02 21:04:38 +03:00
if ( ! bp_temp [ pri ] . primary )
continue ;
bp_curr - > primary = bp_temp [ pri ] . primary ;
if ( bp_temp [ pri ] . secondary ) {
2006-01-18 02:38:21 +03:00
if ( tipc_nmap_equal ( & bp_temp [ pri ] . primary - > nodes ,
& bp_temp [ pri ] . secondary - > nodes ) ) {
2006-01-02 21:04:38 +03:00
bp_curr - > secondary = bp_temp [ pri ] . secondary ;
} else {
bp_curr + + ;
bp_curr - > primary = bp_temp [ pri ] . secondary ;
}
}
bp_curr + + ;
}
2014-05-05 04:56:15 +04:00
tipc_bclink_unlock ( ) ;
2006-01-02 21:04:38 +03:00
}
2006-01-18 02:38:21 +03:00
int tipc_bclink_stats ( char * buf , const u32 buf_size )
2006-01-02 21:04:38 +03:00
{
2012-06-29 08:50:23 +04:00
int ret ;
struct tipc_stats * s ;
2006-01-02 21:04:38 +03:00
if ( ! bcl )
return 0 ;
2014-05-05 04:56:15 +04:00
tipc_bclink_lock ( ) ;
2006-01-02 21:04:38 +03:00
2012-06-29 08:50:23 +04: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 07:34:45 +04:00
" Congestion link:%u Send queue max:%u avg:%u \n " ,
s - > link_congs , s - > max_queue_sz ,
2012-06-29 08:50:23 +04:00
s - > queue_sz_counts ?
( s - > accu_queue_sz / s - > queue_sz_counts ) : 0 ) ;
2006-01-02 21:04:38 +03:00
2014-05-05 04:56:15 +04:00
tipc_bclink_unlock ( ) ;
2012-06-29 08:50:23 +04:00
return ret ;
2006-01-02 21:04:38 +03:00
}
2006-01-18 02:38:21 +03:00
int tipc_bclink_reset_stats ( void )
2006-01-02 21:04:38 +03:00
{
if ( ! bcl )
return - ENOPROTOOPT ;
2014-05-05 04:56:15 +04:00
tipc_bclink_lock ( ) ;
2006-01-02 21:04:38 +03:00
memset ( & bcl - > stats , 0 , sizeof ( bcl - > stats ) ) ;
2014-05-05 04:56:15 +04:00
tipc_bclink_unlock ( ) ;
2008-07-15 09:44:01 +04:00
return 0 ;
2006-01-02 21:04:38 +03:00
}
2006-01-18 02:38:21 +03:00
int tipc_bclink_set_queue_limits ( u32 limit )
2006-01-02 21:04:38 +03:00
{
if ( ! bcl )
return - ENOPROTOOPT ;
if ( ( limit < TIPC_MIN_LINK_WIN ) | | ( limit > TIPC_MAX_LINK_WIN ) )
return - EINVAL ;
2014-05-05 04:56:15 +04:00
tipc_bclink_lock ( ) ;
2006-01-18 02:38:21 +03:00
tipc_link_set_queue_limits ( bcl , limit ) ;
2014-05-05 04:56:15 +04:00
tipc_bclink_unlock ( ) ;
2008-07-15 09:44:01 +04:00
return 0 ;
2006-01-02 21:04:38 +03:00
}
2014-05-05 04:56:16 +04:00
int tipc_bclink_init ( void )
2006-01-02 21:04:38 +03:00
{
2014-05-05 04:56:16 +04:00
bcbearer = kzalloc ( sizeof ( * bcbearer ) , GFP_ATOMIC ) ;
if ( ! bcbearer )
return - ENOMEM ;
bclink = kzalloc ( sizeof ( * bclink ) , GFP_ATOMIC ) ;
if ( ! bclink ) {
kfree ( bcbearer ) ;
return - ENOMEM ;
}
bcl = & bclink - > link ;
2006-01-02 21:04:38 +03:00
bcbearer - > bearer . media = & bcbearer - > media ;
2006-01-18 02:38:21 +03:00
bcbearer - > media . send_msg = tipc_bcbearer_send ;
2011-04-07 18:22:31 +04:00
sprintf ( bcbearer - > media . name , " tipc-broadcast " ) ;
2006-01-02 21:04:38 +03:00
2014-05-05 04:56:15 +04:00
spin_lock_init ( & bclink - > lock ) ;
2014-08-23 02:09:07 +04:00
__skb_queue_head_init ( & bcl - > waiting_sks ) ;
2006-01-02 21:04:38 +03:00
bcl - > next_out_no = 1 ;
2006-06-27 13:53:55 +04:00
spin_lock_init ( & bclink - > node . lock ) ;
2014-08-23 02:09:07 +04:00
__skb_queue_head_init ( & bclink - > node . waiting_sks ) ;
2006-01-02 21:04:38 +03:00
bcl - > owner = & bclink - > node ;
2007-02-09 17:25:21 +03:00
bcl - > max_pkt = MAX_PKT_DEFAULT_MCAST ;
2006-01-18 02:38:21 +03:00
tipc_link_set_queue_limits ( bcl , BCLINK_WIN_DEFAULT ) ;
tipc: decouple the relationship between bearer and link
Currently on both paths of message transmission and reception, the
read lock of tipc_net_lock must be held before bearer is accessed,
while the write lock of tipc_net_lock has to be taken before bearer
is configured. Although it can ensure that bearer is always valid on
the two data paths, link and bearer is closely bound together.
So as the part of effort of removing tipc_net_lock, the locking
policy of bearer protection will be adjusted as below: on the two
data paths, RCU is used, and on the configuration path of bearer,
RTNL lock is applied.
Now RCU just covers the path of message reception. To make it possible
to protect the path of message transmission with RCU, link should not
use its stored bearer pointer to access bearer, but it should use the
bearer identity of its attached bearer as index to get bearer instance
from bearer_list array, which can help us decouple the relationship
between bearer and link. As a result, bearer on the path of message
transmission can be safely protected by RCU when we access bearer_list
array within RCU lock protection.
Signed-off-by: Ying Xue <ying.xue@windriver.com>
Reviewed-by: Jon Maloy <jon.maloy@ericsson.com>
Reviewed-by: Erik Hugne <erik.hugne@ericsson.com>
Tested-by: Erik Hugne <erik.hugne@ericsson.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2014-04-21 06:55:46 +04:00
bcl - > bearer_id = MAX_BEARERS ;
2014-04-21 06:55:45 +04:00
rcu_assign_pointer ( bearer_list [ MAX_BEARERS ] , & bcbearer - > bearer ) ;
2006-01-02 21:04:38 +03:00
bcl - > state = WORKING_WORKING ;
2009-03-19 05:11:29 +03:00
strlcpy ( bcl - > name , tipc_bclink_name , TIPC_MAX_LINK_NAME ) ;
2014-05-05 04:56:16 +04:00
return 0 ;
2006-01-02 21:04:38 +03:00
}
2006-01-18 02:38:21 +03:00
void tipc_bclink_stop ( void )
2006-01-02 21:04:38 +03:00
{
2014-05-05 04:56:15 +04:00
tipc_bclink_lock ( ) ;
2014-01-08 02:02:44 +04:00
tipc_link_purge_queues ( bcl ) ;
2014-05-05 04:56:15 +04:00
tipc_bclink_unlock ( ) ;
2011-10-24 18:29:26 +04:00
2014-04-21 06:55:45 +04:00
RCU_INIT_POINTER ( bearer_list [ BCBEARER ] , NULL ) ;
2014-05-05 04:56:16 +04:00
synchronize_net ( ) ;
kfree ( bcbearer ) ;
kfree ( bclink ) ;
2006-01-02 21:04:38 +03:00
}
2010-05-11 18:30:14 +04:00
/**
* tipc_nmap_add - add a node to a node map
*/
2014-04-21 06:55:51 +04:00
static void tipc_nmap_add ( struct tipc_node_map * nm_ptr , u32 node )
2010-05-11 18:30:14 +04:00
{
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
*/
2014-04-21 06:55:51 +04:00
static void tipc_nmap_remove ( struct tipc_node_map * nm_ptr , u32 node )
2010-05-11 18:30:14 +04:00
{
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 17:20:35 +04: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 18:30:14 +04: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 18:30:15 +04:00
/**
* tipc_port_list_add - add a port to a port list , ensuring no duplicates
*/
2011-12-30 05:33:30 +04:00
void tipc_port_list_add ( struct tipc_port_list * pl_ptr , u32 port )
2010-05-11 18:30:15 +04:00
{
2011-12-30 05:33:30 +04:00
struct tipc_port_list * item = pl_ptr ;
2010-05-11 18:30:15 +04: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 08:16:37 +04:00
pr_warn ( " Incomplete multicast delivery, no memory \n " ) ;
2010-05-11 18:30:15 +04:00
return ;
}
item - > next - > next = NULL ;
}
}
}
/**
* tipc_port_list_free - free dynamically created entries in port_list chain
*
*/
2011-12-30 05:33:30 +04:00
void tipc_port_list_free ( struct tipc_port_list * pl_ptr )
2010-05-11 18:30:15 +04:00
{
2011-12-30 05:33:30 +04:00
struct tipc_port_list * item ;
struct tipc_port_list * next ;
2010-05-11 18:30:15 +04:00
for ( item = pl_ptr - > next ; item ; item = next ) {
next = item - > next ;
kfree ( item ) ;
}
}