netdev - Re: [net-next v3 1/3] tipc: support broadcast/replicast configurable for bc-link

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20190319.135629.491653528810201574.davem@davemloft.net>
Date:   Tue, 19 Mar 2019 13:56:29 -0700 (PDT)
From:   David Miller <davem@...emloft.net>
To:     hoang.h.le@...tech.com.au
Cc:     tipc-discussion@...ts.sourceforge.net, jon.maloy@...csson.com,
        maloy@...jonn.com, ying.xue@...driver.com, netdev@...r.kernel.org
Subject: Re: [net-next v3 1/3] tipc: support broadcast/replicast
 configurable for bc-link

From: Hoang Le <hoang.h.le@...tech.com.au>
Date: Tue, 19 Mar 2019 18:49:48 +0700

> 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@...csson.com>
> Signed-off-by: Hoang Le <hoang.h.le@...tech.com.au>

Applied.