2006-01-02 18:04:38 +00:00
|
|
|
/*
|
|
|
|
|
* net/tipc/bcast.h: Include file for TIPC broadcast code
|
2007-02-09 14:25:21 +00:00
|
|
|
*
|
2015-02-05 13:36:43 +00:00
|
|
|
* Copyright (c) 2003-2006, 2014-2015, Ericsson AB
|
2011-01-18 18:53:16 +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.
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
#ifndef _TIPC_BCAST_H
|
|
|
|
|
#define _TIPC_BCAST_H
|
|
|
|
|
|
2015-10-22 12:51:33 +00:00
|
|
|
#include "core.h"
|
2015-01-09 07:27:07 +00:00
|
|
|
|
|
|
|
|
struct tipc_node;
|
2015-10-22 12:51:33 +00:00
|
|
|
struct tipc_msg;
|
|
|
|
|
struct tipc_nl_msg;
|
2017-01-18 18:50:51 +00:00
|
|
|
struct tipc_nlist;
|
|
|
|
|
struct tipc_nitem;
|
2015-11-19 19:30:45 +00:00
|
|
|
extern const char tipc_bclink_name[];
|
2020-05-26 09:38:36 +00:00
|
|
|
extern unsigned long sysctl_tipc_bc_retruni;
|
2006-01-02 18:04:38 +00:00
|
|
|
|
2017-01-18 18:50:53 +00:00
|
|
|
#define TIPC_METHOD_EXPIRE msecs_to_jiffies(5000)
|
|
|
|
|
|
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
|
|
|
#define BCLINK_MODE_BCAST 0x1
|
|
|
|
|
#define BCLINK_MODE_RCAST 0x2
|
|
|
|
|
#define BCLINK_MODE_SEL 0x4
|
|
|
|
|
|
2017-01-18 18:50:51 +00:00
|
|
|
struct tipc_nlist {
|
|
|
|
|
struct list_head list;
|
|
|
|
|
u32 self;
|
|
|
|
|
u16 remote;
|
|
|
|
|
bool local;
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
void tipc_nlist_init(struct tipc_nlist *nl, u32 self);
|
|
|
|
|
void tipc_nlist_purge(struct tipc_nlist *nl);
|
|
|
|
|
void tipc_nlist_add(struct tipc_nlist *nl, u32 node);
|
|
|
|
|
void tipc_nlist_del(struct tipc_nlist *nl, u32 node);
|
|
|
|
|
|
2017-01-18 18:50:53 +00:00
|
|
|
/* Cookie to be used between socket and broadcast layer
|
|
|
|
|
* @rcast: replicast (instead of broadcast) was used at previous xmit
|
|
|
|
|
* @mandatory: broadcast/replicast indication was set by user
|
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
|
|
|
* @deferredq: defer queue to make message in order
|
2017-01-18 18:50:53 +00:00
|
|
|
* @expires: re-evaluate non-mandatory transmit method if we are past this
|
|
|
|
|
*/
|
|
|
|
|
struct tipc_mc_method {
|
|
|
|
|
bool rcast;
|
|
|
|
|
bool mandatory;
|
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 deferredq;
|
2017-01-18 18:50:53 +00:00
|
|
|
unsigned long expires;
|
|
|
|
|
};
|
|
|
|
|
|
2015-10-22 12:51:33 +00:00
|
|
|
int tipc_bcast_init(struct net *net);
|
|
|
|
|
void tipc_bcast_stop(struct net *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
|
|
|
void tipc_bcast_add_peer(struct net *net, struct tipc_link *l,
|
2015-10-22 12:51:41 +00:00
|
|
|
struct sk_buff_head *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
|
|
|
void tipc_bcast_remove_peer(struct net *net, struct tipc_link *rcv_bcl);
|
|
|
|
|
void tipc_bcast_inc_bearer_dst_cnt(struct net *net, int bearer_id);
|
|
|
|
|
void tipc_bcast_dec_bearer_dst_cnt(struct net *net, int bearer_id);
|
2015-10-22 12:51:43 +00:00
|
|
|
int tipc_bcast_get_mtu(struct net *net);
|
2019-11-21 03:01:09 +00:00
|
|
|
void tipc_bcast_toggle_rcast(struct net *net, bool supp);
|
2017-01-18 18:50:52 +00:00
|
|
|
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);
|
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);
|
2015-10-22 12:51:41 +00:00
|
|
|
int tipc_bcast_rcv(struct net *net, struct tipc_link *l, struct sk_buff *skb);
|
2016-10-27 22:51:55 +00:00
|
|
|
void tipc_bcast_ack_rcv(struct net *net, struct tipc_link *l,
|
|
|
|
|
struct tipc_msg *hdr);
|
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);
|
2020-05-26 09:38:37 +00:00
|
|
|
int tipc_nl_add_bc_link(struct net *net, struct tipc_nl_msg *msg,
|
|
|
|
|
struct tipc_link *bcl);
|
2015-05-06 11:58:55 +00:00
|
|
|
int tipc_nl_bc_link_set(struct net *net, struct nlattr *attrs[]);
|
2020-05-26 09:38:37 +00:00
|
|
|
int tipc_bclink_reset_stats(struct net *net, struct tipc_link *l);
|
2014-11-20 09:29:12 +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
|
|
|
u32 tipc_bcast_get_broadcast_ratio(struct net *net);
|
|
|
|
|
|
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);
|
|
|
|
|
|
2015-10-22 12:51:34 +00:00
|
|
|
static inline void tipc_bcast_lock(struct net *net)
|
|
|
|
|
{
|
|
|
|
|
spin_lock_bh(&tipc_net(net)->bclock);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static inline void tipc_bcast_unlock(struct net *net)
|
|
|
|
|
{
|
|
|
|
|
spin_unlock_bh(&tipc_net(net)->bclock);
|
|
|
|
|
}
|
|
|
|
|
|
2015-10-22 12:51:41 +00:00
|
|
|
static inline struct tipc_link *tipc_bc_sndlink(struct net *net)
|
|
|
|
|
{
|
|
|
|
|
return tipc_net(net)->bcl;
|
|
|
|
|
}
|
|
|
|
|
|
2006-01-02 18:04:38 +00:00
|
|
|
#endif
|
