2006-01-02 18:04:38 +00:00
|
|
|
/*
|
|
|
|
* net/tipc/bcast.c: TIPC broadcast code
|
2007-02-09 14:25:21 +00:00
|
|
|
*
|
2017-11-30 15:47:25 +00:00
|
|
|
* Copyright (c) 2004-2006, 2014-2017, Ericsson AB
|
2006-01-02 18:04:38 +00:00
|
|
|
* Copyright (c) 2004, Intel Corporation.
|
2011-01-07 18:00:11 +00:00
|
|
|
* Copyright (c) 2005, 2010-2011, Wind River Systems
|
2006-01-02 18:04:38 +00:00
|
|
|
* All rights reserved.
|
|
|
|
*
|
2006-01-11 12:30:43 +00:00
|
|
|
* Redistribution and use in source and binary forms, with or without
|
2006-01-02 18:04:38 +00:00
|
|
|
* modification, are permitted provided that the following conditions are met:
|
|
|
|
*
|
2006-01-11 12:30:43 +00: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 18:04:38 +00:00
|
|
|
*
|
2006-01-11 12:30:43 +00: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 18:04:38 +00:00
|
|
|
* POSSIBILITY OF SUCH DAMAGE.
|
|
|
|
*/
|
|
|
|
|
2015-10-22 12:51:33 +00:00
|
|
|
#include <linux/tipc_config.h>
|
2014-07-17 00:41:00 +00:00
|
|
|
#include "socket.h"
|
|
|
|
#include "msg.h"
|
2006-01-02 18:04:38 +00:00
|
|
|
#include "bcast.h"
|
2015-10-22 12:51:33 +00:00
|
|
|
#include "link.h"
|
2017-01-18 18:50:51 +00:00
|
|
|
#include "name_table.h"
|
2006-01-02 18:04:38 +00:00
|
|
|
|
2017-11-30 15:47:25 +00:00
|
|
|
#define BCLINK_WIN_DEFAULT 50 /* bcast link window size (default) */
|
|
|
|
#define BCLINK_WIN_MIN 32 /* bcast minimum link window size */
|
2006-01-02 18:04:38 +00:00
|
|
|
|
2010-05-11 14:30:07 +00:00
|
|
|
const char tipc_bclink_name[] = "broadcast-link";
|
2020-05-26 09:38:36 +00:00
|
|
|
unsigned long sysctl_tipc_bc_retruni __read_mostly;
|
2006-01-02 18:04:38 +00:00
|
|
|
|
2015-10-22 12:51:33 +00:00
|
|
|
/**
|
2015-10-22 12:51:48 +00:00
|
|
|
* struct tipc_bc_base - base structure for keeping broadcast send state
|
tipc: simplify bearer level broadcast
Until now, we have been keeping track of the exact set of broadcast
destinations though the help structure tipc_node_map. This leads us to
have to maintain a whole infrastructure for supporting this, including
a pseudo-bearer and a number of functions to manipulate both the bearers
and the node map correctly. Apart from the complexity, this approach is
also limiting, as struct tipc_node_map only can support cluster local
broadcast if we want to avoid it becoming excessively large. We want to
eliminate this limitation, in order to enable introduction of scoped
multicast in the future.
A closer analysis reveals that it is unnecessary maintaining this "full
set" overview; it is sufficient to keep a counter per bearer, indicating
how many nodes can be reached via this bearer at the moment. The protocol
is now robust enough to handle transitional discrepancies between the
nominal number of reachable destinations, as expected by the broadcast
protocol itself, and the number which is actually reachable at the
moment. The initial broadcast synchronization, in conjunction with the
retransmission mechanism, ensures that all packets will eventually be
acknowledged by the correct set of destinations.
This commit introduces these changes.
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Reviewed-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2015-10-22 12:51:42 +00:00
|
|
|
* @link: broadcast send link structure
|
2015-10-22 12:51:48 +00:00
|
|
|
* @inputq: data input queue; will only carry SOCK_WAKEUP messages
|
2018-09-03 08:36:45 +00:00
|
|
|
* @dests: array keeping number of reachable destinations per bearer
|
2015-10-22 12:51:48 +00:00
|
|
|
* @primary_bearer: a bearer having links to all broadcast destinations, if any
|
2017-01-18 18:50:50 +00:00
|
|
|
* @bcast_support: indicates if primary bearer, if any, supports broadcast
|
tipc: support broadcast/replicast configurable for bc-link
Currently, a multicast stream uses either broadcast or replicast as
transmission method, based on the ratio between number of actual
destinations nodes and cluster size.
However, when an L2 interface (e.g., VXLAN) provides pseudo
broadcast support, this becomes very inefficient, as it blindly
replicates multicast packets to all cluster/subnet nodes,
irrespective of whether they host actual target sockets or not.
The TIPC multicast algorithm is able to distinguish real destination
nodes from other nodes, and hence provides a smarter and more
efficient method for transferring multicast messages than
pseudo broadcast can do.
Because of this, we now make it possible for users to force
the broadcast link to permanently switch to using replicast,
irrespective of which capabilities the bearer provides,
or pretend to provide.
Conversely, we also make it possible to force the broadcast link
to always use true broadcast. While maybe less useful in
deployed systems, this may at least be useful for testing the
broadcast algorithm in small clusters.
We retain the current AUTOSELECT ability, i.e., to let the broadcast link
automatically select which algorithm to use, and to switch back and forth
between broadcast and replicast as the ratio between destination
node number and cluster size changes. This remains the default method.
Furthermore, we make it possible to configure the threshold ratio for
such switches. The default ratio is now set to 10%, down from 25% in the
earlier implementation.
Acked-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: Hoang Le <hoang.h.le@dektech.com.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-03-19 11:49:48 +00:00
|
|
|
* @force_bcast: forces broadcast for multicast traffic
|
2017-01-18 18:50:53 +00:00
|
|
|
* @rcast_support: indicates if all peer nodes support replicast
|
tipc: support broadcast/replicast configurable for bc-link
Currently, a multicast stream uses either broadcast or replicast as
transmission method, based on the ratio between number of actual
destinations nodes and cluster size.
However, when an L2 interface (e.g., VXLAN) provides pseudo
broadcast support, this becomes very inefficient, as it blindly
replicates multicast packets to all cluster/subnet nodes,
irrespective of whether they host actual target sockets or not.
The TIPC multicast algorithm is able to distinguish real destination
nodes from other nodes, and hence provides a smarter and more
efficient method for transferring multicast messages than
pseudo broadcast can do.
Because of this, we now make it possible for users to force
the broadcast link to permanently switch to using replicast,
irrespective of which capabilities the bearer provides,
or pretend to provide.
Conversely, we also make it possible to force the broadcast link
to always use true broadcast. While maybe less useful in
deployed systems, this may at least be useful for testing the
broadcast algorithm in small clusters.
We retain the current AUTOSELECT ability, i.e., to let the broadcast link
automatically select which algorithm to use, and to switch back and forth
between broadcast and replicast as the ratio between destination
node number and cluster size changes. This remains the default method.
Furthermore, we make it possible to configure the threshold ratio for
such switches. The default ratio is now set to 10%, down from 25% in the
earlier implementation.
Acked-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: Hoang Le <hoang.h.le@dektech.com.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-03-19 11:49:48 +00:00
|
|
|
* @force_rcast: forces replicast for multicast traffic
|
2017-01-18 18:50:53 +00:00
|
|
|
* @rc_ratio: dest count as percentage of cluster size where send method changes
|
2018-09-03 08:36:45 +00:00
|
|
|
* @bc_threshold: calculated from rc_ratio; if dests > threshold use broadcast
|
2015-10-22 12:51:33 +00:00
|
|
|
*/
|
|
|
|
struct tipc_bc_base {
|
2015-10-22 12:51:37 +00:00
|
|
|
struct tipc_link *link;
|
2015-10-22 12:51:33 +00:00
|
|
|
struct sk_buff_head inputq;
|
tipc: simplify bearer level broadcast
Until now, we have been keeping track of the exact set of broadcast
destinations though the help structure tipc_node_map. This leads us to
have to maintain a whole infrastructure for supporting this, including
a pseudo-bearer and a number of functions to manipulate both the bearers
and the node map correctly. Apart from the complexity, this approach is
also limiting, as struct tipc_node_map only can support cluster local
broadcast if we want to avoid it becoming excessively large. We want to
eliminate this limitation, in order to enable introduction of scoped
multicast in the future.
A closer analysis reveals that it is unnecessary maintaining this "full
set" overview; it is sufficient to keep a counter per bearer, indicating
how many nodes can be reached via this bearer at the moment. The protocol
is now robust enough to handle transitional discrepancies between the
nominal number of reachable destinations, as expected by the broadcast
protocol itself, and the number which is actually reachable at the
moment. The initial broadcast synchronization, in conjunction with the
retransmission mechanism, ensures that all packets will eventually be
acknowledged by the correct set of destinations.
This commit introduces these changes.
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Reviewed-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2015-10-22 12:51:42 +00:00
|
|
|
int dests[MAX_BEARERS];
|
|
|
|
int primary_bearer;
|
2017-01-18 18:50:50 +00:00
|
|
|
bool bcast_support;
|
tipc: support broadcast/replicast configurable for bc-link
Currently, a multicast stream uses either broadcast or replicast as
transmission method, based on the ratio between number of actual
destinations nodes and cluster size.
However, when an L2 interface (e.g., VXLAN) provides pseudo
broadcast support, this becomes very inefficient, as it blindly
replicates multicast packets to all cluster/subnet nodes,
irrespective of whether they host actual target sockets or not.
The TIPC multicast algorithm is able to distinguish real destination
nodes from other nodes, and hence provides a smarter and more
efficient method for transferring multicast messages than
pseudo broadcast can do.
Because of this, we now make it possible for users to force
the broadcast link to permanently switch to using replicast,
irrespective of which capabilities the bearer provides,
or pretend to provide.
Conversely, we also make it possible to force the broadcast link
to always use true broadcast. While maybe less useful in
deployed systems, this may at least be useful for testing the
broadcast algorithm in small clusters.
We retain the current AUTOSELECT ability, i.e., to let the broadcast link
automatically select which algorithm to use, and to switch back and forth
between broadcast and replicast as the ratio between destination
node number and cluster size changes. This remains the default method.
Furthermore, we make it possible to configure the threshold ratio for
such switches. The default ratio is now set to 10%, down from 25% in the
earlier implementation.
Acked-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: Hoang Le <hoang.h.le@dektech.com.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-03-19 11:49:48 +00:00
|
|
|
bool force_bcast;
|
2017-01-18 18:50:53 +00:00
|
|
|
bool rcast_support;
|
tipc: support broadcast/replicast configurable for bc-link
Currently, a multicast stream uses either broadcast or replicast as
transmission method, based on the ratio between number of actual
destinations nodes and cluster size.
However, when an L2 interface (e.g., VXLAN) provides pseudo
broadcast support, this becomes very inefficient, as it blindly
replicates multicast packets to all cluster/subnet nodes,
irrespective of whether they host actual target sockets or not.
The TIPC multicast algorithm is able to distinguish real destination
nodes from other nodes, and hence provides a smarter and more
efficient method for transferring multicast messages than
pseudo broadcast can do.
Because of this, we now make it possible for users to force
the broadcast link to permanently switch to using replicast,
irrespective of which capabilities the bearer provides,
or pretend to provide.
Conversely, we also make it possible to force the broadcast link
to always use true broadcast. While maybe less useful in
deployed systems, this may at least be useful for testing the
broadcast algorithm in small clusters.
We retain the current AUTOSELECT ability, i.e., to let the broadcast link
automatically select which algorithm to use, and to switch back and forth
between broadcast and replicast as the ratio between destination
node number and cluster size changes. This remains the default method.
Furthermore, we make it possible to configure the threshold ratio for
such switches. The default ratio is now set to 10%, down from 25% in the
earlier implementation.
Acked-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: Hoang Le <hoang.h.le@dektech.com.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-03-19 11:49:48 +00:00
|
|
|
bool force_rcast;
|
2017-01-18 18:50:53 +00:00
|
|
|
int rc_ratio;
|
|
|
|
int bc_threshold;
|
2015-10-22 12:51:33 +00:00
|
|
|
};
|
|
|
|
|
2015-10-22 12:51:35 +00:00
|
|
|
static struct tipc_bc_base *tipc_bc_base(struct net *net)
|
|
|
|
{
|
|
|
|
return tipc_net(net)->bcbase;
|
|
|
|
}
|
|
|
|
|
2017-11-30 15:47:25 +00:00
|
|
|
/* tipc_bcast_get_mtu(): -get the MTU currently used by broadcast link
|
|
|
|
* Note: the MTU is decremented to give room for a tunnel header, in
|
|
|
|
* case the message needs to be sent as replicast
|
|
|
|
*/
|
2015-10-22 12:51:43 +00:00
|
|
|
int tipc_bcast_get_mtu(struct net *net)
|
2014-07-17 00:41:00 +00:00
|
|
|
{
|
2019-11-08 05:05:11 +00:00
|
|
|
return tipc_link_mss(tipc_bc_sndlink(net));
|
2014-07-17 00:41:00 +00:00
|
|
|
}
|
|
|
|
|
2019-11-21 03:01:09 +00:00
|
|
|
void tipc_bcast_toggle_rcast(struct net *net, bool supp)
|
2017-01-18 18:50:53 +00:00
|
|
|
{
|
2019-11-21 03:01:09 +00:00
|
|
|
tipc_bc_base(net)->rcast_support = supp;
|
2017-01-18 18:50:53 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static void tipc_bcbase_calc_bc_threshold(struct net *net)
|
|
|
|
{
|
|
|
|
struct tipc_bc_base *bb = tipc_bc_base(net);
|
|
|
|
int cluster_size = tipc_link_bc_peers(tipc_bc_sndlink(net));
|
|
|
|
|
|
|
|
bb->bc_threshold = 1 + (cluster_size * bb->rc_ratio / 100);
|
|
|
|
}
|
|
|
|
|
tipc: simplify bearer level broadcast
Until now, we have been keeping track of the exact set of broadcast
destinations though the help structure tipc_node_map. This leads us to
have to maintain a whole infrastructure for supporting this, including
a pseudo-bearer and a number of functions to manipulate both the bearers
and the node map correctly. Apart from the complexity, this approach is
also limiting, as struct tipc_node_map only can support cluster local
broadcast if we want to avoid it becoming excessively large. We want to
eliminate this limitation, in order to enable introduction of scoped
multicast in the future.
A closer analysis reveals that it is unnecessary maintaining this "full
set" overview; it is sufficient to keep a counter per bearer, indicating
how many nodes can be reached via this bearer at the moment. The protocol
is now robust enough to handle transitional discrepancies between the
nominal number of reachable destinations, as expected by the broadcast
protocol itself, and the number which is actually reachable at the
moment. The initial broadcast synchronization, in conjunction with the
retransmission mechanism, ensures that all packets will eventually be
acknowledged by the correct set of destinations.
This commit introduces these changes.
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Reviewed-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2015-10-22 12:51:42 +00:00
|
|
|
/* tipc_bcbase_select_primary(): find a bearer with links to all destinations,
|
|
|
|
* if any, and make it primary bearer
|
|
|
|
*/
|
|
|
|
static void tipc_bcbase_select_primary(struct net *net)
|
|
|
|
{
|
|
|
|
struct tipc_bc_base *bb = tipc_bc_base(net);
|
|
|
|
int all_dests = tipc_link_bc_peers(bb->link);
|
2020-10-16 02:31:18 +00:00
|
|
|
int max_win = tipc_link_max_win(bb->link);
|
2020-10-16 02:31:19 +00:00
|
|
|
int min_win = tipc_link_min_win(bb->link);
|
2017-01-18 18:50:50 +00:00
|
|
|
int i, mtu, prim;
|
tipc: simplify bearer level broadcast
Until now, we have been keeping track of the exact set of broadcast
destinations though the help structure tipc_node_map. This leads us to
have to maintain a whole infrastructure for supporting this, including
a pseudo-bearer and a number of functions to manipulate both the bearers
and the node map correctly. Apart from the complexity, this approach is
also limiting, as struct tipc_node_map only can support cluster local
broadcast if we want to avoid it becoming excessively large. We want to
eliminate this limitation, in order to enable introduction of scoped
multicast in the future.
A closer analysis reveals that it is unnecessary maintaining this "full
set" overview; it is sufficient to keep a counter per bearer, indicating
how many nodes can be reached via this bearer at the moment. The protocol
is now robust enough to handle transitional discrepancies between the
nominal number of reachable destinations, as expected by the broadcast
protocol itself, and the number which is actually reachable at the
moment. The initial broadcast synchronization, in conjunction with the
retransmission mechanism, ensures that all packets will eventually be
acknowledged by the correct set of destinations.
This commit introduces these changes.
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Reviewed-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2015-10-22 12:51:42 +00:00
|
|
|
|
|
|
|
bb->primary_bearer = INVALID_BEARER_ID;
|
2017-01-18 18:50:50 +00:00
|
|
|
bb->bcast_support = true;
|
tipc: simplify bearer level broadcast
Until now, we have been keeping track of the exact set of broadcast
destinations though the help structure tipc_node_map. This leads us to
have to maintain a whole infrastructure for supporting this, including
a pseudo-bearer and a number of functions to manipulate both the bearers
and the node map correctly. Apart from the complexity, this approach is
also limiting, as struct tipc_node_map only can support cluster local
broadcast if we want to avoid it becoming excessively large. We want to
eliminate this limitation, in order to enable introduction of scoped
multicast in the future.
A closer analysis reveals that it is unnecessary maintaining this "full
set" overview; it is sufficient to keep a counter per bearer, indicating
how many nodes can be reached via this bearer at the moment. The protocol
is now robust enough to handle transitional discrepancies between the
nominal number of reachable destinations, as expected by the broadcast
protocol itself, and the number which is actually reachable at the
moment. The initial broadcast synchronization, in conjunction with the
retransmission mechanism, ensures that all packets will eventually be
acknowledged by the correct set of destinations.
This commit introduces these changes.
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Reviewed-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2015-10-22 12:51:42 +00:00
|
|
|
|
|
|
|
if (!all_dests)
|
|
|
|
return;
|
|
|
|
|
|
|
|
for (i = 0; i < MAX_BEARERS; i++) {
|
2015-10-22 12:51:43 +00:00
|
|
|
if (!bb->dests[i])
|
|
|
|
continue;
|
|
|
|
|
|
|
|
mtu = tipc_bearer_mtu(net, i);
|
2020-10-16 02:31:18 +00:00
|
|
|
if (mtu < tipc_link_mtu(bb->link)) {
|
2015-10-22 12:51:43 +00:00
|
|
|
tipc_link_set_mtu(bb->link, mtu);
|
2020-10-16 02:31:19 +00:00
|
|
|
tipc_link_set_queue_limits(bb->link,
|
|
|
|
min_win,
|
2020-10-16 02:31:18 +00:00
|
|
|
max_win);
|
|
|
|
}
|
2017-01-18 18:50:50 +00:00
|
|
|
bb->bcast_support &= tipc_bearer_bcast_support(net, i);
|
tipc: simplify bearer level broadcast
Until now, we have been keeping track of the exact set of broadcast
destinations though the help structure tipc_node_map. This leads us to
have to maintain a whole infrastructure for supporting this, including
a pseudo-bearer and a number of functions to manipulate both the bearers
and the node map correctly. Apart from the complexity, this approach is
also limiting, as struct tipc_node_map only can support cluster local
broadcast if we want to avoid it becoming excessively large. We want to
eliminate this limitation, in order to enable introduction of scoped
multicast in the future.
A closer analysis reveals that it is unnecessary maintaining this "full
set" overview; it is sufficient to keep a counter per bearer, indicating
how many nodes can be reached via this bearer at the moment. The protocol
is now robust enough to handle transitional discrepancies between the
nominal number of reachable destinations, as expected by the broadcast
protocol itself, and the number which is actually reachable at the
moment. The initial broadcast synchronization, in conjunction with the
retransmission mechanism, ensures that all packets will eventually be
acknowledged by the correct set of destinations.
This commit introduces these changes.
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Reviewed-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2015-10-22 12:51:42 +00:00
|
|
|
if (bb->dests[i] < all_dests)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
bb->primary_bearer = i;
|
|
|
|
|
|
|
|
/* Reduce risk that all nodes select same primary */
|
|
|
|
if ((i ^ tipc_own_addr(net)) & 1)
|
|
|
|
break;
|
|
|
|
}
|
2017-01-18 18:50:50 +00:00
|
|
|
prim = bb->primary_bearer;
|
|
|
|
if (prim != INVALID_BEARER_ID)
|
|
|
|
bb->bcast_support = tipc_bearer_bcast_support(net, prim);
|
tipc: simplify bearer level broadcast
Until now, we have been keeping track of the exact set of broadcast
destinations though the help structure tipc_node_map. This leads us to
have to maintain a whole infrastructure for supporting this, including
a pseudo-bearer and a number of functions to manipulate both the bearers
and the node map correctly. Apart from the complexity, this approach is
also limiting, as struct tipc_node_map only can support cluster local
broadcast if we want to avoid it becoming excessively large. We want to
eliminate this limitation, in order to enable introduction of scoped
multicast in the future.
A closer analysis reveals that it is unnecessary maintaining this "full
set" overview; it is sufficient to keep a counter per bearer, indicating
how many nodes can be reached via this bearer at the moment. The protocol
is now robust enough to handle transitional discrepancies between the
nominal number of reachable destinations, as expected by the broadcast
protocol itself, and the number which is actually reachable at the
moment. The initial broadcast synchronization, in conjunction with the
retransmission mechanism, ensures that all packets will eventually be
acknowledged by the correct set of destinations.
This commit introduces these changes.
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Reviewed-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2015-10-22 12:51:42 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
void tipc_bcast_inc_bearer_dst_cnt(struct net *net, int bearer_id)
|
|
|
|
{
|
|
|
|
struct tipc_bc_base *bb = tipc_bc_base(net);
|
|
|
|
|
|
|
|
tipc_bcast_lock(net);
|
|
|
|
bb->dests[bearer_id]++;
|
|
|
|
tipc_bcbase_select_primary(net);
|
|
|
|
tipc_bcast_unlock(net);
|
|
|
|
}
|
|
|
|
|
|
|
|
void tipc_bcast_dec_bearer_dst_cnt(struct net *net, int bearer_id)
|
|
|
|
{
|
|
|
|
struct tipc_bc_base *bb = tipc_bc_base(net);
|
|
|
|
|
|
|
|
tipc_bcast_lock(net);
|
|
|
|
bb->dests[bearer_id]--;
|
|
|
|
tipc_bcbase_select_primary(net);
|
|
|
|
tipc_bcast_unlock(net);
|
|
|
|
}
|
|
|
|
|
|
|
|
/* tipc_bcbase_xmit - broadcast a packet queue across one or more bearers
|
|
|
|
*
|
|
|
|
* Note that number of reachable destinations, as indicated in the dests[]
|
|
|
|
* array, may transitionally differ from the number of destinations indicated
|
|
|
|
* in each sent buffer. We can sustain this. Excess destination nodes will
|
|
|
|
* drop and never acknowledge the unexpected packets, and missing destinations
|
|
|
|
* will either require retransmission (if they are just about to be added to
|
|
|
|
* the bearer), or be removed from the buffer's 'ackers' counter (if they
|
|
|
|
* just went down)
|
|
|
|
*/
|
|
|
|
static void tipc_bcbase_xmit(struct net *net, struct sk_buff_head *xmitq)
|
|
|
|
{
|
|
|
|
int bearer_id;
|
|
|
|
struct tipc_bc_base *bb = tipc_bc_base(net);
|
|
|
|
struct sk_buff *skb, *_skb;
|
|
|
|
struct sk_buff_head _xmitq;
|
|
|
|
|
|
|
|
if (skb_queue_empty(xmitq))
|
|
|
|
return;
|
|
|
|
|
|
|
|
/* The typical case: at least one bearer has links to all nodes */
|
|
|
|
bearer_id = bb->primary_bearer;
|
|
|
|
if (bearer_id >= 0) {
|
|
|
|
tipc_bearer_bc_xmit(net, bearer_id, xmitq);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* We have to transmit across all bearers */
|
2019-08-15 14:42:50 +00:00
|
|
|
__skb_queue_head_init(&_xmitq);
|
tipc: simplify bearer level broadcast
Until now, we have been keeping track of the exact set of broadcast
destinations though the help structure tipc_node_map. This leads us to
have to maintain a whole infrastructure for supporting this, including
a pseudo-bearer and a number of functions to manipulate both the bearers
and the node map correctly. Apart from the complexity, this approach is
also limiting, as struct tipc_node_map only can support cluster local
broadcast if we want to avoid it becoming excessively large. We want to
eliminate this limitation, in order to enable introduction of scoped
multicast in the future.
A closer analysis reveals that it is unnecessary maintaining this "full
set" overview; it is sufficient to keep a counter per bearer, indicating
how many nodes can be reached via this bearer at the moment. The protocol
is now robust enough to handle transitional discrepancies between the
nominal number of reachable destinations, as expected by the broadcast
protocol itself, and the number which is actually reachable at the
moment. The initial broadcast synchronization, in conjunction with the
retransmission mechanism, ensures that all packets will eventually be
acknowledged by the correct set of destinations.
This commit introduces these changes.
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Reviewed-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2015-10-22 12:51:42 +00:00
|
|
|
for (bearer_id = 0; bearer_id < MAX_BEARERS; bearer_id++) {
|
|
|
|
if (!bb->dests[bearer_id])
|
|
|
|
continue;
|
|
|
|
|
|
|
|
skb_queue_walk(xmitq, skb) {
|
|
|
|
_skb = pskb_copy_for_clone(skb, GFP_ATOMIC);
|
|
|
|
if (!_skb)
|
|
|
|
break;
|
|
|
|
__skb_queue_tail(&_xmitq, _skb);
|
|
|
|
}
|
|
|
|
tipc_bearer_bc_xmit(net, bearer_id, &_xmitq);
|
|
|
|
}
|
|
|
|
__skb_queue_purge(xmitq);
|
|
|
|
__skb_queue_purge(&_xmitq);
|
|
|
|
}
|
|
|
|
|
2017-01-18 18:50:53 +00:00
|
|
|
static void tipc_bcast_select_xmit_method(struct net *net, int dests,
|
|
|
|
struct tipc_mc_method *method)
|
|
|
|
{
|
|
|
|
struct tipc_bc_base *bb = tipc_bc_base(net);
|
|
|
|
unsigned long exp = method->expires;
|
|
|
|
|
|
|
|
/* Broadcast supported by used bearer/bearers? */
|
|
|
|
if (!bb->bcast_support) {
|
|
|
|
method->rcast = true;
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
/* Any destinations which don't support replicast ? */
|
|
|
|
if (!bb->rcast_support) {
|
|
|
|
method->rcast = false;
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
/* Can current method be changed ? */
|
|
|
|
method->expires = jiffies + TIPC_METHOD_EXPIRE;
|
tipc: smooth change between replicast and broadcast
Currently, a multicast stream may start out using replicast, because
there are few destinations, and then it should ideally switch to
L2/broadcast IGMP/multicast when the number of destinations grows beyond
a certain limit. The opposite should happen when the number decreases
below the limit.
To eliminate the risk of message reordering caused by method change,
a sending socket must stick to a previously selected method until it
enters an idle period of 5 seconds. Means there is a 5 seconds pause
in the traffic from the sender socket.
If the sender never makes such a pause, the method will never change,
and transmission may become very inefficient as the cluster grows.
With this commit, we allow such a switch between replicast and
broadcast without any need for a traffic pause.
Solution is to send a dummy message with only the header, also with
the SYN bit set, via broadcast or replicast. For the data message,
the SYN bit is set and sending via replicast or broadcast (inverse
method with dummy).
Then, at receiving side any messages follow first SYN bit message
(data or dummy message), they will be held in deferred queue until
another pair (dummy or data message) arrived in other link.
v2: reverse christmas tree declaration
Acked-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: Hoang Le <hoang.h.le@dektech.com.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-03-19 11:49:50 +00:00
|
|
|
if (method->mandatory)
|
2017-01-18 18:50:53 +00:00
|
|
|
return;
|
|
|
|
|
tipc: smooth change between replicast and broadcast
Currently, a multicast stream may start out using replicast, because
there are few destinations, and then it should ideally switch to
L2/broadcast IGMP/multicast when the number of destinations grows beyond
a certain limit. The opposite should happen when the number decreases
below the limit.
To eliminate the risk of message reordering caused by method change,
a sending socket must stick to a previously selected method until it
enters an idle period of 5 seconds. Means there is a 5 seconds pause
in the traffic from the sender socket.
If the sender never makes such a pause, the method will never change,
and transmission may become very inefficient as the cluster grows.
With this commit, we allow such a switch between replicast and
broadcast without any need for a traffic pause.
Solution is to send a dummy message with only the header, also with
the SYN bit set, via broadcast or replicast. For the data message,
the SYN bit is set and sending via replicast or broadcast (inverse
method with dummy).
Then, at receiving side any messages follow first SYN bit message
(data or dummy message), they will be held in deferred queue until
another pair (dummy or data message) arrived in other link.
v2: reverse christmas tree declaration
Acked-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: Hoang Le <hoang.h.le@dektech.com.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-03-19 11:49:50 +00:00
|
|
|
if (!(tipc_net(net)->capabilities & TIPC_MCAST_RBCTL) &&
|
|
|
|
time_before(jiffies, exp))
|
|
|
|
return;
|
|
|
|
|
|
|
|
/* Configuration as force 'broadcast' method */
|
|
|
|
if (bb->force_bcast) {
|
|
|
|
method->rcast = false;
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
/* Configuration as force 'replicast' method */
|
|
|
|
if (bb->force_rcast) {
|
|
|
|
method->rcast = true;
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
/* Configuration as 'autoselect' or default method */
|
2017-01-18 18:50:53 +00:00
|
|
|
/* Determine method to use now */
|
|
|
|
method->rcast = dests <= bb->bc_threshold;
|
|
|
|
}
|
|
|
|
|
2017-01-18 18:50:52 +00:00
|
|
|
/* tipc_bcast_xmit - broadcast the buffer chain to all external nodes
|
2015-01-09 07:27:05 +00:00
|
|
|
* @net: the applicable net namespace
|
2017-01-18 18:50:52 +00:00
|
|
|
* @pkts: chain of buffers containing message
|
|
|
|
* @cong_link_cnt: set to 1 if broadcast link is congested, otherwise 0
|
tipc: reduce risk of user starvation during link congestion
The socket code currently handles link congestion by either blocking
and trying to send again when the congestion has abated, or just
returning to the user with -EAGAIN and let him re-try later.
This mechanism is prone to starvation, because the wakeup algorithm is
non-atomic. During the time the link issues a wakeup signal, until the
socket wakes up and re-attempts sending, other senders may have come
in between and occupied the free buffer space in the link. This in turn
may lead to a socket having to make many send attempts before it is
successful. In extremely loaded systems we have observed latency times
of several seconds before a low-priority socket is able to send out a
message.
In this commit, we simplify this mechanism and reduce the risk of the
described scenario happening. When a message is attempted sent via a
congested link, we now let it be added to the link's backlog queue
anyway, thus permitting an oversubscription of one message per source
socket. We still create a wakeup item and return an error code, hence
instructing the sender to block or stop sending. Only when enough space
has been freed up in the link's backlog queue do we issue a wakeup event
that allows the sender to continue with the next message, if any.
The fact that a socket now can consider a message sent even when the
link returns a congestion code means that the sending socket code can
be simplified. Also, since this is a good opportunity to get rid of the
obsolete 'mtu change' condition in the three socket send functions, we
now choose to refactor those functions completely.
Signed-off-by: Parthasarathy Bhuvaragan <parthasarathy.bhuvaragan@ericsson.com>
Acked-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-01-03 15:55:11 +00:00
|
|
|
* Consumes the buffer chain.
|
2017-01-18 18:50:52 +00:00
|
|
|
* Returns 0 if success, otherwise errno: -EHOSTUNREACH,-EMSGSIZE
|
2014-07-17 00:41:00 +00:00
|
|
|
*/
|
tipc: update a binding service via broadcast
Currently, updating binding table (add service binding to
name table/withdraw a service binding) is being sent over replicast.
However, if we are scaling up clusters to > 100 nodes/containers this
method is less affection because of looping through nodes in a cluster one
by one.
It is worth to use broadcast to update a binding service. This way, the
binding table can be updated on all peer nodes in one shot.
Broadcast is used when all peer nodes, as indicated by a new capability
flag TIPC_NAMED_BCAST, support reception of this message type.
Four problems need to be considered when introducing this feature.
1) When establishing a link to a new peer node we still update this by a
unicast 'bulk' update. This may lead to race conditions, where a later
broadcast publication/withdrawal bypass the 'bulk', resulting in
disordered publications, or even that a withdrawal may arrive before the
corresponding publication. We solve this by adding an 'is_last_bulk' bit
in the last bulk messages so that it can be distinguished from all other
messages. Only when this message has arrived do we open up for reception
of broadcast publications/withdrawals.
2) When a first legacy node is added to the cluster all distribution
will switch over to use the legacy 'replicast' method, while the
opposite happens when the last legacy node leaves the cluster. This
entails another risk of message disordering that has to be handled. We
solve this by adding a sequence number to the broadcast/replicast
messages, so that disordering can be discovered and corrected. Note
however that we don't need to consider potential message loss or
duplication at this protocol level.
3) Bulk messages don't contain any sequence numbers, and will always
arrive in order. Hence we must exempt those from the sequence number
control and deliver them unconditionally. We solve this by adding a new
'is_bulk' bit in those messages so that they can be recognized.
4) Legacy messages, which don't contain any new bits or sequence
numbers, but neither can arrive out of order, also need to be exempt
from the initial synchronization and sequence number check, and
delivered unconditionally. Therefore, we add another 'is_not_legacy' bit
to all new messages so that those can be distinguished from legacy
messages and the latter delivered directly.
v1->v2:
- fix warning issue reported by kbuild test robot <lkp@intel.com>
- add santiy check to drop the publication message with a sequence
number that is lower than the agreed synch point
Signed-off-by: kernel test robot <lkp@intel.com>
Signed-off-by: Hoang Huu Le <hoang.h.le@dektech.com.au>
Acked-by: Jon Maloy <jmaloy@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2020-06-17 06:56:05 +00:00
|
|
|
int tipc_bcast_xmit(struct net *net, struct sk_buff_head *pkts,
|
|
|
|
u16 *cong_link_cnt)
|
2014-07-17 00:41:00 +00:00
|
|
|
{
|
2015-10-22 12:51:39 +00:00
|
|
|
struct tipc_link *l = tipc_bc_sndlink(net);
|
2017-01-18 18:50:52 +00:00
|
|
|
struct sk_buff_head xmitq;
|
2014-07-17 00:41:00 +00:00
|
|
|
int rc = 0;
|
|
|
|
|
2019-08-15 14:42:50 +00:00
|
|
|
__skb_queue_head_init(&xmitq);
|
2015-10-22 12:51:39 +00:00
|
|
|
tipc_bcast_lock(net);
|
|
|
|
if (tipc_link_bc_peers(l))
|
2017-01-18 18:50:52 +00:00
|
|
|
rc = tipc_link_xmit(l, pkts, &xmitq);
|
2015-10-22 12:51:39 +00:00
|
|
|
tipc_bcast_unlock(net);
|
2017-01-18 18:50:52 +00:00
|
|
|
tipc_bcbase_xmit(net, &xmitq);
|
|
|
|
__skb_queue_purge(pkts);
|
|
|
|
if (rc == -ELINKCONG) {
|
|
|
|
*cong_link_cnt = 1;
|
|
|
|
rc = 0;
|
|
|
|
}
|
|
|
|
return rc;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* tipc_rcast_xmit - replicate and send a message to given destination nodes
|
|
|
|
* @net: the applicable net namespace
|
|
|
|
* @pkts: chain of buffers containing message
|
|
|
|
* @dests: list of destination nodes
|
|
|
|
* @cong_link_cnt: returns number of congested links
|
|
|
|
* @cong_links: returns identities of congested links
|
|
|
|
* Returns 0 if success, otherwise errno
|
|
|
|
*/
|
|
|
|
static int tipc_rcast_xmit(struct net *net, struct sk_buff_head *pkts,
|
|
|
|
struct tipc_nlist *dests, u16 *cong_link_cnt)
|
|
|
|
{
|
2017-10-13 09:04:22 +00:00
|
|
|
struct tipc_dest *dst, *tmp;
|
2017-01-18 18:50:52 +00:00
|
|
|
struct sk_buff_head _pkts;
|
2017-10-13 09:04:22 +00:00
|
|
|
u32 dnode, selector;
|
2017-01-18 18:50:52 +00:00
|
|
|
|
|
|
|
selector = msg_link_selector(buf_msg(skb_peek(pkts)));
|
2019-08-15 14:42:50 +00:00
|
|
|
__skb_queue_head_init(&_pkts);
|
2017-01-18 18:50:52 +00:00
|
|
|
|
2017-10-13 09:04:22 +00:00
|
|
|
list_for_each_entry_safe(dst, tmp, &dests->list, list) {
|
|
|
|
dnode = dst->node;
|
|
|
|
if (!tipc_msg_pskb_copy(dnode, pkts, &_pkts))
|
2017-01-18 18:50:52 +00:00
|
|
|
return -ENOMEM;
|
2014-07-17 00:41:00 +00:00
|
|
|
|
2017-01-18 18:50:52 +00:00
|
|
|
/* Any other return value than -ELINKCONG is ignored */
|
2017-10-13 09:04:22 +00:00
|
|
|
if (tipc_node_xmit(net, &_pkts, dnode, selector) == -ELINKCONG)
|
2017-01-18 18:50:52 +00:00
|
|
|
(*cong_link_cnt)++;
|
2015-02-05 13:36:44 +00:00
|
|
|
}
|
2017-01-18 18:50:52 +00:00
|
|
|
return 0;
|
|
|
|
}
|
2015-10-22 12:51:41 +00:00
|
|
|
|
tipc: smooth change between replicast and broadcast
Currently, a multicast stream may start out using replicast, because
there are few destinations, and then it should ideally switch to
L2/broadcast IGMP/multicast when the number of destinations grows beyond
a certain limit. The opposite should happen when the number decreases
below the limit.
To eliminate the risk of message reordering caused by method change,
a sending socket must stick to a previously selected method until it
enters an idle period of 5 seconds. Means there is a 5 seconds pause
in the traffic from the sender socket.
If the sender never makes such a pause, the method will never change,
and transmission may become very inefficient as the cluster grows.
With this commit, we allow such a switch between replicast and
broadcast without any need for a traffic pause.
Solution is to send a dummy message with only the header, also with
the SYN bit set, via broadcast or replicast. For the data message,
the SYN bit is set and sending via replicast or broadcast (inverse
method with dummy).
Then, at receiving side any messages follow first SYN bit message
(data or dummy message), they will be held in deferred queue until
another pair (dummy or data message) arrived in other link.
v2: reverse christmas tree declaration
Acked-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: Hoang Le <hoang.h.le@dektech.com.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-03-19 11:49:50 +00:00
|
|
|
/* tipc_mcast_send_sync - deliver a dummy message with SYN bit
|
|
|
|
* @net: the applicable net namespace
|
|
|
|
* @skb: socket buffer to copy
|
|
|
|
* @method: send method to be used
|
|
|
|
* @dests: destination nodes for message.
|
|
|
|
* Returns 0 if success, otherwise errno
|
|
|
|
*/
|
|
|
|
static int tipc_mcast_send_sync(struct net *net, struct sk_buff *skb,
|
|
|
|
struct tipc_mc_method *method,
|
tipc: fix potential hanging after b/rcast changing
In commit c55c8edafa91 ("tipc: smooth change between replicast and
broadcast"), we allow instant switching between replicast and broadcast
by sending a dummy 'SYN' packet on the last used link to synchronize
packets on the links. The 'SYN' message is an object of link congestion
also, so if that happens, a 'SOCK_WAKEUP' will be scheduled to be sent
back to the socket...
However, in that commit, we simply use the same socket 'cong_link_cnt'
counter for both the 'SYN' & normal payload message sending. Therefore,
if both the replicast & broadcast links are congested, the counter will
be not updated correctly but overwritten by the latter congestion.
Later on, when the 'SOCK_WAKEUP' messages are processed, the counter is
reduced one by one and eventually overflowed. Consequently, further
activities on the socket will only wait for the false congestion signal
to disappear but never been met.
Because sending the 'SYN' message is vital for the mechanism, it should
be done anyway. This commit fixes the issue by marking the message with
an error code e.g. 'TIPC_ERR_NO_PORT', so its sending should not face a
link congestion, there is no need to touch the socket 'cong_link_cnt'
either. In addition, in the event of any error (e.g. -ENOBUFS), we will
purge the entire payload message queue and make a return immediately.
Fixes: c55c8edafa91 ("tipc: smooth change between replicast and broadcast")
Acked-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: Tuong Lien <tuong.t.lien@dektech.com.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-12-10 08:21:03 +00:00
|
|
|
struct tipc_nlist *dests)
|
tipc: smooth change between replicast and broadcast
Currently, a multicast stream may start out using replicast, because
there are few destinations, and then it should ideally switch to
L2/broadcast IGMP/multicast when the number of destinations grows beyond
a certain limit. The opposite should happen when the number decreases
below the limit.
To eliminate the risk of message reordering caused by method change,
a sending socket must stick to a previously selected method until it
enters an idle period of 5 seconds. Means there is a 5 seconds pause
in the traffic from the sender socket.
If the sender never makes such a pause, the method will never change,
and transmission may become very inefficient as the cluster grows.
With this commit, we allow such a switch between replicast and
broadcast without any need for a traffic pause.
Solution is to send a dummy message with only the header, also with
the SYN bit set, via broadcast or replicast. For the data message,
the SYN bit is set and sending via replicast or broadcast (inverse
method with dummy).
Then, at receiving side any messages follow first SYN bit message
(data or dummy message), they will be held in deferred queue until
another pair (dummy or data message) arrived in other link.
v2: reverse christmas tree declaration
Acked-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: Hoang Le <hoang.h.le@dektech.com.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-03-19 11:49:50 +00:00
|
|
|
{
|
|
|
|
struct tipc_msg *hdr, *_hdr;
|
|
|
|
struct sk_buff_head tmpq;
|
2024-09-12 11:01:20 +00:00
|
|
|
u16 cong_link_cnt = 0;
|
tipc: smooth change between replicast and broadcast
Currently, a multicast stream may start out using replicast, because
there are few destinations, and then it should ideally switch to
L2/broadcast IGMP/multicast when the number of destinations grows beyond
a certain limit. The opposite should happen when the number decreases
below the limit.
To eliminate the risk of message reordering caused by method change,
a sending socket must stick to a previously selected method until it
enters an idle period of 5 seconds. Means there is a 5 seconds pause
in the traffic from the sender socket.
If the sender never makes such a pause, the method will never change,
and transmission may become very inefficient as the cluster grows.
With this commit, we allow such a switch between replicast and
broadcast without any need for a traffic pause.
Solution is to send a dummy message with only the header, also with
the SYN bit set, via broadcast or replicast. For the data message,
the SYN bit is set and sending via replicast or broadcast (inverse
method with dummy).
Then, at receiving side any messages follow first SYN bit message
(data or dummy message), they will be held in deferred queue until
another pair (dummy or data message) arrived in other link.
v2: reverse christmas tree declaration
Acked-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: Hoang Le <hoang.h.le@dektech.com.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-03-19 11:49:50 +00:00
|
|
|
struct sk_buff *_skb;
|
tipc: fix potential hanging after b/rcast changing
In commit c55c8edafa91 ("tipc: smooth change between replicast and
broadcast"), we allow instant switching between replicast and broadcast
by sending a dummy 'SYN' packet on the last used link to synchronize
packets on the links. The 'SYN' message is an object of link congestion
also, so if that happens, a 'SOCK_WAKEUP' will be scheduled to be sent
back to the socket...
However, in that commit, we simply use the same socket 'cong_link_cnt'
counter for both the 'SYN' & normal payload message sending. Therefore,
if both the replicast & broadcast links are congested, the counter will
be not updated correctly but overwritten by the latter congestion.
Later on, when the 'SOCK_WAKEUP' messages are processed, the counter is
reduced one by one and eventually overflowed. Consequently, further
activities on the socket will only wait for the false congestion signal
to disappear but never been met.
Because sending the 'SYN' message is vital for the mechanism, it should
be done anyway. This commit fixes the issue by marking the message with
an error code e.g. 'TIPC_ERR_NO_PORT', so its sending should not face a
link congestion, there is no need to touch the socket 'cong_link_cnt'
either. In addition, in the event of any error (e.g. -ENOBUFS), we will
purge the entire payload message queue and make a return immediately.
Fixes: c55c8edafa91 ("tipc: smooth change between replicast and broadcast")
Acked-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: Tuong Lien <tuong.t.lien@dektech.com.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-12-10 08:21:03 +00:00
|
|
|
int rc = 0;
|
tipc: smooth change between replicast and broadcast
Currently, a multicast stream may start out using replicast, because
there are few destinations, and then it should ideally switch to
L2/broadcast IGMP/multicast when the number of destinations grows beyond
a certain limit. The opposite should happen when the number decreases
below the limit.
To eliminate the risk of message reordering caused by method change,
a sending socket must stick to a previously selected method until it
enters an idle period of 5 seconds. Means there is a 5 seconds pause
in the traffic from the sender socket.
If the sender never makes such a pause, the method will never change,
and transmission may become very inefficient as the cluster grows.
With this commit, we allow such a switch between replicast and
broadcast without any need for a traffic pause.
Solution is to send a dummy message with only the header, also with
the SYN bit set, via broadcast or replicast. For the data message,
the SYN bit is set and sending via replicast or broadcast (inverse
method with dummy).
Then, at receiving side any messages follow first SYN bit message
(data or dummy message), they will be held in deferred queue until
another pair (dummy or data message) arrived in other link.
v2: reverse christmas tree declaration
Acked-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: Hoang Le <hoang.h.le@dektech.com.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-03-19 11:49:50 +00:00
|
|
|
|
|
|
|
/* Is a cluster supporting with new capabilities ? */
|
|
|
|
if (!(tipc_net(net)->capabilities & TIPC_MCAST_RBCTL))
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
hdr = buf_msg(skb);
|
|
|
|
if (msg_user(hdr) == MSG_FRAGMENTER)
|
2019-06-25 17:37:00 +00:00
|
|
|
hdr = msg_inner_hdr(hdr);
|
tipc: smooth change between replicast and broadcast
Currently, a multicast stream may start out using replicast, because
there are few destinations, and then it should ideally switch to
L2/broadcast IGMP/multicast when the number of destinations grows beyond
a certain limit. The opposite should happen when the number decreases
below the limit.
To eliminate the risk of message reordering caused by method change,
a sending socket must stick to a previously selected method until it
enters an idle period of 5 seconds. Means there is a 5 seconds pause
in the traffic from the sender socket.
If the sender never makes such a pause, the method will never change,
and transmission may become very inefficient as the cluster grows.
With this commit, we allow such a switch between replicast and
broadcast without any need for a traffic pause.
Solution is to send a dummy message with only the header, also with
the SYN bit set, via broadcast or replicast. For the data message,
the SYN bit is set and sending via replicast or broadcast (inverse
method with dummy).
Then, at receiving side any messages follow first SYN bit message
(data or dummy message), they will be held in deferred queue until
another pair (dummy or data message) arrived in other link.
v2: reverse christmas tree declaration
Acked-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: Hoang Le <hoang.h.le@dektech.com.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-03-19 11:49:50 +00:00
|
|
|
if (msg_type(hdr) != TIPC_MCAST_MSG)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
/* Allocate dummy message */
|
|
|
|
_skb = tipc_buf_acquire(MCAST_H_SIZE, GFP_KERNEL);
|
2019-03-25 06:31:09 +00:00
|
|
|
if (!_skb)
|
tipc: smooth change between replicast and broadcast
Currently, a multicast stream may start out using replicast, because
there are few destinations, and then it should ideally switch to
L2/broadcast IGMP/multicast when the number of destinations grows beyond
a certain limit. The opposite should happen when the number decreases
below the limit.
To eliminate the risk of message reordering caused by method change,
a sending socket must stick to a previously selected method until it
enters an idle period of 5 seconds. Means there is a 5 seconds pause
in the traffic from the sender socket.
If the sender never makes such a pause, the method will never change,
and transmission may become very inefficient as the cluster grows.
With this commit, we allow such a switch between replicast and
broadcast without any need for a traffic pause.
Solution is to send a dummy message with only the header, also with
the SYN bit set, via broadcast or replicast. For the data message,
the SYN bit is set and sending via replicast or broadcast (inverse
method with dummy).
Then, at receiving side any messages follow first SYN bit message
(data or dummy message), they will be held in deferred queue until
another pair (dummy or data message) arrived in other link.
v2: reverse christmas tree declaration
Acked-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: Hoang Le <hoang.h.le@dektech.com.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-03-19 11:49:50 +00:00
|
|
|
return -ENOMEM;
|
|
|
|
|
|
|
|
/* Preparing for 'synching' header */
|
|
|
|
msg_set_syn(hdr, 1);
|
|
|
|
|
|
|
|
/* Copy skb's header into a dummy header */
|
|
|
|
skb_copy_to_linear_data(_skb, hdr, MCAST_H_SIZE);
|
|
|
|
skb_orphan(_skb);
|
|
|
|
|
|
|
|
/* Reverse method for dummy message */
|
|
|
|
_hdr = buf_msg(_skb);
|
|
|
|
msg_set_size(_hdr, MCAST_H_SIZE);
|
|
|
|
msg_set_is_rcast(_hdr, !msg_is_rcast(hdr));
|
tipc: fix potential hanging after b/rcast changing
In commit c55c8edafa91 ("tipc: smooth change between replicast and
broadcast"), we allow instant switching between replicast and broadcast
by sending a dummy 'SYN' packet on the last used link to synchronize
packets on the links. The 'SYN' message is an object of link congestion
also, so if that happens, a 'SOCK_WAKEUP' will be scheduled to be sent
back to the socket...
However, in that commit, we simply use the same socket 'cong_link_cnt'
counter for both the 'SYN' & normal payload message sending. Therefore,
if both the replicast & broadcast links are congested, the counter will
be not updated correctly but overwritten by the latter congestion.
Later on, when the 'SOCK_WAKEUP' messages are processed, the counter is
reduced one by one and eventually overflowed. Consequently, further
activities on the socket will only wait for the false congestion signal
to disappear but never been met.
Because sending the 'SYN' message is vital for the mechanism, it should
be done anyway. This commit fixes the issue by marking the message with
an error code e.g. 'TIPC_ERR_NO_PORT', so its sending should not face a
link congestion, there is no need to touch the socket 'cong_link_cnt'
either. In addition, in the event of any error (e.g. -ENOBUFS), we will
purge the entire payload message queue and make a return immediately.
Fixes: c55c8edafa91 ("tipc: smooth change between replicast and broadcast")
Acked-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: Tuong Lien <tuong.t.lien@dektech.com.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-12-10 08:21:03 +00:00
|
|
|
msg_set_errcode(_hdr, TIPC_ERR_NO_PORT);
|
tipc: smooth change between replicast and broadcast
Currently, a multicast stream may start out using replicast, because
there are few destinations, and then it should ideally switch to
L2/broadcast IGMP/multicast when the number of destinations grows beyond
a certain limit. The opposite should happen when the number decreases
below the limit.
To eliminate the risk of message reordering caused by method change,
a sending socket must stick to a previously selected method until it
enters an idle period of 5 seconds. Means there is a 5 seconds pause
in the traffic from the sender socket.
If the sender never makes such a pause, the method will never change,
and transmission may become very inefficient as the cluster grows.
With this commit, we allow such a switch between replicast and
broadcast without any need for a traffic pause.
Solution is to send a dummy message with only the header, also with
the SYN bit set, via broadcast or replicast. For the data message,
the SYN bit is set and sending via replicast or broadcast (inverse
method with dummy).
Then, at receiving side any messages follow first SYN bit message
(data or dummy message), they will be held in deferred queue until
another pair (dummy or data message) arrived in other link.
v2: reverse christmas tree declaration
Acked-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: Hoang Le <hoang.h.le@dektech.com.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-03-19 11:49:50 +00:00
|
|
|
|
2019-08-15 14:42:50 +00:00
|
|
|
__skb_queue_head_init(&tmpq);
|
tipc: smooth change between replicast and broadcast
Currently, a multicast stream may start out using replicast, because
there are few destinations, and then it should ideally switch to
L2/broadcast IGMP/multicast when the number of destinations grows beyond
a certain limit. The opposite should happen when the number decreases
below the limit.
To eliminate the risk of message reordering caused by method change,
a sending socket must stick to a previously selected method until it
enters an idle period of 5 seconds. Means there is a 5 seconds pause
in the traffic from the sender socket.
If the sender never makes such a pause, the method will never change,
and transmission may become very inefficient as the cluster grows.
With this commit, we allow such a switch between replicast and
broadcast without any need for a traffic pause.
Solution is to send a dummy message with only the header, also with
the SYN bit set, via broadcast or replicast. For the data message,
the SYN bit is set and sending via replicast or broadcast (inverse
method with dummy).
Then, at receiving side any messages follow first SYN bit message
(data or dummy message), they will be held in deferred queue until
another pair (dummy or data message) arrived in other link.
v2: reverse christmas tree declaration
Acked-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: Hoang Le <hoang.h.le@dektech.com.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-03-19 11:49:50 +00:00
|
|
|
__skb_queue_tail(&tmpq, _skb);
|
|
|
|
if (method->rcast)
|
tipc: fix potential hanging after b/rcast changing
In commit c55c8edafa91 ("tipc: smooth change between replicast and
broadcast"), we allow instant switching between replicast and broadcast
by sending a dummy 'SYN' packet on the last used link to synchronize
packets on the links. The 'SYN' message is an object of link congestion
also, so if that happens, a 'SOCK_WAKEUP' will be scheduled to be sent
back to the socket...
However, in that commit, we simply use the same socket 'cong_link_cnt'
counter for both the 'SYN' & normal payload message sending. Therefore,
if both the replicast & broadcast links are congested, the counter will
be not updated correctly but overwritten by the latter congestion.
Later on, when the 'SOCK_WAKEUP' messages are processed, the counter is
reduced one by one and eventually overflowed. Consequently, further
activities on the socket will only wait for the false congestion signal
to disappear but never been met.
Because sending the 'SYN' message is vital for the mechanism, it should
be done anyway. This commit fixes the issue by marking the message with
an error code e.g. 'TIPC_ERR_NO_PORT', so its sending should not face a
link congestion, there is no need to touch the socket 'cong_link_cnt'
either. In addition, in the event of any error (e.g. -ENOBUFS), we will
purge the entire payload message queue and make a return immediately.
Fixes: c55c8edafa91 ("tipc: smooth change between replicast and broadcast")
Acked-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: Tuong Lien <tuong.t.lien@dektech.com.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-12-10 08:21:03 +00:00
|
|
|
rc = tipc_bcast_xmit(net, &tmpq, &cong_link_cnt);
|
tipc: smooth change between replicast and broadcast
Currently, a multicast stream may start out using replicast, because
there are few destinations, and then it should ideally switch to
L2/broadcast IGMP/multicast when the number of destinations grows beyond
a certain limit. The opposite should happen when the number decreases
below the limit.
To eliminate the risk of message reordering caused by method change,
a sending socket must stick to a previously selected method until it
enters an idle period of 5 seconds. Means there is a 5 seconds pause
in the traffic from the sender socket.
If the sender never makes such a pause, the method will never change,
and transmission may become very inefficient as the cluster grows.
With this commit, we allow such a switch between replicast and
broadcast without any need for a traffic pause.
Solution is to send a dummy message with only the header, also with
the SYN bit set, via broadcast or replicast. For the data message,
the SYN bit is set and sending via replicast or broadcast (inverse
method with dummy).
Then, at receiving side any messages follow first SYN bit message
(data or dummy message), they will be held in deferred queue until
another pair (dummy or data message) arrived in other link.
v2: reverse christmas tree declaration
Acked-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: Hoang Le <hoang.h.le@dektech.com.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-03-19 11:49:50 +00:00
|
|
|
else
|
tipc: fix potential hanging after b/rcast changing
In commit c55c8edafa91 ("tipc: smooth change between replicast and
broadcast"), we allow instant switching between replicast and broadcast
by sending a dummy 'SYN' packet on the last used link to synchronize
packets on the links. The 'SYN' message is an object of link congestion
also, so if that happens, a 'SOCK_WAKEUP' will be scheduled to be sent
back to the socket...
However, in that commit, we simply use the same socket 'cong_link_cnt'
counter for both the 'SYN' & normal payload message sending. Therefore,
if both the replicast & broadcast links are congested, the counter will
be not updated correctly but overwritten by the latter congestion.
Later on, when the 'SOCK_WAKEUP' messages are processed, the counter is
reduced one by one and eventually overflowed. Consequently, further
activities on the socket will only wait for the false congestion signal
to disappear but never been met.
Because sending the 'SYN' message is vital for the mechanism, it should
be done anyway. This commit fixes the issue by marking the message with
an error code e.g. 'TIPC_ERR_NO_PORT', so its sending should not face a
link congestion, there is no need to touch the socket 'cong_link_cnt'
either. In addition, in the event of any error (e.g. -ENOBUFS), we will
purge the entire payload message queue and make a return immediately.
Fixes: c55c8edafa91 ("tipc: smooth change between replicast and broadcast")
Acked-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: Tuong Lien <tuong.t.lien@dektech.com.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-12-10 08:21:03 +00:00
|
|
|
rc = tipc_rcast_xmit(net, &tmpq, dests, &cong_link_cnt);
|
tipc: smooth change between replicast and broadcast
Currently, a multicast stream may start out using replicast, because
there are few destinations, and then it should ideally switch to
L2/broadcast IGMP/multicast when the number of destinations grows beyond
a certain limit. The opposite should happen when the number decreases
below the limit.
To eliminate the risk of message reordering caused by method change,
a sending socket must stick to a previously selected method until it
enters an idle period of 5 seconds. Means there is a 5 seconds pause
in the traffic from the sender socket.
If the sender never makes such a pause, the method will never change,
and transmission may become very inefficient as the cluster grows.
With this commit, we allow such a switch between replicast and
broadcast without any need for a traffic pause.
Solution is to send a dummy message with only the header, also with
the SYN bit set, via broadcast or replicast. For the data message,
the SYN bit is set and sending via replicast or broadcast (inverse
method with dummy).
Then, at receiving side any messages follow first SYN bit message
(data or dummy message), they will be held in deferred queue until
another pair (dummy or data message) arrived in other link.
v2: reverse christmas tree declaration
Acked-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: Hoang Le <hoang.h.le@dektech.com.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-03-19 11:49:50 +00:00
|
|
|
|
|
|
|
/* This queue should normally be empty by now */
|
|
|
|
__skb_queue_purge(&tmpq);
|
|
|
|
|
tipc: fix potential hanging after b/rcast changing
In commit c55c8edafa91 ("tipc: smooth change between replicast and
broadcast"), we allow instant switching between replicast and broadcast
by sending a dummy 'SYN' packet on the last used link to synchronize
packets on the links. The 'SYN' message is an object of link congestion
also, so if that happens, a 'SOCK_WAKEUP' will be scheduled to be sent
back to the socket...
However, in that commit, we simply use the same socket 'cong_link_cnt'
counter for both the 'SYN' & normal payload message sending. Therefore,
if both the replicast & broadcast links are congested, the counter will
be not updated correctly but overwritten by the latter congestion.
Later on, when the 'SOCK_WAKEUP' messages are processed, the counter is
reduced one by one and eventually overflowed. Consequently, further
activities on the socket will only wait for the false congestion signal
to disappear but never been met.
Because sending the 'SYN' message is vital for the mechanism, it should
be done anyway. This commit fixes the issue by marking the message with
an error code e.g. 'TIPC_ERR_NO_PORT', so its sending should not face a
link congestion, there is no need to touch the socket 'cong_link_cnt'
either. In addition, in the event of any error (e.g. -ENOBUFS), we will
purge the entire payload message queue and make a return immediately.
Fixes: c55c8edafa91 ("tipc: smooth change between replicast and broadcast")
Acked-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: Tuong Lien <tuong.t.lien@dektech.com.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-12-10 08:21:03 +00:00
|
|
|
return rc;
|
tipc: smooth change between replicast and broadcast
Currently, a multicast stream may start out using replicast, because
there are few destinations, and then it should ideally switch to
L2/broadcast IGMP/multicast when the number of destinations grows beyond
a certain limit. The opposite should happen when the number decreases
below the limit.
To eliminate the risk of message reordering caused by method change,
a sending socket must stick to a previously selected method until it
enters an idle period of 5 seconds. Means there is a 5 seconds pause
in the traffic from the sender socket.
If the sender never makes such a pause, the method will never change,
and transmission may become very inefficient as the cluster grows.
With this commit, we allow such a switch between replicast and
broadcast without any need for a traffic pause.
Solution is to send a dummy message with only the header, also with
the SYN bit set, via broadcast or replicast. For the data message,
the SYN bit is set and sending via replicast or broadcast (inverse
method with dummy).
Then, at receiving side any messages follow first SYN bit message
(data or dummy message), they will be held in deferred queue until
another pair (dummy or data message) arrived in other link.
v2: reverse christmas tree declaration
Acked-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: Hoang Le <hoang.h.le@dektech.com.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-03-19 11:49:50 +00:00
|
|
|
}
|
|
|
|
|
2017-01-18 18:50:52 +00:00
|
|
|
/* tipc_mcast_xmit - deliver message to indicated destination nodes
|
|
|
|
* and to identified node local sockets
|
|
|
|
* @net: the applicable net namespace
|
|
|
|
* @pkts: chain of buffers containing message
|
2017-01-18 18:50:53 +00:00
|
|
|
* @method: send method to be used
|
|
|
|
* @dests: destination nodes for message.
|
2017-01-18 18:50:52 +00:00
|
|
|
* @cong_link_cnt: returns number of encountered congested destination links
|
|
|
|
* Consumes buffer chain.
|
|
|
|
* Returns 0 if success, otherwise errno
|
|
|
|
*/
|
|
|
|
int tipc_mcast_xmit(struct net *net, struct sk_buff_head *pkts,
|
2017-01-18 18:50:53 +00:00
|
|
|
struct tipc_mc_method *method, struct tipc_nlist *dests,
|
|
|
|
u16 *cong_link_cnt)
|
2017-01-18 18:50:52 +00:00
|
|
|
{
|
|
|
|
struct sk_buff_head inputq, localq;
|
tipc: smooth change between replicast and broadcast
Currently, a multicast stream may start out using replicast, because
there are few destinations, and then it should ideally switch to
L2/broadcast IGMP/multicast when the number of destinations grows beyond
a certain limit. The opposite should happen when the number decreases
below the limit.
To eliminate the risk of message reordering caused by method change,
a sending socket must stick to a previously selected method until it
enters an idle period of 5 seconds. Means there is a 5 seconds pause
in the traffic from the sender socket.
If the sender never makes such a pause, the method will never change,
and transmission may become very inefficient as the cluster grows.
With this commit, we allow such a switch between replicast and
broadcast without any need for a traffic pause.
Solution is to send a dummy message with only the header, also with
the SYN bit set, via broadcast or replicast. For the data message,
the SYN bit is set and sending via replicast or broadcast (inverse
method with dummy).
Then, at receiving side any messages follow first SYN bit message
(data or dummy message), they will be held in deferred queue until
another pair (dummy or data message) arrived in other link.
v2: reverse christmas tree declaration
Acked-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: Hoang Le <hoang.h.le@dektech.com.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-03-19 11:49:50 +00:00
|
|
|
bool rcast = method->rcast;
|
|
|
|
struct tipc_msg *hdr;
|
|
|
|
struct sk_buff *skb;
|
2017-01-18 18:50:52 +00:00
|
|
|
int rc = 0;
|
|
|
|
|
|
|
|
skb_queue_head_init(&inputq);
|
2019-08-15 14:42:50 +00:00
|
|
|
__skb_queue_head_init(&localq);
|
2017-01-18 18:50:52 +00:00
|
|
|
|
|
|
|
/* Clone packets before they are consumed by next call */
|
|
|
|
if (dests->local && !tipc_msg_reassemble(pkts, &localq)) {
|
|
|
|
rc = -ENOMEM;
|
|
|
|
goto exit;
|
|
|
|
}
|
2017-01-18 18:50:53 +00:00
|
|
|
/* Send according to determined transmit method */
|
2017-01-18 18:50:52 +00:00
|
|
|
if (dests->remote) {
|
2017-01-18 18:50:53 +00:00
|
|
|
tipc_bcast_select_xmit_method(net, dests->remote, method);
|
tipc: smooth change between replicast and broadcast
Currently, a multicast stream may start out using replicast, because
there are few destinations, and then it should ideally switch to
L2/broadcast IGMP/multicast when the number of destinations grows beyond
a certain limit. The opposite should happen when the number decreases
below the limit.
To eliminate the risk of message reordering caused by method change,
a sending socket must stick to a previously selected method until it
enters an idle period of 5 seconds. Means there is a 5 seconds pause
in the traffic from the sender socket.
If the sender never makes such a pause, the method will never change,
and transmission may become very inefficient as the cluster grows.
With this commit, we allow such a switch between replicast and
broadcast without any need for a traffic pause.
Solution is to send a dummy message with only the header, also with
the SYN bit set, via broadcast or replicast. For the data message,
the SYN bit is set and sending via replicast or broadcast (inverse
method with dummy).
Then, at receiving side any messages follow first SYN bit message
(data or dummy message), they will be held in deferred queue until
another pair (dummy or data message) arrived in other link.
v2: reverse christmas tree declaration
Acked-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: Hoang Le <hoang.h.le@dektech.com.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-03-19 11:49:50 +00:00
|
|
|
|
|
|
|
skb = skb_peek(pkts);
|
|
|
|
hdr = buf_msg(skb);
|
|
|
|
if (msg_user(hdr) == MSG_FRAGMENTER)
|
2019-06-25 17:37:00 +00:00
|
|
|
hdr = msg_inner_hdr(hdr);
|
tipc: smooth change between replicast and broadcast
Currently, a multicast stream may start out using replicast, because
there are few destinations, and then it should ideally switch to
L2/broadcast IGMP/multicast when the number of destinations grows beyond
a certain limit. The opposite should happen when the number decreases
below the limit.
To eliminate the risk of message reordering caused by method change,
a sending socket must stick to a previously selected method until it
enters an idle period of 5 seconds. Means there is a 5 seconds pause
in the traffic from the sender socket.
If the sender never makes such a pause, the method will never change,
and transmission may become very inefficient as the cluster grows.
With this commit, we allow such a switch between replicast and
broadcast without any need for a traffic pause.
Solution is to send a dummy message with only the header, also with
the SYN bit set, via broadcast or replicast. For the data message,
the SYN bit is set and sending via replicast or broadcast (inverse
method with dummy).
Then, at receiving side any messages follow first SYN bit message
(data or dummy message), they will be held in deferred queue until
another pair (dummy or data message) arrived in other link.
v2: reverse christmas tree declaration
Acked-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: Hoang Le <hoang.h.le@dektech.com.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-03-19 11:49:50 +00:00
|
|
|
msg_set_is_rcast(hdr, method->rcast);
|
|
|
|
|
|
|
|
/* Switch method ? */
|
tipc: fix potential hanging after b/rcast changing
In commit c55c8edafa91 ("tipc: smooth change between replicast and
broadcast"), we allow instant switching between replicast and broadcast
by sending a dummy 'SYN' packet on the last used link to synchronize
packets on the links. The 'SYN' message is an object of link congestion
also, so if that happens, a 'SOCK_WAKEUP' will be scheduled to be sent
back to the socket...
However, in that commit, we simply use the same socket 'cong_link_cnt'
counter for both the 'SYN' & normal payload message sending. Therefore,
if both the replicast & broadcast links are congested, the counter will
be not updated correctly but overwritten by the latter congestion.
Later on, when the 'SOCK_WAKEUP' messages are processed, the counter is
reduced one by one and eventually overflowed. Consequently, further
activities on the socket will only wait for the false congestion signal
to disappear but never been met.
Because sending the 'SYN' message is vital for the mechanism, it should
be done anyway. This commit fixes the issue by marking the message with
an error code e.g. 'TIPC_ERR_NO_PORT', so its sending should not face a
link congestion, there is no need to touch the socket 'cong_link_cnt'
either. In addition, in the event of any error (e.g. -ENOBUFS), we will
purge the entire payload message queue and make a return immediately.
Fixes: c55c8edafa91 ("tipc: smooth change between replicast and broadcast")
Acked-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: Tuong Lien <tuong.t.lien@dektech.com.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-12-10 08:21:03 +00:00
|
|
|
if (rcast != method->rcast) {
|
|
|
|
rc = tipc_mcast_send_sync(net, skb, method, dests);
|
|
|
|
if (unlikely(rc)) {
|
|
|
|
pr_err("Unable to send SYN: method %d, rc %d\n",
|
|
|
|
rcast, rc);
|
|
|
|
goto exit;
|
|
|
|
}
|
|
|
|
}
|
tipc: smooth change between replicast and broadcast
Currently, a multicast stream may start out using replicast, because
there are few destinations, and then it should ideally switch to
L2/broadcast IGMP/multicast when the number of destinations grows beyond
a certain limit. The opposite should happen when the number decreases
below the limit.
To eliminate the risk of message reordering caused by method change,
a sending socket must stick to a previously selected method until it
enters an idle period of 5 seconds. Means there is a 5 seconds pause
in the traffic from the sender socket.
If the sender never makes such a pause, the method will never change,
and transmission may become very inefficient as the cluster grows.
With this commit, we allow such a switch between replicast and
broadcast without any need for a traffic pause.
Solution is to send a dummy message with only the header, also with
the SYN bit set, via broadcast or replicast. For the data message,
the SYN bit is set and sending via replicast or broadcast (inverse
method with dummy).
Then, at receiving side any messages follow first SYN bit message
(data or dummy message), they will be held in deferred queue until
another pair (dummy or data message) arrived in other link.
v2: reverse christmas tree declaration
Acked-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: Hoang Le <hoang.h.le@dektech.com.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-03-19 11:49:50 +00:00
|
|
|
|
2017-01-18 18:50:53 +00:00
|
|
|
if (method->rcast)
|
2017-01-18 18:50:52 +00:00
|
|
|
rc = tipc_rcast_xmit(net, pkts, dests, cong_link_cnt);
|
|
|
|
else
|
|
|
|
rc = tipc_bcast_xmit(net, pkts, cong_link_cnt);
|
|
|
|
}
|
|
|
|
|
2019-08-07 02:52:29 +00:00
|
|
|
if (dests->local) {
|
|
|
|
tipc_loopback_trace(net, &localq);
|
2017-01-18 18:50:52 +00:00
|
|
|
tipc_sk_mcast_rcv(net, &localq, &inputq);
|
2019-08-07 02:52:29 +00:00
|
|
|
}
|
2017-01-18 18:50:52 +00:00
|
|
|
exit:
|
2017-01-18 18:50:53 +00:00
|
|
|
/* This queue should normally be empty by now */
|
2017-01-18 18:50:52 +00:00
|
|
|
__skb_queue_purge(pkts);
|
tipc: reduce risk of user starvation during link congestion
The socket code currently handles link congestion by either blocking
and trying to send again when the congestion has abated, or just
returning to the user with -EAGAIN and let him re-try later.
This mechanism is prone to starvation, because the wakeup algorithm is
non-atomic. During the time the link issues a wakeup signal, until the
socket wakes up and re-attempts sending, other senders may have come
in between and occupied the free buffer space in the link. This in turn
may lead to a socket having to make many send attempts before it is
successful. In extremely loaded systems we have observed latency times
of several seconds before a low-priority socket is able to send out a
message.
In this commit, we simplify this mechanism and reduce the risk of the
described scenario happening. When a message is attempted sent via a
congested link, we now let it be added to the link's backlog queue
anyway, thus permitting an oversubscription of one message per source
socket. We still create a wakeup item and return an error code, hence
instructing the sender to block or stop sending. Only when enough space
has been freed up in the link's backlog queue do we issue a wakeup event
that allows the sender to continue with the next message, if any.
The fact that a socket now can consider a message sent even when the
link returns a congestion code means that the sending socket code can
be simplified. Also, since this is a good opportunity to get rid of the
obsolete 'mtu change' condition in the three socket send functions, we
now choose to refactor those functions completely.
Signed-off-by: Parthasarathy Bhuvaragan <parthasarathy.bhuvaragan@ericsson.com>
Acked-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-01-03 15:55:11 +00:00
|
|
|
return rc;
|
2014-07-17 00:41:00 +00:00
|
|
|
}
|
2015-10-22 12:51:41 +00:00
|
|
|
|
|
|
|
/* tipc_bcast_rcv - receive a broadcast packet, and deliver to rcv link
|
|
|
|
*
|
|
|
|
* RCU is locked, no other locks set
|
|
|
|
*/
|
|
|
|
int tipc_bcast_rcv(struct net *net, struct tipc_link *l, struct sk_buff *skb)
|
|
|
|
{
|
|
|
|
struct tipc_msg *hdr = buf_msg(skb);
|
|
|
|
struct sk_buff_head *inputq = &tipc_bc_base(net)->inputq;
|
|
|
|
struct sk_buff_head xmitq;
|
|
|
|
int rc;
|
|
|
|
|
|
|
|
__skb_queue_head_init(&xmitq);
|
|
|
|
|
|
|
|
if (msg_mc_netid(hdr) != tipc_netid(net) || !tipc_link_is_up(l)) {
|
|
|
|
kfree_skb(skb);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
tipc_bcast_lock(net);
|
|
|
|
if (msg_user(hdr) == BCAST_PROTOCOL)
|
|
|
|
rc = tipc_link_bc_nack_rcv(l, skb, &xmitq);
|
|
|
|
else
|
|
|
|
rc = tipc_link_rcv(l, skb, NULL);
|
|
|
|
tipc_bcast_unlock(net);
|
|
|
|
|
tipc: simplify bearer level broadcast
Until now, we have been keeping track of the exact set of broadcast
destinations though the help structure tipc_node_map. This leads us to
have to maintain a whole infrastructure for supporting this, including
a pseudo-bearer and a number of functions to manipulate both the bearers
and the node map correctly. Apart from the complexity, this approach is
also limiting, as struct tipc_node_map only can support cluster local
broadcast if we want to avoid it becoming excessively large. We want to
eliminate this limitation, in order to enable introduction of scoped
multicast in the future.
A closer analysis reveals that it is unnecessary maintaining this "full
set" overview; it is sufficient to keep a counter per bearer, indicating
how many nodes can be reached via this bearer at the moment. The protocol
is now robust enough to handle transitional discrepancies between the
nominal number of reachable destinations, as expected by the broadcast
protocol itself, and the number which is actually reachable at the
moment. The initial broadcast synchronization, in conjunction with the
retransmission mechanism, ensures that all packets will eventually be
acknowledged by the correct set of destinations.
This commit introduces these changes.
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Reviewed-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2015-10-22 12:51:42 +00:00
|
|
|
tipc_bcbase_xmit(net, &xmitq);
|
2015-10-22 12:51:41 +00:00
|
|
|
|
|
|
|
/* Any socket wakeup messages ? */
|
|
|
|
if (!skb_queue_empty(inputq))
|
|
|
|
tipc_sk_rcv(net, inputq);
|
|
|
|
|
|
|
|
return rc;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* tipc_bcast_ack_rcv - receive and handle a broadcast acknowledge
|
|
|
|
*
|
|
|
|
* RCU is locked, no other locks set
|
|
|
|
*/
|
2016-10-27 22:51:55 +00:00
|
|
|
void tipc_bcast_ack_rcv(struct net *net, struct tipc_link *l,
|
|
|
|
struct tipc_msg *hdr)
|
2015-10-22 12:51:41 +00:00
|
|
|
{
|
|
|
|
struct sk_buff_head *inputq = &tipc_bc_base(net)->inputq;
|
2016-10-27 22:51:55 +00:00
|
|
|
u16 acked = msg_bcast_ack(hdr);
|
2015-10-22 12:51:41 +00:00
|
|
|
struct sk_buff_head xmitq;
|
|
|
|
|
2016-10-27 22:51:55 +00:00
|
|
|
/* Ignore bc acks sent by peer before bcast synch point was received */
|
|
|
|
if (msg_bc_ack_invalid(hdr))
|
|
|
|
return;
|
|
|
|
|
2015-10-22 12:51:41 +00:00
|
|
|
__skb_queue_head_init(&xmitq);
|
|
|
|
|
|
|
|
tipc_bcast_lock(net);
|
2020-05-26 09:38:36 +00:00
|
|
|
tipc_link_bc_ack_rcv(l, acked, 0, NULL, &xmitq, NULL);
|
2015-10-22 12:51:41 +00:00
|
|
|
tipc_bcast_unlock(net);
|
|
|
|
|
tipc: simplify bearer level broadcast
Until now, we have been keeping track of the exact set of broadcast
destinations though the help structure tipc_node_map. This leads us to
have to maintain a whole infrastructure for supporting this, including
a pseudo-bearer and a number of functions to manipulate both the bearers
and the node map correctly. Apart from the complexity, this approach is
also limiting, as struct tipc_node_map only can support cluster local
broadcast if we want to avoid it becoming excessively large. We want to
eliminate this limitation, in order to enable introduction of scoped
multicast in the future.
A closer analysis reveals that it is unnecessary maintaining this "full
set" overview; it is sufficient to keep a counter per bearer, indicating
how many nodes can be reached via this bearer at the moment. The protocol
is now robust enough to handle transitional discrepancies between the
nominal number of reachable destinations, as expected by the broadcast
protocol itself, and the number which is actually reachable at the
moment. The initial broadcast synchronization, in conjunction with the
retransmission mechanism, ensures that all packets will eventually be
acknowledged by the correct set of destinations.
This commit introduces these changes.
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Reviewed-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2015-10-22 12:51:42 +00:00
|
|
|
tipc_bcbase_xmit(net, &xmitq);
|
2015-10-22 12:51:41 +00:00
|
|
|
|
|
|
|
/* Any socket wakeup messages ? */
|
|
|
|
if (!skb_queue_empty(inputq))
|
|
|
|
tipc_sk_rcv(net, inputq);
|
|
|
|
}
|
|
|
|
|
|
|
|
/* tipc_bcast_synch_rcv - check and update rcv link with peer's send state
|
|
|
|
*
|
|
|
|
* RCU is locked, no other locks set
|
|
|
|
*/
|
2016-09-01 17:52:49 +00:00
|
|
|
int tipc_bcast_sync_rcv(struct net *net, struct tipc_link *l,
|
2020-05-26 09:38:36 +00:00
|
|
|
struct tipc_msg *hdr,
|
|
|
|
struct sk_buff_head *retrq)
|
2015-10-22 12:51:41 +00:00
|
|
|
{
|
|
|
|
struct sk_buff_head *inputq = &tipc_bc_base(net)->inputq;
|
2020-05-26 09:38:34 +00:00
|
|
|
struct tipc_gap_ack_blks *ga;
|
2015-10-22 12:51:41 +00:00
|
|
|
struct sk_buff_head xmitq;
|
2016-09-01 17:52:49 +00:00
|
|
|
int rc = 0;
|
2015-10-22 12:51:41 +00:00
|
|
|
|
|
|
|
__skb_queue_head_init(&xmitq);
|
|
|
|
|
|
|
|
tipc_bcast_lock(net);
|
2016-10-27 22:51:55 +00:00
|
|
|
if (msg_type(hdr) != STATE_MSG) {
|
|
|
|
tipc_link_bc_init_rcv(l, hdr);
|
|
|
|
} else if (!msg_bc_ack_invalid(hdr)) {
|
2020-05-26 09:38:34 +00:00
|
|
|
tipc_get_gap_ack_blks(&ga, l, hdr, false);
|
2020-05-26 09:38:36 +00:00
|
|
|
if (!sysctl_tipc_bc_retruni)
|
|
|
|
retrq = &xmitq;
|
2020-05-26 09:38:34 +00:00
|
|
|
rc = tipc_link_bc_ack_rcv(l, msg_bcast_ack(hdr),
|
2020-05-26 09:38:36 +00:00
|
|
|
msg_bc_gap(hdr), ga, &xmitq,
|
|
|
|
retrq);
|
2020-05-26 09:38:34 +00:00
|
|
|
rc |= tipc_link_bc_sync_rcv(l, hdr, &xmitq);
|
2015-10-22 12:51:41 +00:00
|
|
|
}
|
|
|
|
tipc_bcast_unlock(net);
|
|
|
|
|
tipc: simplify bearer level broadcast
Until now, we have been keeping track of the exact set of broadcast
destinations though the help structure tipc_node_map. This leads us to
have to maintain a whole infrastructure for supporting this, including
a pseudo-bearer and a number of functions to manipulate both the bearers
and the node map correctly. Apart from the complexity, this approach is
also limiting, as struct tipc_node_map only can support cluster local
broadcast if we want to avoid it becoming excessively large. We want to
eliminate this limitation, in order to enable introduction of scoped
multicast in the future.
A closer analysis reveals that it is unnecessary maintaining this "full
set" overview; it is sufficient to keep a counter per bearer, indicating
how many nodes can be reached via this bearer at the moment. The protocol
is now robust enough to handle transitional discrepancies between the
nominal number of reachable destinations, as expected by the broadcast
protocol itself, and the number which is actually reachable at the
moment. The initial broadcast synchronization, in conjunction with the
retransmission mechanism, ensures that all packets will eventually be
acknowledged by the correct set of destinations.
This commit introduces these changes.
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Reviewed-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2015-10-22 12:51:42 +00:00
|
|
|
tipc_bcbase_xmit(net, &xmitq);
|
2015-10-22 12:51:41 +00:00
|
|
|
|
|
|
|
/* Any socket wakeup messages ? */
|
|
|
|
if (!skb_queue_empty(inputq))
|
|
|
|
tipc_sk_rcv(net, inputq);
|
2016-09-01 17:52:49 +00:00
|
|
|
return rc;
|
2015-10-22 12:51:41 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/* tipc_bcast_add_peer - add a peer node to broadcast link and bearer
|
|
|
|
*
|
|
|
|
* RCU is locked, node lock is set
|
|
|
|
*/
|
tipc: simplify bearer level broadcast
Until now, we have been keeping track of the exact set of broadcast
destinations though the help structure tipc_node_map. This leads us to
have to maintain a whole infrastructure for supporting this, including
a pseudo-bearer and a number of functions to manipulate both the bearers
and the node map correctly. Apart from the complexity, this approach is
also limiting, as struct tipc_node_map only can support cluster local
broadcast if we want to avoid it becoming excessively large. We want to
eliminate this limitation, in order to enable introduction of scoped
multicast in the future.
A closer analysis reveals that it is unnecessary maintaining this "full
set" overview; it is sufficient to keep a counter per bearer, indicating
how many nodes can be reached via this bearer at the moment. The protocol
is now robust enough to handle transitional discrepancies between the
nominal number of reachable destinations, as expected by the broadcast
protocol itself, and the number which is actually reachable at the
moment. The initial broadcast synchronization, in conjunction with the
retransmission mechanism, ensures that all packets will eventually be
acknowledged by the correct set of destinations.
This commit introduces these changes.
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Reviewed-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2015-10-22 12:51:42 +00:00
|
|
|
void tipc_bcast_add_peer(struct net *net, struct tipc_link *uc_l,
|
2015-10-22 12:51:41 +00:00
|
|
|
struct sk_buff_head *xmitq)
|
|
|
|
{
|
|
|
|
struct tipc_link *snd_l = tipc_bc_sndlink(net);
|
|
|
|
|
tipc: simplify bearer level broadcast
Until now, we have been keeping track of the exact set of broadcast
destinations though the help structure tipc_node_map. This leads us to
have to maintain a whole infrastructure for supporting this, including
a pseudo-bearer and a number of functions to manipulate both the bearers
and the node map correctly. Apart from the complexity, this approach is
also limiting, as struct tipc_node_map only can support cluster local
broadcast if we want to avoid it becoming excessively large. We want to
eliminate this limitation, in order to enable introduction of scoped
multicast in the future.
A closer analysis reveals that it is unnecessary maintaining this "full
set" overview; it is sufficient to keep a counter per bearer, indicating
how many nodes can be reached via this bearer at the moment. The protocol
is now robust enough to handle transitional discrepancies between the
nominal number of reachable destinations, as expected by the broadcast
protocol itself, and the number which is actually reachable at the
moment. The initial broadcast synchronization, in conjunction with the
retransmission mechanism, ensures that all packets will eventually be
acknowledged by the correct set of destinations.
This commit introduces these changes.
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Reviewed-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2015-10-22 12:51:42 +00:00
|
|
|
tipc_bcast_lock(net);
|
2015-10-22 12:51:41 +00:00
|
|
|
tipc_link_add_bc_peer(snd_l, uc_l, xmitq);
|
tipc: simplify bearer level broadcast
Until now, we have been keeping track of the exact set of broadcast
destinations though the help structure tipc_node_map. This leads us to
have to maintain a whole infrastructure for supporting this, including
a pseudo-bearer and a number of functions to manipulate both the bearers
and the node map correctly. Apart from the complexity, this approach is
also limiting, as struct tipc_node_map only can support cluster local
broadcast if we want to avoid it becoming excessively large. We want to
eliminate this limitation, in order to enable introduction of scoped
multicast in the future.
A closer analysis reveals that it is unnecessary maintaining this "full
set" overview; it is sufficient to keep a counter per bearer, indicating
how many nodes can be reached via this bearer at the moment. The protocol
is now robust enough to handle transitional discrepancies between the
nominal number of reachable destinations, as expected by the broadcast
protocol itself, and the number which is actually reachable at the
moment. The initial broadcast synchronization, in conjunction with the
retransmission mechanism, ensures that all packets will eventually be
acknowledged by the correct set of destinations.
This commit introduces these changes.
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Reviewed-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2015-10-22 12:51:42 +00:00
|
|
|
tipc_bcbase_select_primary(net);
|
2017-01-18 18:50:53 +00:00
|
|
|
tipc_bcbase_calc_bc_threshold(net);
|
tipc: simplify bearer level broadcast
Until now, we have been keeping track of the exact set of broadcast
destinations though the help structure tipc_node_map. This leads us to
have to maintain a whole infrastructure for supporting this, including
a pseudo-bearer and a number of functions to manipulate both the bearers
and the node map correctly. Apart from the complexity, this approach is
also limiting, as struct tipc_node_map only can support cluster local
broadcast if we want to avoid it becoming excessively large. We want to
eliminate this limitation, in order to enable introduction of scoped
multicast in the future.
A closer analysis reveals that it is unnecessary maintaining this "full
set" overview; it is sufficient to keep a counter per bearer, indicating
how many nodes can be reached via this bearer at the moment. The protocol
is now robust enough to handle transitional discrepancies between the
nominal number of reachable destinations, as expected by the broadcast
protocol itself, and the number which is actually reachable at the
moment. The initial broadcast synchronization, in conjunction with the
retransmission mechanism, ensures that all packets will eventually be
acknowledged by the correct set of destinations.
This commit introduces these changes.
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Reviewed-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2015-10-22 12:51:42 +00:00
|
|
|
tipc_bcast_unlock(net);
|
2015-10-22 12:51:41 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/* tipc_bcast_remove_peer - remove a peer node from broadcast link and bearer
|
|
|
|
*
|
|
|
|
* RCU is locked, node lock is set
|
|
|
|
*/
|
tipc: simplify bearer level broadcast
Until now, we have been keeping track of the exact set of broadcast
destinations though the help structure tipc_node_map. This leads us to
have to maintain a whole infrastructure for supporting this, including
a pseudo-bearer and a number of functions to manipulate both the bearers
and the node map correctly. Apart from the complexity, this approach is
also limiting, as struct tipc_node_map only can support cluster local
broadcast if we want to avoid it becoming excessively large. We want to
eliminate this limitation, in order to enable introduction of scoped
multicast in the future.
A closer analysis reveals that it is unnecessary maintaining this "full
set" overview; it is sufficient to keep a counter per bearer, indicating
how many nodes can be reached via this bearer at the moment. The protocol
is now robust enough to handle transitional discrepancies between the
nominal number of reachable destinations, as expected by the broadcast
protocol itself, and the number which is actually reachable at the
moment. The initial broadcast synchronization, in conjunction with the
retransmission mechanism, ensures that all packets will eventually be
acknowledged by the correct set of destinations.
This commit introduces these changes.
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Reviewed-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2015-10-22 12:51:42 +00:00
|
|
|
void tipc_bcast_remove_peer(struct net *net, struct tipc_link *rcv_l)
|
2015-10-22 12:51:41 +00:00
|
|
|
{
|
|
|
|
struct tipc_link *snd_l = tipc_bc_sndlink(net);
|
tipc: simplify bearer level broadcast
Until now, we have been keeping track of the exact set of broadcast
destinations though the help structure tipc_node_map. This leads us to
have to maintain a whole infrastructure for supporting this, including
a pseudo-bearer and a number of functions to manipulate both the bearers
and the node map correctly. Apart from the complexity, this approach is
also limiting, as struct tipc_node_map only can support cluster local
broadcast if we want to avoid it becoming excessively large. We want to
eliminate this limitation, in order to enable introduction of scoped
multicast in the future.
A closer analysis reveals that it is unnecessary maintaining this "full
set" overview; it is sufficient to keep a counter per bearer, indicating
how many nodes can be reached via this bearer at the moment. The protocol
is now robust enough to handle transitional discrepancies between the
nominal number of reachable destinations, as expected by the broadcast
protocol itself, and the number which is actually reachable at the
moment. The initial broadcast synchronization, in conjunction with the
retransmission mechanism, ensures that all packets will eventually be
acknowledged by the correct set of destinations.
This commit introduces these changes.
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Reviewed-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2015-10-22 12:51:42 +00:00
|
|
|
struct sk_buff_head *inputq = &tipc_bc_base(net)->inputq;
|
2015-10-22 12:51:41 +00:00
|
|
|
struct sk_buff_head xmitq;
|
|
|
|
|
|
|
|
__skb_queue_head_init(&xmitq);
|
|
|
|
|
tipc: simplify bearer level broadcast
Until now, we have been keeping track of the exact set of broadcast
destinations though the help structure tipc_node_map. This leads us to
have to maintain a whole infrastructure for supporting this, including
a pseudo-bearer and a number of functions to manipulate both the bearers
and the node map correctly. Apart from the complexity, this approach is
also limiting, as struct tipc_node_map only can support cluster local
broadcast if we want to avoid it becoming excessively large. We want to
eliminate this limitation, in order to enable introduction of scoped
multicast in the future.
A closer analysis reveals that it is unnecessary maintaining this "full
set" overview; it is sufficient to keep a counter per bearer, indicating
how many nodes can be reached via this bearer at the moment. The protocol
is now robust enough to handle transitional discrepancies between the
nominal number of reachable destinations, as expected by the broadcast
protocol itself, and the number which is actually reachable at the
moment. The initial broadcast synchronization, in conjunction with the
retransmission mechanism, ensures that all packets will eventually be
acknowledged by the correct set of destinations.
This commit introduces these changes.
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Reviewed-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2015-10-22 12:51:42 +00:00
|
|
|
tipc_bcast_lock(net);
|
2015-10-22 12:51:41 +00:00
|
|
|
tipc_link_remove_bc_peer(snd_l, rcv_l, &xmitq);
|
tipc: simplify bearer level broadcast
Until now, we have been keeping track of the exact set of broadcast
destinations though the help structure tipc_node_map. This leads us to
have to maintain a whole infrastructure for supporting this, including
a pseudo-bearer and a number of functions to manipulate both the bearers
and the node map correctly. Apart from the complexity, this approach is
also limiting, as struct tipc_node_map only can support cluster local
broadcast if we want to avoid it becoming excessively large. We want to
eliminate this limitation, in order to enable introduction of scoped
multicast in the future.
A closer analysis reveals that it is unnecessary maintaining this "full
set" overview; it is sufficient to keep a counter per bearer, indicating
how many nodes can be reached via this bearer at the moment. The protocol
is now robust enough to handle transitional discrepancies between the
nominal number of reachable destinations, as expected by the broadcast
protocol itself, and the number which is actually reachable at the
moment. The initial broadcast synchronization, in conjunction with the
retransmission mechanism, ensures that all packets will eventually be
acknowledged by the correct set of destinations.
This commit introduces these changes.
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Reviewed-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2015-10-22 12:51:42 +00:00
|
|
|
tipc_bcbase_select_primary(net);
|
2017-01-18 18:50:53 +00:00
|
|
|
tipc_bcbase_calc_bc_threshold(net);
|
tipc: simplify bearer level broadcast
Until now, we have been keeping track of the exact set of broadcast
destinations though the help structure tipc_node_map. This leads us to
have to maintain a whole infrastructure for supporting this, including
a pseudo-bearer and a number of functions to manipulate both the bearers
and the node map correctly. Apart from the complexity, this approach is
also limiting, as struct tipc_node_map only can support cluster local
broadcast if we want to avoid it becoming excessively large. We want to
eliminate this limitation, in order to enable introduction of scoped
multicast in the future.
A closer analysis reveals that it is unnecessary maintaining this "full
set" overview; it is sufficient to keep a counter per bearer, indicating
how many nodes can be reached via this bearer at the moment. The protocol
is now robust enough to handle transitional discrepancies between the
nominal number of reachable destinations, as expected by the broadcast
protocol itself, and the number which is actually reachable at the
moment. The initial broadcast synchronization, in conjunction with the
retransmission mechanism, ensures that all packets will eventually be
acknowledged by the correct set of destinations.
This commit introduces these changes.
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Reviewed-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2015-10-22 12:51:42 +00:00
|
|
|
tipc_bcast_unlock(net);
|
2015-10-22 12:51:41 +00:00
|
|
|
|
tipc: simplify bearer level broadcast
Until now, we have been keeping track of the exact set of broadcast
destinations though the help structure tipc_node_map. This leads us to
have to maintain a whole infrastructure for supporting this, including
a pseudo-bearer and a number of functions to manipulate both the bearers
and the node map correctly. Apart from the complexity, this approach is
also limiting, as struct tipc_node_map only can support cluster local
broadcast if we want to avoid it becoming excessively large. We want to
eliminate this limitation, in order to enable introduction of scoped
multicast in the future.
A closer analysis reveals that it is unnecessary maintaining this "full
set" overview; it is sufficient to keep a counter per bearer, indicating
how many nodes can be reached via this bearer at the moment. The protocol
is now robust enough to handle transitional discrepancies between the
nominal number of reachable destinations, as expected by the broadcast
protocol itself, and the number which is actually reachable at the
moment. The initial broadcast synchronization, in conjunction with the
retransmission mechanism, ensures that all packets will eventually be
acknowledged by the correct set of destinations.
This commit introduces these changes.
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Reviewed-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2015-10-22 12:51:42 +00:00
|
|
|
tipc_bcbase_xmit(net, &xmitq);
|
2015-10-22 12:51:41 +00:00
|
|
|
|
|
|
|
/* Any socket wakeup messages ? */
|
|
|
|
if (!skb_queue_empty(inputq))
|
|
|
|
tipc_sk_rcv(net, inputq);
|
|
|
|
}
|
|
|
|
|
2020-05-26 09:38:37 +00:00
|
|
|
int tipc_bclink_reset_stats(struct net *net, struct tipc_link *l)
|
2006-01-02 18:04:38 +00:00
|
|
|
{
|
2015-11-19 19:30:46 +00:00
|
|
|
if (!l)
|
2006-01-02 18:04:38 +00:00
|
|
|
return -ENOPROTOOPT;
|
|
|
|
|
2015-10-22 12:51:48 +00:00
|
|
|
tipc_bcast_lock(net);
|
2015-11-19 19:30:46 +00:00
|
|
|
tipc_link_reset_stats(l);
|
2015-10-22 12:51:48 +00:00
|
|
|
tipc_bcast_unlock(net);
|
2008-07-15 05:44:01 +00:00
|
|
|
return 0;
|
2006-01-02 18:04:38 +00:00
|
|
|
}
|
|
|
|
|
tipc: introduce variable window congestion control
We introduce a simple variable window congestion control for links.
The algorithm is inspired by the Reno algorithm, covering both 'slow
start', 'congestion avoidance', and 'fast recovery' modes.
- We introduce hard lower and upper window limits per link, still
different and configurable per bearer type.
- We introduce a 'slow start theshold' variable, initially set to
the maximum window size.
- We let a link start at the minimum congestion window, i.e. in slow
start mode, and then let is grow rapidly (+1 per rceived ACK) until
it reaches the slow start threshold and enters congestion avoidance
mode.
- In congestion avoidance mode we increment the congestion window for
each window-size number of acked packets, up to a possible maximum
equal to the configured maximum window.
- For each non-duplicate NACK received, we drop back to fast recovery
mode, by setting the both the slow start threshold to and the
congestion window to (current_congestion_window / 2).
- If the timeout handler finds that the transmit queue has not moved
since the previous timeout, it drops the link back to slow start
and forces a probe containing the last sent sequence number to the
sent to the peer, so that this can discover the stale situation.
This change does in reality have effect only on unicast ethernet
transport, as we have seen that there is no room whatsoever for
increasing the window max size for the UDP bearer.
For now, we also choose to keep the limits for the broadcast link
unchanged and equal.
This algorithm seems to give a 50-100% throughput improvement for
messages larger than MTU.
Suggested-by: Xin Long <lucien.xin@gmail.com>
Acked-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-12-09 23:52:46 +00:00
|
|
|
static int tipc_bc_link_set_queue_limits(struct net *net, u32 max_win)
|
2006-01-02 18:04:38 +00:00
|
|
|
{
|
2015-10-22 12:51:48 +00:00
|
|
|
struct tipc_link *l = tipc_bc_sndlink(net);
|
2015-01-09 07:27:07 +00:00
|
|
|
|
2015-10-22 12:51:48 +00:00
|
|
|
if (!l)
|
2006-01-02 18:04:38 +00:00
|
|
|
return -ENOPROTOOPT;
|
tipc: introduce variable window congestion control
We introduce a simple variable window congestion control for links.
The algorithm is inspired by the Reno algorithm, covering both 'slow
start', 'congestion avoidance', and 'fast recovery' modes.
- We introduce hard lower and upper window limits per link, still
different and configurable per bearer type.
- We introduce a 'slow start theshold' variable, initially set to
the maximum window size.
- We let a link start at the minimum congestion window, i.e. in slow
start mode, and then let is grow rapidly (+1 per rceived ACK) until
it reaches the slow start threshold and enters congestion avoidance
mode.
- In congestion avoidance mode we increment the congestion window for
each window-size number of acked packets, up to a possible maximum
equal to the configured maximum window.
- For each non-duplicate NACK received, we drop back to fast recovery
mode, by setting the both the slow start threshold to and the
congestion window to (current_congestion_window / 2).
- If the timeout handler finds that the transmit queue has not moved
since the previous timeout, it drops the link back to slow start
and forces a probe containing the last sent sequence number to the
sent to the peer, so that this can discover the stale situation.
This change does in reality have effect only on unicast ethernet
transport, as we have seen that there is no room whatsoever for
increasing the window max size for the UDP bearer.
For now, we also choose to keep the limits for the broadcast link
unchanged and equal.
This algorithm seems to give a 50-100% throughput improvement for
messages larger than MTU.
Suggested-by: Xin Long <lucien.xin@gmail.com>
Acked-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-12-09 23:52:46 +00:00
|
|
|
if (max_win < BCLINK_WIN_MIN)
|
|
|
|
max_win = BCLINK_WIN_MIN;
|
|
|
|
if (max_win > TIPC_MAX_LINK_WIN)
|
2006-01-02 18:04:38 +00:00
|
|
|
return -EINVAL;
|
2015-10-22 12:51:48 +00:00
|
|
|
tipc_bcast_lock(net);
|
2020-10-16 02:31:19 +00:00
|
|
|
tipc_link_set_queue_limits(l, tipc_link_min_win(l), max_win);
|
2015-10-22 12:51:48 +00:00
|
|
|
tipc_bcast_unlock(net);
|
2008-07-15 05:44:01 +00:00
|
|
|
return 0;
|
2006-01-02 18:04:38 +00:00
|
|
|
}
|
|
|
|
|
tipc: support broadcast/replicast configurable for bc-link
Currently, a multicast stream uses either broadcast or replicast as
transmission method, based on the ratio between number of actual
destinations nodes and cluster size.
However, when an L2 interface (e.g., VXLAN) provides pseudo
broadcast support, this becomes very inefficient, as it blindly
replicates multicast packets to all cluster/subnet nodes,
irrespective of whether they host actual target sockets or not.
The TIPC multicast algorithm is able to distinguish real destination
nodes from other nodes, and hence provides a smarter and more
efficient method for transferring multicast messages than
pseudo broadcast can do.
Because of this, we now make it possible for users to force
the broadcast link to permanently switch to using replicast,
irrespective of which capabilities the bearer provides,
or pretend to provide.
Conversely, we also make it possible to force the broadcast link
to always use true broadcast. While maybe less useful in
deployed systems, this may at least be useful for testing the
broadcast algorithm in small clusters.
We retain the current AUTOSELECT ability, i.e., to let the broadcast link
automatically select which algorithm to use, and to switch back and forth
between broadcast and replicast as the ratio between destination
node number and cluster size changes. This remains the default method.
Furthermore, we make it possible to configure the threshold ratio for
such switches. The default ratio is now set to 10%, down from 25% in the
earlier implementation.
Acked-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: Hoang Le <hoang.h.le@dektech.com.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-03-19 11:49:48 +00:00
|
|
|
static int tipc_bc_link_set_broadcast_mode(struct net *net, u32 bc_mode)
|
|
|
|
{
|
|
|
|
struct tipc_bc_base *bb = tipc_bc_base(net);
|
|
|
|
|
|
|
|
switch (bc_mode) {
|
|
|
|
case BCLINK_MODE_BCAST:
|
|
|
|
if (!bb->bcast_support)
|
|
|
|
return -ENOPROTOOPT;
|
|
|
|
|
|
|
|
bb->force_bcast = true;
|
|
|
|
bb->force_rcast = false;
|
|
|
|
break;
|
|
|
|
case BCLINK_MODE_RCAST:
|
|
|
|
if (!bb->rcast_support)
|
|
|
|
return -ENOPROTOOPT;
|
|
|
|
|
|
|
|
bb->force_bcast = false;
|
|
|
|
bb->force_rcast = true;
|
|
|
|
break;
|
|
|
|
case BCLINK_MODE_SEL:
|
|
|
|
if (!bb->bcast_support || !bb->rcast_support)
|
|
|
|
return -ENOPROTOOPT;
|
|
|
|
|
|
|
|
bb->force_bcast = false;
|
|
|
|
bb->force_rcast = false;
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int tipc_bc_link_set_broadcast_ratio(struct net *net, u32 bc_ratio)
|
|
|
|
{
|
|
|
|
struct tipc_bc_base *bb = tipc_bc_base(net);
|
|
|
|
|
|
|
|
if (!bb->bcast_support || !bb->rcast_support)
|
|
|
|
return -ENOPROTOOPT;
|
|
|
|
|
|
|
|
if (bc_ratio > 100 || bc_ratio <= 0)
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
bb->rc_ratio = bc_ratio;
|
|
|
|
tipc_bcast_lock(net);
|
|
|
|
tipc_bcbase_calc_bc_threshold(net);
|
|
|
|
tipc_bcast_unlock(net);
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2015-05-06 11:58:55 +00:00
|
|
|
int tipc_nl_bc_link_set(struct net *net, struct nlattr *attrs[])
|
|
|
|
{
|
|
|
|
int err;
|
|
|
|
u32 win;
|
tipc: support broadcast/replicast configurable for bc-link
Currently, a multicast stream uses either broadcast or replicast as
transmission method, based on the ratio between number of actual
destinations nodes and cluster size.
However, when an L2 interface (e.g., VXLAN) provides pseudo
broadcast support, this becomes very inefficient, as it blindly
replicates multicast packets to all cluster/subnet nodes,
irrespective of whether they host actual target sockets or not.
The TIPC multicast algorithm is able to distinguish real destination
nodes from other nodes, and hence provides a smarter and more
efficient method for transferring multicast messages than
pseudo broadcast can do.
Because of this, we now make it possible for users to force
the broadcast link to permanently switch to using replicast,
irrespective of which capabilities the bearer provides,
or pretend to provide.
Conversely, we also make it possible to force the broadcast link
to always use true broadcast. While maybe less useful in
deployed systems, this may at least be useful for testing the
broadcast algorithm in small clusters.
We retain the current AUTOSELECT ability, i.e., to let the broadcast link
automatically select which algorithm to use, and to switch back and forth
between broadcast and replicast as the ratio between destination
node number and cluster size changes. This remains the default method.
Furthermore, we make it possible to configure the threshold ratio for
such switches. The default ratio is now set to 10%, down from 25% in the
earlier implementation.
Acked-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: Hoang Le <hoang.h.le@dektech.com.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-03-19 11:49:48 +00:00
|
|
|
u32 bc_mode;
|
|
|
|
u32 bc_ratio;
|
2015-05-06 11:58:55 +00:00
|
|
|
struct nlattr *props[TIPC_NLA_PROP_MAX + 1];
|
|
|
|
|
|
|
|
if (!attrs[TIPC_NLA_LINK_PROP])
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
err = tipc_nl_parse_link_prop(attrs[TIPC_NLA_LINK_PROP], props);
|
|
|
|
if (err)
|
|
|
|
return err;
|
|
|
|
|
tipc: support broadcast/replicast configurable for bc-link
Currently, a multicast stream uses either broadcast or replicast as
transmission method, based on the ratio between number of actual
destinations nodes and cluster size.
However, when an L2 interface (e.g., VXLAN) provides pseudo
broadcast support, this becomes very inefficient, as it blindly
replicates multicast packets to all cluster/subnet nodes,
irrespective of whether they host actual target sockets or not.
The TIPC multicast algorithm is able to distinguish real destination
nodes from other nodes, and hence provides a smarter and more
efficient method for transferring multicast messages than
pseudo broadcast can do.
Because of this, we now make it possible for users to force
the broadcast link to permanently switch to using replicast,
irrespective of which capabilities the bearer provides,
or pretend to provide.
Conversely, we also make it possible to force the broadcast link
to always use true broadcast. While maybe less useful in
deployed systems, this may at least be useful for testing the
broadcast algorithm in small clusters.
We retain the current AUTOSELECT ability, i.e., to let the broadcast link
automatically select which algorithm to use, and to switch back and forth
between broadcast and replicast as the ratio between destination
node number and cluster size changes. This remains the default method.
Furthermore, we make it possible to configure the threshold ratio for
such switches. The default ratio is now set to 10%, down from 25% in the
earlier implementation.
Acked-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: Hoang Le <hoang.h.le@dektech.com.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-03-19 11:49:48 +00:00
|
|
|
if (!props[TIPC_NLA_PROP_WIN] &&
|
|
|
|
!props[TIPC_NLA_PROP_BROADCAST] &&
|
|
|
|
!props[TIPC_NLA_PROP_BROADCAST_RATIO]) {
|
2015-05-06 11:58:55 +00:00
|
|
|
return -EOPNOTSUPP;
|
tipc: support broadcast/replicast configurable for bc-link
Currently, a multicast stream uses either broadcast or replicast as
transmission method, based on the ratio between number of actual
destinations nodes and cluster size.
However, when an L2 interface (e.g., VXLAN) provides pseudo
broadcast support, this becomes very inefficient, as it blindly
replicates multicast packets to all cluster/subnet nodes,
irrespective of whether they host actual target sockets or not.
The TIPC multicast algorithm is able to distinguish real destination
nodes from other nodes, and hence provides a smarter and more
efficient method for transferring multicast messages than
pseudo broadcast can do.
Because of this, we now make it possible for users to force
the broadcast link to permanently switch to using replicast,
irrespective of which capabilities the bearer provides,
or pretend to provide.
Conversely, we also make it possible to force the broadcast link
to always use true broadcast. While maybe less useful in
deployed systems, this may at least be useful for testing the
broadcast algorithm in small clusters.
We retain the current AUTOSELECT ability, i.e., to let the broadcast link
automatically select which algorithm to use, and to switch back and forth
between broadcast and replicast as the ratio between destination
node number and cluster size changes. This remains the default method.
Furthermore, we make it possible to configure the threshold ratio for
such switches. The default ratio is now set to 10%, down from 25% in the
earlier implementation.
Acked-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: Hoang Le <hoang.h.le@dektech.com.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-03-19 11:49:48 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
if (props[TIPC_NLA_PROP_BROADCAST]) {
|
|
|
|
bc_mode = nla_get_u32(props[TIPC_NLA_PROP_BROADCAST]);
|
|
|
|
err = tipc_bc_link_set_broadcast_mode(net, bc_mode);
|
|
|
|
}
|
2015-05-06 11:58:55 +00:00
|
|
|
|
tipc: support broadcast/replicast configurable for bc-link
Currently, a multicast stream uses either broadcast or replicast as
transmission method, based on the ratio between number of actual
destinations nodes and cluster size.
However, when an L2 interface (e.g., VXLAN) provides pseudo
broadcast support, this becomes very inefficient, as it blindly
replicates multicast packets to all cluster/subnet nodes,
irrespective of whether they host actual target sockets or not.
The TIPC multicast algorithm is able to distinguish real destination
nodes from other nodes, and hence provides a smarter and more
efficient method for transferring multicast messages than
pseudo broadcast can do.
Because of this, we now make it possible for users to force
the broadcast link to permanently switch to using replicast,
irrespective of which capabilities the bearer provides,
or pretend to provide.
Conversely, we also make it possible to force the broadcast link
to always use true broadcast. While maybe less useful in
deployed systems, this may at least be useful for testing the
broadcast algorithm in small clusters.
We retain the current AUTOSELECT ability, i.e., to let the broadcast link
automatically select which algorithm to use, and to switch back and forth
between broadcast and replicast as the ratio between destination
node number and cluster size changes. This remains the default method.
Furthermore, we make it possible to configure the threshold ratio for
such switches. The default ratio is now set to 10%, down from 25% in the
earlier implementation.
Acked-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: Hoang Le <hoang.h.le@dektech.com.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-03-19 11:49:48 +00:00
|
|
|
if (!err && props[TIPC_NLA_PROP_BROADCAST_RATIO]) {
|
|
|
|
bc_ratio = nla_get_u32(props[TIPC_NLA_PROP_BROADCAST_RATIO]);
|
|
|
|
err = tipc_bc_link_set_broadcast_ratio(net, bc_ratio);
|
|
|
|
}
|
2015-05-06 11:58:55 +00:00
|
|
|
|
tipc: support broadcast/replicast configurable for bc-link
Currently, a multicast stream uses either broadcast or replicast as
transmission method, based on the ratio between number of actual
destinations nodes and cluster size.
However, when an L2 interface (e.g., VXLAN) provides pseudo
broadcast support, this becomes very inefficient, as it blindly
replicates multicast packets to all cluster/subnet nodes,
irrespective of whether they host actual target sockets or not.
The TIPC multicast algorithm is able to distinguish real destination
nodes from other nodes, and hence provides a smarter and more
efficient method for transferring multicast messages than
pseudo broadcast can do.
Because of this, we now make it possible for users to force
the broadcast link to permanently switch to using replicast,
irrespective of which capabilities the bearer provides,
or pretend to provide.
Conversely, we also make it possible to force the broadcast link
to always use true broadcast. While maybe less useful in
deployed systems, this may at least be useful for testing the
broadcast algorithm in small clusters.
We retain the current AUTOSELECT ability, i.e., to let the broadcast link
automatically select which algorithm to use, and to switch back and forth
between broadcast and replicast as the ratio between destination
node number and cluster size changes. This remains the default method.
Furthermore, we make it possible to configure the threshold ratio for
such switches. The default ratio is now set to 10%, down from 25% in the
earlier implementation.
Acked-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: Hoang Le <hoang.h.le@dektech.com.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-03-19 11:49:48 +00:00
|
|
|
if (!err && props[TIPC_NLA_PROP_WIN]) {
|
|
|
|
win = nla_get_u32(props[TIPC_NLA_PROP_WIN]);
|
|
|
|
err = tipc_bc_link_set_queue_limits(net, win);
|
|
|
|
}
|
|
|
|
|
|
|
|
return err;
|
2015-05-06 11:58:55 +00:00
|
|
|
}
|
|
|
|
|
2015-10-22 12:51:33 +00:00
|
|
|
int tipc_bcast_init(struct net *net)
|
2006-01-02 18:04:38 +00:00
|
|
|
{
|
2015-10-22 12:51:37 +00:00
|
|
|
struct tipc_net *tn = tipc_net(net);
|
|
|
|
struct tipc_bc_base *bb = NULL;
|
|
|
|
struct tipc_link *l = NULL;
|
|
|
|
|
2018-07-27 09:31:35 +00:00
|
|
|
bb = kzalloc(sizeof(*bb), GFP_KERNEL);
|
2015-10-22 12:51:37 +00:00
|
|
|
if (!bb)
|
|
|
|
goto enomem;
|
|
|
|
tn->bcbase = bb;
|
2015-10-22 12:51:34 +00:00
|
|
|
spin_lock_init(&tipc_net(net)->bclock);
|
2015-10-22 12:51:37 +00:00
|
|
|
|
2020-05-26 09:38:37 +00:00
|
|
|
if (!tipc_link_bc_create(net, 0, 0, NULL,
|
2021-06-28 06:37:44 +00:00
|
|
|
one_page_mtu,
|
2015-10-22 12:51:37 +00:00
|
|
|
BCLINK_WIN_DEFAULT,
|
tipc: introduce variable window congestion control
We introduce a simple variable window congestion control for links.
The algorithm is inspired by the Reno algorithm, covering both 'slow
start', 'congestion avoidance', and 'fast recovery' modes.
- We introduce hard lower and upper window limits per link, still
different and configurable per bearer type.
- We introduce a 'slow start theshold' variable, initially set to
the maximum window size.
- We let a link start at the minimum congestion window, i.e. in slow
start mode, and then let is grow rapidly (+1 per rceived ACK) until
it reaches the slow start threshold and enters congestion avoidance
mode.
- In congestion avoidance mode we increment the congestion window for
each window-size number of acked packets, up to a possible maximum
equal to the configured maximum window.
- For each non-duplicate NACK received, we drop back to fast recovery
mode, by setting the both the slow start threshold to and the
congestion window to (current_congestion_window / 2).
- If the timeout handler finds that the transmit queue has not moved
since the previous timeout, it drops the link back to slow start
and forces a probe containing the last sent sequence number to the
sent to the peer, so that this can discover the stale situation.
This change does in reality have effect only on unicast ethernet
transport, as we have seen that there is no room whatsoever for
increasing the window max size for the UDP bearer.
For now, we also choose to keep the limits for the broadcast link
unchanged and equal.
This algorithm seems to give a 50-100% throughput improvement for
messages larger than MTU.
Suggested-by: Xin Long <lucien.xin@gmail.com>
Acked-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-12-09 23:52:46 +00:00
|
|
|
BCLINK_WIN_DEFAULT,
|
2015-10-22 12:51:40 +00:00
|
|
|
0,
|
2015-10-22 12:51:37 +00:00
|
|
|
&bb->inputq,
|
2015-10-22 12:51:48 +00:00
|
|
|
NULL,
|
2015-10-22 12:51:41 +00:00
|
|
|
NULL,
|
2015-10-22 12:51:37 +00:00
|
|
|
&l))
|
|
|
|
goto enomem;
|
|
|
|
bb->link = l;
|
|
|
|
tn->bcl = l;
|
tipc: support broadcast/replicast configurable for bc-link
Currently, a multicast stream uses either broadcast or replicast as
transmission method, based on the ratio between number of actual
destinations nodes and cluster size.
However, when an L2 interface (e.g., VXLAN) provides pseudo
broadcast support, this becomes very inefficient, as it blindly
replicates multicast packets to all cluster/subnet nodes,
irrespective of whether they host actual target sockets or not.
The TIPC multicast algorithm is able to distinguish real destination
nodes from other nodes, and hence provides a smarter and more
efficient method for transferring multicast messages than
pseudo broadcast can do.
Because of this, we now make it possible for users to force
the broadcast link to permanently switch to using replicast,
irrespective of which capabilities the bearer provides,
or pretend to provide.
Conversely, we also make it possible to force the broadcast link
to always use true broadcast. While maybe less useful in
deployed systems, this may at least be useful for testing the
broadcast algorithm in small clusters.
We retain the current AUTOSELECT ability, i.e., to let the broadcast link
automatically select which algorithm to use, and to switch back and forth
between broadcast and replicast as the ratio between destination
node number and cluster size changes. This remains the default method.
Furthermore, we make it possible to configure the threshold ratio for
such switches. The default ratio is now set to 10%, down from 25% in the
earlier implementation.
Acked-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: Hoang Le <hoang.h.le@dektech.com.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-03-19 11:49:48 +00:00
|
|
|
bb->rc_ratio = 10;
|
2017-01-18 18:50:53 +00:00
|
|
|
bb->rcast_support = true;
|
2014-05-05 00:56:16 +00:00
|
|
|
return 0;
|
2015-10-22 12:51:37 +00:00
|
|
|
enomem:
|
|
|
|
kfree(bb);
|
|
|
|
kfree(l);
|
|
|
|
return -ENOMEM;
|
2006-01-02 18:04:38 +00:00
|
|
|
}
|
|
|
|
|
2015-10-22 12:51:33 +00:00
|
|
|
void tipc_bcast_stop(struct net *net)
|
2006-01-02 18:04:38 +00:00
|
|
|
{
|
2015-01-09 07:27:06 +00:00
|
|
|
struct tipc_net *tn = net_generic(net, tipc_net_id);
|
|
|
|
|
2014-05-05 00:56:16 +00:00
|
|
|
synchronize_net();
|
2015-10-22 12:51:33 +00:00
|
|
|
kfree(tn->bcbase);
|
2015-10-22 12:51:37 +00:00
|
|
|
kfree(tn->bcl);
|
2006-01-02 18:04:38 +00:00
|
|
|
}
|
2017-01-18 18:50:51 +00:00
|
|
|
|
|
|
|
void tipc_nlist_init(struct tipc_nlist *nl, u32 self)
|
|
|
|
{
|
|
|
|
memset(nl, 0, sizeof(*nl));
|
|
|
|
INIT_LIST_HEAD(&nl->list);
|
|
|
|
nl->self = self;
|
|
|
|
}
|
|
|
|
|
|
|
|
void tipc_nlist_add(struct tipc_nlist *nl, u32 node)
|
|
|
|
{
|
|
|
|
if (node == nl->self)
|
|
|
|
nl->local = true;
|
2017-10-13 09:04:22 +00:00
|
|
|
else if (tipc_dest_push(&nl->list, node, 0))
|
2017-01-18 18:50:51 +00:00
|
|
|
nl->remote++;
|
|
|
|
}
|
|
|
|
|
|
|
|
void tipc_nlist_del(struct tipc_nlist *nl, u32 node)
|
|
|
|
{
|
|
|
|
if (node == nl->self)
|
|
|
|
nl->local = false;
|
2017-10-13 09:04:22 +00:00
|
|
|
else if (tipc_dest_del(&nl->list, node, 0))
|
2017-01-18 18:50:51 +00:00
|
|
|
nl->remote--;
|
|
|
|
}
|
|
|
|
|
|
|
|
void tipc_nlist_purge(struct tipc_nlist *nl)
|
|
|
|
{
|
2017-10-13 09:04:22 +00:00
|
|
|
tipc_dest_list_purge(&nl->list);
|
2017-01-18 18:50:51 +00:00
|
|
|
nl->remote = 0;
|
2018-03-05 21:56:14 +00:00
|
|
|
nl->local = false;
|
2017-01-18 18:50:51 +00:00
|
|
|
}
|
tipc: support broadcast/replicast configurable for bc-link
Currently, a multicast stream uses either broadcast or replicast as
transmission method, based on the ratio between number of actual
destinations nodes and cluster size.
However, when an L2 interface (e.g., VXLAN) provides pseudo
broadcast support, this becomes very inefficient, as it blindly
replicates multicast packets to all cluster/subnet nodes,
irrespective of whether they host actual target sockets or not.
The TIPC multicast algorithm is able to distinguish real destination
nodes from other nodes, and hence provides a smarter and more
efficient method for transferring multicast messages than
pseudo broadcast can do.
Because of this, we now make it possible for users to force
the broadcast link to permanently switch to using replicast,
irrespective of which capabilities the bearer provides,
or pretend to provide.
Conversely, we also make it possible to force the broadcast link
to always use true broadcast. While maybe less useful in
deployed systems, this may at least be useful for testing the
broadcast algorithm in small clusters.
We retain the current AUTOSELECT ability, i.e., to let the broadcast link
automatically select which algorithm to use, and to switch back and forth
between broadcast and replicast as the ratio between destination
node number and cluster size changes. This remains the default method.
Furthermore, we make it possible to configure the threshold ratio for
such switches. The default ratio is now set to 10%, down from 25% in the
earlier implementation.
Acked-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: Hoang Le <hoang.h.le@dektech.com.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-03-19 11:49:48 +00:00
|
|
|
|
tipc: update a binding service via broadcast
Currently, updating binding table (add service binding to
name table/withdraw a service binding) is being sent over replicast.
However, if we are scaling up clusters to > 100 nodes/containers this
method is less affection because of looping through nodes in a cluster one
by one.
It is worth to use broadcast to update a binding service. This way, the
binding table can be updated on all peer nodes in one shot.
Broadcast is used when all peer nodes, as indicated by a new capability
flag TIPC_NAMED_BCAST, support reception of this message type.
Four problems need to be considered when introducing this feature.
1) When establishing a link to a new peer node we still update this by a
unicast 'bulk' update. This may lead to race conditions, where a later
broadcast publication/withdrawal bypass the 'bulk', resulting in
disordered publications, or even that a withdrawal may arrive before the
corresponding publication. We solve this by adding an 'is_last_bulk' bit
in the last bulk messages so that it can be distinguished from all other
messages. Only when this message has arrived do we open up for reception
of broadcast publications/withdrawals.
2) When a first legacy node is added to the cluster all distribution
will switch over to use the legacy 'replicast' method, while the
opposite happens when the last legacy node leaves the cluster. This
entails another risk of message disordering that has to be handled. We
solve this by adding a sequence number to the broadcast/replicast
messages, so that disordering can be discovered and corrected. Note
however that we don't need to consider potential message loss or
duplication at this protocol level.
3) Bulk messages don't contain any sequence numbers, and will always
arrive in order. Hence we must exempt those from the sequence number
control and deliver them unconditionally. We solve this by adding a new
'is_bulk' bit in those messages so that they can be recognized.
4) Legacy messages, which don't contain any new bits or sequence
numbers, but neither can arrive out of order, also need to be exempt
from the initial synchronization and sequence number check, and
delivered unconditionally. Therefore, we add another 'is_not_legacy' bit
to all new messages so that those can be distinguished from legacy
messages and the latter delivered directly.
v1->v2:
- fix warning issue reported by kbuild test robot <lkp@intel.com>
- add santiy check to drop the publication message with a sequence
number that is lower than the agreed synch point
Signed-off-by: kernel test robot <lkp@intel.com>
Signed-off-by: Hoang Huu Le <hoang.h.le@dektech.com.au>
Acked-by: Jon Maloy <jmaloy@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2020-06-17 06:56:05 +00:00
|
|
|
u32 tipc_bcast_get_mode(struct net *net)
|
tipc: support broadcast/replicast configurable for bc-link
Currently, a multicast stream uses either broadcast or replicast as
transmission method, based on the ratio between number of actual
destinations nodes and cluster size.
However, when an L2 interface (e.g., VXLAN) provides pseudo
broadcast support, this becomes very inefficient, as it blindly
replicates multicast packets to all cluster/subnet nodes,
irrespective of whether they host actual target sockets or not.
The TIPC multicast algorithm is able to distinguish real destination
nodes from other nodes, and hence provides a smarter and more
efficient method for transferring multicast messages than
pseudo broadcast can do.
Because of this, we now make it possible for users to force
the broadcast link to permanently switch to using replicast,
irrespective of which capabilities the bearer provides,
or pretend to provide.
Conversely, we also make it possible to force the broadcast link
to always use true broadcast. While maybe less useful in
deployed systems, this may at least be useful for testing the
broadcast algorithm in small clusters.
We retain the current AUTOSELECT ability, i.e., to let the broadcast link
automatically select which algorithm to use, and to switch back and forth
between broadcast and replicast as the ratio between destination
node number and cluster size changes. This remains the default method.
Furthermore, we make it possible to configure the threshold ratio for
such switches. The default ratio is now set to 10%, down from 25% in the
earlier implementation.
Acked-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: Hoang Le <hoang.h.le@dektech.com.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-03-19 11:49:48 +00:00
|
|
|
{
|
|
|
|
struct tipc_bc_base *bb = tipc_bc_base(net);
|
|
|
|
|
|
|
|
if (bb->force_bcast)
|
|
|
|
return BCLINK_MODE_BCAST;
|
|
|
|
|
|
|
|
if (bb->force_rcast)
|
|
|
|
return BCLINK_MODE_RCAST;
|
|
|
|
|
|
|
|
if (bb->bcast_support && bb->rcast_support)
|
|
|
|
return BCLINK_MODE_SEL;
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
u32 tipc_bcast_get_broadcast_ratio(struct net *net)
|
|
|
|
{
|
|
|
|
struct tipc_bc_base *bb = tipc_bc_base(net);
|
|
|
|
|
|
|
|
return bb->rc_ratio;
|
|
|
|
}
|
tipc: smooth change between replicast and broadcast
Currently, a multicast stream may start out using replicast, because
there are few destinations, and then it should ideally switch to
L2/broadcast IGMP/multicast when the number of destinations grows beyond
a certain limit. The opposite should happen when the number decreases
below the limit.
To eliminate the risk of message reordering caused by method change,
a sending socket must stick to a previously selected method until it
enters an idle period of 5 seconds. Means there is a 5 seconds pause
in the traffic from the sender socket.
If the sender never makes such a pause, the method will never change,
and transmission may become very inefficient as the cluster grows.
With this commit, we allow such a switch between replicast and
broadcast without any need for a traffic pause.
Solution is to send a dummy message with only the header, also with
the SYN bit set, via broadcast or replicast. For the data message,
the SYN bit is set and sending via replicast or broadcast (inverse
method with dummy).
Then, at receiving side any messages follow first SYN bit message
(data or dummy message), they will be held in deferred queue until
another pair (dummy or data message) arrived in other link.
v2: reverse christmas tree declaration
Acked-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: Hoang Le <hoang.h.le@dektech.com.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-03-19 11:49:50 +00:00
|
|
|
|
2019-03-21 10:25:18 +00:00
|
|
|
void tipc_mcast_filter_msg(struct net *net, struct sk_buff_head *defq,
|
tipc: smooth change between replicast and broadcast
Currently, a multicast stream may start out using replicast, because
there are few destinations, and then it should ideally switch to
L2/broadcast IGMP/multicast when the number of destinations grows beyond
a certain limit. The opposite should happen when the number decreases
below the limit.
To eliminate the risk of message reordering caused by method change,
a sending socket must stick to a previously selected method until it
enters an idle period of 5 seconds. Means there is a 5 seconds pause
in the traffic from the sender socket.
If the sender never makes such a pause, the method will never change,
and transmission may become very inefficient as the cluster grows.
With this commit, we allow such a switch between replicast and
broadcast without any need for a traffic pause.
Solution is to send a dummy message with only the header, also with
the SYN bit set, via broadcast or replicast. For the data message,
the SYN bit is set and sending via replicast or broadcast (inverse
method with dummy).
Then, at receiving side any messages follow first SYN bit message
(data or dummy message), they will be held in deferred queue until
another pair (dummy or data message) arrived in other link.
v2: reverse christmas tree declaration
Acked-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: Hoang Le <hoang.h.le@dektech.com.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-03-19 11:49:50 +00:00
|
|
|
struct sk_buff_head *inputq)
|
|
|
|
{
|
|
|
|
struct sk_buff *skb, *_skb, *tmp;
|
|
|
|
struct tipc_msg *hdr, *_hdr;
|
|
|
|
bool match = false;
|
|
|
|
u32 node, port;
|
|
|
|
|
|
|
|
skb = skb_peek(inputq);
|
2019-04-03 06:05:04 +00:00
|
|
|
if (!skb)
|
|
|
|
return;
|
|
|
|
|
tipc: smooth change between replicast and broadcast
Currently, a multicast stream may start out using replicast, because
there are few destinations, and then it should ideally switch to
L2/broadcast IGMP/multicast when the number of destinations grows beyond
a certain limit. The opposite should happen when the number decreases
below the limit.
To eliminate the risk of message reordering caused by method change,
a sending socket must stick to a previously selected method until it
enters an idle period of 5 seconds. Means there is a 5 seconds pause
in the traffic from the sender socket.
If the sender never makes such a pause, the method will never change,
and transmission may become very inefficient as the cluster grows.
With this commit, we allow such a switch between replicast and
broadcast without any need for a traffic pause.
Solution is to send a dummy message with only the header, also with
the SYN bit set, via broadcast or replicast. For the data message,
the SYN bit is set and sending via replicast or broadcast (inverse
method with dummy).
Then, at receiving side any messages follow first SYN bit message
(data or dummy message), they will be held in deferred queue until
another pair (dummy or data message) arrived in other link.
v2: reverse christmas tree declaration
Acked-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: Hoang Le <hoang.h.le@dektech.com.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-03-19 11:49:50 +00:00
|
|
|
hdr = buf_msg(skb);
|
|
|
|
|
|
|
|
if (likely(!msg_is_syn(hdr) && skb_queue_empty(defq)))
|
|
|
|
return;
|
|
|
|
|
|
|
|
node = msg_orignode(hdr);
|
2019-03-21 10:25:18 +00:00
|
|
|
if (node == tipc_own_addr(net))
|
|
|
|
return;
|
|
|
|
|
tipc: smooth change between replicast and broadcast
Currently, a multicast stream may start out using replicast, because
there are few destinations, and then it should ideally switch to
L2/broadcast IGMP/multicast when the number of destinations grows beyond
a certain limit. The opposite should happen when the number decreases
below the limit.
To eliminate the risk of message reordering caused by method change,
a sending socket must stick to a previously selected method until it
enters an idle period of 5 seconds. Means there is a 5 seconds pause
in the traffic from the sender socket.
If the sender never makes such a pause, the method will never change,
and transmission may become very inefficient as the cluster grows.
With this commit, we allow such a switch between replicast and
broadcast without any need for a traffic pause.
Solution is to send a dummy message with only the header, also with
the SYN bit set, via broadcast or replicast. For the data message,
the SYN bit is set and sending via replicast or broadcast (inverse
method with dummy).
Then, at receiving side any messages follow first SYN bit message
(data or dummy message), they will be held in deferred queue until
another pair (dummy or data message) arrived in other link.
v2: reverse christmas tree declaration
Acked-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: Hoang Le <hoang.h.le@dektech.com.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-03-19 11:49:50 +00:00
|
|
|
port = msg_origport(hdr);
|
|
|
|
|
|
|
|
/* Has the twin SYN message already arrived ? */
|
|
|
|
skb_queue_walk(defq, _skb) {
|
|
|
|
_hdr = buf_msg(_skb);
|
|
|
|
if (msg_orignode(_hdr) != node)
|
|
|
|
continue;
|
|
|
|
if (msg_origport(_hdr) != port)
|
|
|
|
continue;
|
|
|
|
match = true;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!match) {
|
|
|
|
if (!msg_is_syn(hdr))
|
|
|
|
return;
|
|
|
|
__skb_dequeue(inputq);
|
|
|
|
__skb_queue_tail(defq, skb);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Deliver non-SYN message from other link, otherwise queue it */
|
|
|
|
if (!msg_is_syn(hdr)) {
|
|
|
|
if (msg_is_rcast(hdr) != msg_is_rcast(_hdr))
|
|
|
|
return;
|
|
|
|
__skb_dequeue(inputq);
|
|
|
|
__skb_queue_tail(defq, skb);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Queue non-SYN/SYN message from same link */
|
|
|
|
if (msg_is_rcast(hdr) == msg_is_rcast(_hdr)) {
|
|
|
|
__skb_dequeue(inputq);
|
|
|
|
__skb_queue_tail(defq, skb);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Matching SYN messages => return the one with data, if any */
|
|
|
|
__skb_unlink(_skb, defq);
|
|
|
|
if (msg_data_sz(hdr)) {
|
|
|
|
kfree_skb(_skb);
|
|
|
|
} else {
|
|
|
|
__skb_dequeue(inputq);
|
|
|
|
kfree_skb(skb);
|
|
|
|
__skb_queue_tail(inputq, _skb);
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Deliver subsequent non-SYN messages from same peer */
|
|
|
|
skb_queue_walk_safe(defq, _skb, tmp) {
|
|
|
|
_hdr = buf_msg(_skb);
|
|
|
|
if (msg_orignode(_hdr) != node)
|
|
|
|
continue;
|
|
|
|
if (msg_origport(_hdr) != port)
|
|
|
|
continue;
|
|
|
|
if (msg_is_syn(_hdr))
|
|
|
|
break;
|
|
|
|
__skb_unlink(_skb, defq);
|
|
|
|
__skb_queue_tail(inputq, _skb);
|
|
|
|
}
|
|
|
|
}
|