> -Original Message-
> From: Xue, Ying [mailto:ying@windriver.com]
> Sent: Sunday, 01 May, 2016 05:52
> To: Jon Maloy; tipc-discussion@lists.sourceforge.net; Parthasarathy
> Bhuvaragan;
> Richard Alpe
> Cc: ma...@donjonn.com
> Subject: RE: [PATCH net-
The socket-level flow control in TIPC has long been due for a major
overhaul. This series fixes this.
Jon Maloy (3):
tipc: re-enable compensation for socket receive buffer double counting
tipc: propagate peer node capabilities to socket layer
tipc: redesign connection-level flow control
adds this functionality.
Acked-by: Ying Xue
Signed-off-by: Jon Maloy
---
net/tipc/node.c | 21 +++--
net/tipc/node.h | 1 +
net/tipc/socket.c | 2 ++
3 files changed, 22 insertions(+), 2 deletions(-)
diff --git a/net/tipc/node.c b/net/tipc/node.c
index c299156..29cc853
In order to keep this solution backwards compatible, we introduce a
new capability bit in the discovery protocol, and use this throughout
the message sending/reception path to always select the right unit.
Acked-by: Ying Xue
Signed-off-by: Jon Maloy
---
net/tipc/core.c | 8 ++--
net/
becomes indispensable when we reduce this buffer limit
later in this series.
We now fix this by inverting the mentioned condition.
Acked-by: Ying Xue
Signed-off-by: Jon Maloy
---
net/tipc/socket.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/tipc/socket.c b/net/tipc/s
adds this functionality.
Acked-by: Ying Xue
Signed-off-by: Jon Maloy
---
net/tipc/node.c | 21 +++--
net/tipc/node.h | 1 +
net/tipc/socket.c | 2 ++
3 files changed, 22 insertions(+), 2 deletions(-)
diff --git a/net/tipc/node.c b/net/tipc/node.c
index c299156..29cc853
The socket-level flow control in TIPC has long been due for a major
overhaul. This series fixes this.
Jon Maloy (3):
tipc: re-enable compensation for socket receive buffer double counting
tipc: propagate peer node capabilities to socket layer
tipc: redesign connection-level flow control
In order to keep this solution backwards compatible, we introduce a
new capability bit in the discovery protocol, and use this throughout
the message sending/reception path to always select the right unit.
Acked-by: Ying Xue
Signed-off-by: Jon Maloy
---
net/tipc/core.c | 8 ++--
net/
becomes indispensable when we reduce this buffer limit
later in this series.
We now fix this by inverting the mentioned condition.
Acked-by: Ying Xue
Signed-off-by: Jon Maloy
---
net/tipc/socket.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/tipc/socket.c b/net/tipc/s
See below. The fix has been released in Ubuntu Xenial 16.04.
///jon
-Original Message-
From: boun...@canonical.com [mailto:boun...@canonical.com] On Behalf Of Kamal
Mostafa
Sent: Friday, 06 May, 2016 16:52
To: Jon Maloy
Subject: [Bug 1567064] Re: tipc: missing linearization of sk_buff
build_proto_msg(), so that we send only
the actual size of the domain record, and nothing more.
- Moved skb_linearize() in link_proto_rcv() so that it now covers
all received messages. I found out the hard way that this is
necessary
Signed-off-by: Jon Maloy
---
net/tipc/Makefile
t parts of it and added it as a commit #2.
I think that the function for displaying the monitor table might be
of particular interest to Partha.
Jon Maloy (2):
tipc: add neighbor monitoring framework
tipc: debugging_tracing_profiling support for neighbor monitoring code
net/tipc/Makefil
monitoring:
- Beyond 10 nodes tracing printouts should be enabled for only one node.
- Beyond 30 nodes tracing printouts should be disabled, and periodical
statistics and monitor printouts made for only one node.
Signed-off-by: Jon Maloy
---
net/tipc/addr.c | 1 +
net/tipc/bearer.c | 1
Attached examples of a monitor table listing and a profiling/statistics
listing as they will look if patch #2 is applied.
///jon
On 05/10/2016 02:43 AM, Jon Maloy wrote:
I made some updates to commit #1, notably by removing the "head map", which
I think we all regarded a potential
On 05/10/2016 04:22 PM, Erik Hugne wrote:
> Problem was that the test system didn't have a TIPC address configured, but
> this is assumed to always be done in the name resolve function
I believe you are talking by the name resolution function in TIPC here?
There is no such assumption.
A (non)-c
On 05/11/2016 05:03 AM, Parthasarathy Bhuvaragan wrote:
>
> On 05/10/2016 08:43 AM, Jon Maloy wrote:
>> TIPC based clusters are by default set up with full-mesh link
>> connectivity between all nodes. Those links are expected to provide
>> a short failure detection time
On 05/11/2016 10:05 AM, Erik Hugne wrote:
>
>
> On May 11, 2016 14:34, "Jon Maloy" <mailto:ma...@donjonn.com>> wrote:
> >
> >
> >
> > On 05/10/2016 04:22 PM, Erik Hugne wrote:
> > > Problem was that the test system didn't have a
confusion.
This commit eliminates this risk by checking if the link is already
up before proceeding with the second half of the setup.
Signed-off-by: Jon Maloy
---
net/tipc/node.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/tipc/node.c b/net/tipc/node.c
index d903f56
tion.
Signed-off-by: Jon Maloy
---
net/tipc/link.c | 2 --
net/tipc/node.c | 18 ++
2 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/net/tipc/link.c b/net/tipc/link.c
index 7059c94..a904ccd 100644
--- a/net/tipc/link.c
+++ b/net/tipc/link.c
@@ -87,7 +87,6
oth according to
comments from Partha and own improvements.
- Introduced new flag 'check_gen' in struct mon_state to fixe a
problem with reception of domain records: when a peer has just
come up, it must accept any domain generation, without checking
if it is
micoseconds to this interval for each new neighbor This means
that e.g., the 500'th node will not be accepted until 10 ms after the
previous one was. This seems to be sufficient to solve the problem with
cluster startup overload, while adding only a few seconds to the overall
cluster establishment
look pretty stable now, but we should still to wait until the
next cycle with this one.
- Separated out the discovery rate control as commit #3. Still
a little uncertain about this one.
- More measuring points in the profiling commit (#4)
Jon Maloy (4):
tipc: change node
disovery rate control as commit #3.
- More measuring points in the profiling commit (#4)
Jon Maloy (4):
tipc: change node timer unit from jiffies to ms
tipc: add neighbor monitoring framework
tipc: rate control acceptance of new neighbor nodes
tipc: debugging_tracing_profiling support for
monitoring:
- Beyond 10 nodes tracing printouts should be enabled for only one node.
- Beyond 30 nodes tracing printouts should be disabled, and periodical
statistics and monitor printouts made for only one node.
Signed-off-by: Jon Maloy
---
net/tipc/addr.c| 1 +
net/tipc/bearer.c
ntation.
Signed-off-by: Jon Maloy
---
net/tipc/link.c | 2 --
net/tipc/node.c | 18 ++
2 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/net/tipc/link.c b/net/tipc/link.c
index 7059c94..a904ccd 100644
--- a/net/tipc/link.c
+++ b/net/tipc/link.c
@@ -87,7 +87,6
, but Iam
> unable to verify the above.
>
> regards
> Partha
> ________
> From: Jon Maloy [jon.ma...@ericsson.com]
> Sent: 14 May 2016 02:07
> To: tipc-discussion@lists.sourceforge.net; Parthasarathy Bhuvaragan; Ying
> Xue; Richard Alpe;
Acked-by: jon
Send tis to net, since it is a bug correction.
///jon
> -Original Message-
> From: Richard Alpe
> Sent: Monday, 16 May, 2016 09:50
> To: tipc-discussion@lists.sourceforge.net
> Cc: Jon Maloy; Richard Alpe
> Subject: [PATCH net-next] tipc: fix nametable pu
This is a serious bug, so it should be posted to net, not net-next.
Otherwise,
Acked-by: Jon Maloy
///jon
> -Original Message-
> From: Richard Alpe [mailto:richard.a...@ericsson.com]
> Sent: Monday, 16 May, 2016 05:15
> To: net...@vger.kernel.org
> Cc: splovi...@
+--->| SELF_DOWN_ |<---+ SELF_DOWN_EVT|
+--->| PEER_DOWN |<+
+--+
Signed-off-by: Jon Maloy
---
net/tipc/node.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/tipc/node.
ntation.
Signed-off-by: Jon Maloy
---
net/tipc/link.c | 2 --
net/tipc/node.c | 18 ++
2 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/net/tipc/link.c b/net/tipc/link.c
index 7059c94..a904ccd 100644
--- a/net/tipc/link.c
+++ b/net/tipc/link.c
@@ -87,7 +87,6
distribution to the monitor timer interval. The
interval will now be spread across the interval 2-3 minutes.
- Only consider tic_peer->down_cnt's value when the peer is not in
the local domain. I.e., loss of a local peer must always be
confirmed by direct probing. This elim
some time.
- Updated #3 (v6/#2), see its commit log.
- Removed v6/#3 as it doesn't seem to make any difference.
- Finally got the "monitored links" counter in #4 right, plus more.
Jon Maloy (4):
tipc: correct error in node fsm
tipc: change node timer unit from jiffi
monitoring:
- Beyond 10 nodes tracing printouts should be enabled for only one node.
- Beyond 30 nodes tracing printouts should be disabled, and periodical
statistics and monitor printouts made for only one node.
Signed-off-by: Jon Maloy
---
net/tipc/addr.c| 1 +
net/tipc/bearer.c
> -Original Message-
> From: GUNA [mailto:gbala...@gmail.com]
> Sent: Friday, 20 May, 2016 11:04
> To: Erik Hugne
> Cc: Richard Alpe; Ying Xue; Parthasarathy Bhuvaragan; Jon Maloy; tipc-
> discuss...@lists.sourceforge.net
> Subject: Re: [tipc-discussion] tipc_sk_rcv
On 05/24/2016 12:16 PM, GUNA wrote:
> I suspect there could be glitch on switch may cause lost the probe or
> abort message. However, even if the messages are lost for what ever
> reason, is not TIPC stack should handle the graceful shutdown of the
> TIPC connection by releasing all the resource
ther sw interrups (tipc_sk_rcv()) and vice versa. Or maybe not even this is
enough?
I will continue my analysis, but input from others would be appreciated.
///jon
> -Original Message-
> From: GUNA [mailto:gbala...@gmail.com]
> Sent: Saturday, 28 May, 2016 06:00
> To: Jon Ma
From: Erik Hugne [mailto:erik.hu...@gmail.com]
Sent: Monday, 30 May, 2016 07:08
To: Jon Maloy
Cc: Jon Maloy; Ying Xue; GUNA; Xue Ying (ying.x...@gmail.com);
tipc-discussion@lists.sourceforge.net
Subject: RE: [tipc-discussion] tipc_sk_rcv: Kernel panic on one of the card on
4.4.0
oops, hit
> -Original Message-
> From: Xue, Ying [mailto:ying@windriver.com]
> Sent: Monday, 30 May, 2016 14:15
> To: Jon Maloy; GUNA; Jon Maloy; tipc-discussion@lists.sourceforge.net; Erik
> Hugne; Xue Ying (ying.x...@gmail.com)
> Subject: RE: [tipc-discussion] tipc_sk_rc
> -Original Message-
> From: GUNA [mailto:gbala...@gmail.com]
> Sent: Wednesday, 01 June, 2016 19:52
> To: tipc-discussion@lists.sourceforge.net
> Subject: [tipc-discussion] tipc: name table entry is not matched
>
> I am running on Kernel 4.4.0 and do see table Name table mismatch as
> p
From: Erik Hugne [mailto:erik.hu...@gmail.com]
Sent: Thursday, 02 June, 2016 14:11
To: Ying Xue
Cc: Richard Alpe; Parthasarathy Bhuvaragan; Jon Maloy;
tipc-discussion@lists.sourceforge.net
Subject: RE: [RFC PATCH] tipc: fix timer handling when socket is owned
On Jun 2, 2016 1:03 PM, &quo
> -Original Message-
> From: Xue, Ying [mailto:ying@windriver.com]
> Sent: Saturday, 04 June, 2016 10:12
> To: Jon Maloy; Erik Hugne
> Cc: Richard Alpe; Parthasarathy Bhuvaragan; tipc-
> discuss...@lists.sourceforge.net
> Subject: RE: [RFC PATCH] tipc: fix timer
Acked-by: me
///jon
> -Original Message-
> From: Ying Xue [mailto:ying@windriver.com]
> Sent: Tuesday, 07 June, 2016 12:12
> To: ma...@donjonn.com; erik.hu...@ericsson.com
> Cc: Jon Maloy; Ying Xue; tipc-discussion@lists.sourceforge.net
> Subject: [PATC
> -Original Message-
> From: Ying Xue [mailto:ying@windriver.com]
> Sent: Tuesday, 07 June, 2016 12:12
> To: ma...@donjonn.com; erik.hu...@ericsson.com
> Cc: Jon Maloy; Ying Xue; tipc-discussion@lists.sourceforge.net
> Subject: [PATCH] tipc: fix suspicious RCU u
David.
///jon
> -Original Message-
> From: Jon Maloy [mailto:jon.ma...@ericsson.com]
> Sent: Thursday, 19 May, 2016 20:09
> To: tipc-discussion@lists.sourceforge.net; Parthasarathy Bhuvaragan; Ying Xue;
> Richard Alpe; Jon Maloy
> Cc: ma...@donjonn.com
> Subject: [
+--->| SELF_DOWN_ |<---+ SELF_DOWN_EVT|
+--->| PEER_DOWN |<+
+--+
Acked-by: Ying Xue
Signed-off-by: Jon Maloy
---
net/tipc/node.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff
mentation.
Acked-by: Ying Xue
Signed-off-by: Jon Maloy
---
net/tipc/link.c | 2 --
net/tipc/node.c | 18 ++
2 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/net/tipc/link.c b/net/tipc/link.c
index 7059c94..a904ccd 100644
--- a/net/tipc/link.c
+++ b/net/tipc/l
We fix a couple of rarely seen anomalies discovered during testing.
Jon Maloy (2):
tipc: correct error in node fsm
tipc: change node timer unit from jiffies to ms
net/tipc/link.c | 2 --
net/tipc/node.c | 22 --
2 files changed, 12 insertions(+), 12 deletions
eliminates the risk of avalanche
link losses because of false positives.
v8: - Added missing "peer->applied = 0" in tipc_mon_remove_peer() when
monitor moves back to full-mesh monitoring. This fixes a crash
reported by Partha.
Signed-off-by: Jon Maloy
---
net/tipc/Ma
I believe this one is ready for posting now. Please ack.
///jon
> -Original Message-
> From: Jon Maloy [mailto:jon.ma...@ericsson.com]
> Sent: Wednesday, 08 June, 2016 14:54
> To: tipc-discussion@lists.sourceforge.net; Parthasarathy Bhuvaragan; Ying Xue;
> Richard Alpe;
> -Original Message-
> From: Parthasarathy Bhuvaragan
> Sent: Thursday, 02 June, 2016 10:10
> To: tipc-discussion@lists.sourceforge.net; Jon Maloy; ma...@donjonn.com; Ying
> Xue; Richard Alpe
> Subject: [PATCH iproute2 v3 09/10] tipc: add link monitor list
>
>
> -Original Message-
> From: Parthasarathy Bhuvaragan
> Sent: Thursday, 02 June, 2016 10:10
> To: tipc-discussion@lists.sourceforge.net; Jon Maloy; ma...@donjonn.com; Ying
> Xue; Richard Alpe
> Subject: [PATCH iproute2 v3 07/10] tipc: add link monitor summary
>
> -Original Message-
> From: Jon Maloy [mailto:jon.ma...@ericsson.com]
> Sent: Wednesday, 08 June, 2016 15:46
> To: Parthasarathy Bhuvaragan; tipc-discussion@lists.sourceforge.net;
> ma...@donjonn.com; Ying Xue; Richard Alpe
> Subject: Re: [tipc-discussion] [PATCH iprou
> -Original Message-
> From: Erik Hugne [mailto:erik.hu...@gmail.com]
> Sent: Wednesday, 08 June, 2016 15:39
> To: Ying Xue
> Cc: Jon Maloy; Richard Alpe; Parthasarathy Bhuvaragan; tipc-
> discuss...@lists.sourceforge.net
> Subject: Re: [RFC PATCH] tipc: fix timer ha
t lock, with ensuing risk of similar deadlocks.
We solve this by ensuring that messages created by tipc_sk_respond()
only are sent directly if sk_lock.slock is not held. Otherwise they are
queued up in the socket write queue and sent after the lock has been
released.
Reported-by: GUNA
Signed-off-b
Testing on mutex sk_lock.owned instead of sk_lock.slock in
tipc_sk_respond(). This is safer, since sk_lock.slock may
occasionally and briefly be held (by concurrent user contexts)
even if we are in user context.
Reported-by: GUNA
Signed-off-by: Jon Maloy
---
net/ti
above.
Reported-by: GUNA
Signed-off-by: Jon Maloy
---
net/tipc/socket.c | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/net/tipc/socket.c b/net/tipc/socket.c
index 88bfcd7..e8ed3a8 100644
--- a/net/tipc/socket.c
+++ b/net/tipc/socket.c
@@ -278,7 +278,11 @@ static v
On 06/13/2016 02:24 PM, Erik Hugne wrote:
> On Mon, Jun 13, 2016 at 01:51:15PM -0400, Jon Maloy wrote:
>> --- a/net/tipc/socket.c
>> +++ b/net/tipc/socket.c
>> @@ -1830,6 +1834,14 @@ void tipc_sk_rcv(struct net *net, struct sk_
e. This means that if the threshold is set to
a value larger than any anticipated cluster size (default size is 32)
the new algorithm is effectively disabled. A patch set for altering the
threshold value will follow shortly.
- This change is fully backwards compatible.
Acked-by: Ying Xue
Sign
On 06/13/2016 03:20 PM, Erik Hugne wrote:
>
>
> On Jun 13, 2016 20:29, "Jon Maloy" <mailto:ma...@donjonn.com>> wrote:
> > I already thought about that, and checked the implementation of
> > skb_dequeue(). As I suspected it unconditionally grabs the qu
rds compatible.
Acked-by: Ying Xue
Signed-off-by: Jon Maloy
---
net/tipc/Makefile | 2 +-
net/tipc/addr.h| 1 +
net/tipc/bearer.c | 8 +-
net/tipc/bearer.h | 2 +-
net/tipc/core.c| 1 +
net/tipc/core.h| 15 +-
net/tipc/link.c|
acket chain") i.e. as recent as kernel 4.5, so using
this queue would screw up older kernel versions.
- Made small cosmetic improvement to the dequeuing loop.
Reported-by: GUNA
Signed-off-by: Jon Maloy
---
net/tipc/socket.c | 14 +-
1 file changed, 13 insertions(+),
> -Original Message-
> From: Xue, Ying [mailto:ying@windriver.com]
> Sent: Tuesday, 14 June, 2016 05:46
> To: Jon Maloy; tipc-discussion@lists.sourceforge.net; Parthasarathy
> Bhuvaragan;
> Richard Alpe
> Cc: ma...@donjonn.com; gbala...@gmail.com
> Subjec
(re-)introducing a solution that I believe is the only really safe
one.
Reported-by: GUNA
Signed-off-by: Jon Maloy
---
net/tipc/socket.c | 54 ++
1 file changed, 42 insertions(+), 12 deletions(-)
diff --git a/net/tipc/socket.c b/net/
it this way.
Regards
///jon
>
> Regards,
> Ying
>
> -Original Message-
> From: Jon Maloy [mailto:jon.ma...@ericsson.com]
> Sent: Wednesday, June 15, 2016 10:46 PM
> To: tipc-discussion@lists.sourceforge.net;
> parthasarathy.bhuvara...@ericsson.com; Xue, Ying; richar
leading to unpredicatable consequences, such as a link
reset.
We now fix this by ensuring that the msg_reverse() function never
returns a cloned buffer, and that the returned buffer always contains
sufficient valid head and tail room to be forwarded.
Reported-by: Erik Hugne
Signed-off-by:
ow we are safely outside the slock
context.
Reported-by: GUNA
Acked-by: Ying Xue
Signed-off-by: Jon Maloy
---
net/tipc/socket.c | 54 ++
1 file changed, 42 insertions(+), 12 deletions(-)
diff --git a/net/tipc/socket.c b/net/tipc/socket.c
index
Acked. This will only be relevant in clusters > 1000 nodes, which I must admit
I haven't tested yet.
///jon
> -Original Message-
> From: Dan Carpenter [mailto:dan.carpen...@oracle.com]
> Sent: Friday, 17 June, 2016 05:22
> To: Jon Maloy
> Cc: Ying Xu
idn't seem to solve the
problem at my first attempt. When I removed my own debug
instrumentation everything worked fine.
Reported-by: Erik Hugne
Signed-off-by: Jon Maloy
---
net/tipc/msg.c | 6 ++
net/tipc/msg.h | 11 ---
2 files changed, 6 insertions(+), 11 deletions
ned-off-by: Jon Maloy
---
net/tipc/msg.c | 6 ++
net/tipc/msg.h | 11 ---
2 files changed, 6 insertions(+), 11 deletions(-)
diff --git a/net/tipc/msg.c b/net/tipc/msg.c
index 8740930..17201aa 100644
--- a/net/tipc/msg.c
+++ b/net/tipc/msg.c
@@ -41,6 +41,8 @@
#include "name_tabl
On 06/22/2016 11:40 AM, Erik Hugne wrote:
> This change is not backwards compatible, udp_media_addr is carried in the
> neighbor discovery messages.
>
> //E
Not sure if backwards compatibility is a big issue at this stage, but as
I remember it the 'media_id' field was meant to fulfill this role
Same for me.
Acked-by: jon
///jon
On 06/23/2016 06:23 AM, Xue, Ying wrote:
> The other two patches look good for me.
>
> Regards,
> Ying
>
> -Original Message-
> From: Richard Alpe [mailto:richard.a...@ericsson.com]
> Sent: Thursday, June 23, 2016 6:02 PM
> To: Erik Hugne
> Cc: tipc-discu
Acked-by: jon
On 06/28/2016 05:21 AM, Richard Alpe wrote:
> Split the UDP netlink parse function so that it only parses one
> netlink attribute at the time. This makes the parse function more
> generic and allow future UDP API functions to use it for parsing.
>
> Signed-off-by: Richard Alpe
> ---
On 06/28/2016 05:21 AM, Richard Alpe wrote:
> Split the UDP send function into two. One callback that prepares the
> skb and one transmit function that sends the skb. This will come in
> handy in later patches, when we introduce UDP replicast.
>
> Signed-off-by: Richard Alpe
> ---
> net/tipc/u
On 06/28/2016 05:21 AM, Richard Alpe wrote:
> This patch introduces UDP replicast. A concept where we emulate
> multicast by sending multiple unicast messages to configured peers.
>
> The purpose of replicast is mainly to be able to use TIPC in cloud
> environments where IP multicast is disabled.
On 06/28/2016 05:21 AM, Richard Alpe wrote:
> Split the UDP send function into two. One callback that prepares the
> skb and one transmit function that sends the skb. This will come in
> handy in later patches, when we introduce UDP replicast.
>
> Signed-off-by: Richard Alpe
> ---
> net/tipc/u
On 06/28/2016 05:21 AM, Richard Alpe wrote:
> Automatically learn UDP remote IP addresses of communicating peers by
> looking at the source IP address of incoming TIPC link configuration
> messages (neighbor discovery).
>
> This makes configuration slightly easier and removes the problematic
> sc
Acked-by: jon
On 06/28/2016 05:21 AM, Richard Alpe wrote:
> When using replicast a UDP bearer can have an arbitrary amount of
> remote ip addresses associated with it. This means we cannot simply
> add all remote ip addresses to an existing bearer data message as it
> might fill the message, leavi
> -Original Message-
> From: Jon Maloy [mailto:ma...@donjonn.com]
> Sent: Wednesday, 29 June, 2016 08:18
> To: tipc-discussion@lists.sourceforge.net
> Subject: Re: [tipc-discussion] [PATCH net-next 3/6] tipc: introduce UDP
> replicast
>
>
>
> On 06/
> -Original Message-
> From: Richard Alpe [mailto:richard.a...@ericsson.com]
> Sent: Wednesday, 29 June, 2016 09:28
> To: Jon Maloy; tipc-discussion@lists.sourceforge.net
> Subject: Re: [tipc-discussion] [PATCH net-next 3/6] tipc: introduce UDP
> replicast
>
>
Acked-by: jon
> -Original Message-
> From: Ying Xue [mailto:ying@windriver.com]
> Sent: Wednesday, 29 June, 2016 07:31
> To: ma...@donjonn.com
> Cc: Jon Maloy; Ying Xue; tipc-discussion@lists.sourceforge.net
> Subject: [PATCH net-next] tipc: remove unused function
> -Original Message-
> From: Jon Maloy [mailto:jon.ma...@ericsson.com]
> Sent: Wednesday, 29 June, 2016 12:05
> To: Jon Maloy; tipc-discussion@lists.sourceforge.net
> Subject: Re: [tipc-discussion] [PATCH net-next 3/6] tipc: introduce UDP
> replicast
>
>
>
> -Original Message-
> From: Erik Hugne [mailto:erik.hu...@gmail.com]
> Sent: Wednesday, 29 June, 2016 16:15
> To: Jon Maloy
> Cc: Richard Alpe; Jon Maloy; tipc-discussion@lists.sourceforge.net
> Subject: Re: [tipc-discussion] [PATCH net-next 3/6] tipc: introduce UDP
&
> On Jun 30, 2016 15:05, "Richard Alpe" wrote:
> >
> > On 2016-06-29 21:20, Jon Maloy wrote:
> > >
> > >
> > >> -Original Message-
> > >> From: Jon Maloy [mailto:jon.ma...@ericsson.com]
> > >> Sent: Wednesday, 29
;
state to true before we issue the local acknowledges. This ensures that
those acknowledges will always be accepted. The mentioned state values
are restored immediately afterwards when the link is reset.
Signed-off-by: Jon Maloy
---
net/tipc/link.c | 2 ++
1 file changed, 2 insertions(+)
diff -
Two fixes to broadcast link problems that may occur in large systems.
Jon Maloy (2):
tipc: extend broadcast link initialization criteria
tipc: ensure correct broadcast send buffer release when peer is lost
net/tipc/link.c | 9 -
1 file changed, 8 insertions(+), 1 deletion
ink, and always with seqeunce number 1. Because
of this, we only need to look for a non-zero acknowledge value in the
arriving STATE messages, and once that is seen we know we are safe and
can set the field. Until then, we ignore all broadcast acknowledge
values from the peer.
Signed-off-by: Jon Maloy
will become evident in the next commit.
Signed-off-by: Jon Maloy
---
net/tipc/bearer.c| 60 +++-
net/tipc/bearer.h| 1 +
net/tipc/udp_media.c | 2 +-
3 files changed, 28 insertions(+), 35 deletions(-)
diff --git a/net/tipc/bearer.c b/net
The two first commits fixes a problem with the broadcast link.
This is really a bug fix, but the problem is too esoteric and
the solution too intrusive to be comfortably applied to 'net'.
The last commit is just an improvement of the link congestion
mechanism.
Jon Maloy (3):
tipc: m
(),
which really scans across all bearers and resets all their pertaining
links.
The "tipc_bearer::blocked" flag introduced in the previous commit
is now useful to ensure that no links are re-established during this
reset process.
Signed-off-by: Jon Maloy
---
net/tipc/bea
, and the current backlog limit
for the lowest level is too small to house even a single maximum-size
message, we have to expand this limit. We do this by evaluating an
alternative, minimum value during the setting of the importance limits.
Signed-off-by: Jon Maloy
---
net/tipc/link.c | 18
The two first commits fixes a problem with the brodcast link.
This is really a bug fix, but the problem is too esoteric and
the solution too intrusive to be comfortably applied to 'net'.
The last commit is just an improvement of the link congestion
mechanism.
Jon Maloy (3):
tipc: m
Hi,
I think this type of bug is Partha's table (or maybe Ying's), but he is
on vacation until next week, and I don't have time right now.
I cannot immediately figure out any smarter way to do this, but why does
the timeout need to be this short? Does it work with 2 ms, or 10 ms?
///jon
On 07/0
state to ESTABLISHED and the 'bc_peer_is_up'
state to true before we issue the local acknowledges. This ensures that
those acknowledges will always be accepted. The mentioned state values
are restored immediately afterwards when the link is reset.
Signed-off-by: Jon Maloy
---
net/tipc/
Fixes for some broadcast link problems that may occur in large systems.
v2: Added a third commit to reset all unicast links when broadcast
send link fails.
Jon Maloy (3):
tipc: extend broadcast link initialization criteria
tipc: ensure correct broadcast send buffer release when peer is
the broadcast link.
In this commit, we add a new function tipc_bearer_reset_all() to be used
in such situations. The function scans across all bearers and resets all
their pertaining links.
Signed-off-by: Jon Maloy
---
net/tipc/bearer.c | 17 +
net/tipc/bearer.h | 1 +
net/tipc
om the peer.
Signed-off-by: Jon Maloy
---
net/tipc/link.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/net/tipc/link.c b/net/tipc/link.c
index c1df33f..4cd76bb 100644
--- a/net/tipc/link.c
+++ b/net/tipc/link.c
@@ -1582,7 +1582,12 @@ void tipc_link_bc_sync_rcv(struct
I set it rather high.
> >
> > Thing is, this works without problems in Ubuntus's 3.13.x series kernels. I
> > only
> have problems in newer kernels.
> >
> > -Original Message-
> > From: Jon Maloy [mailto:ma...@donjonn.com]
> > Sent: Wednesday,
> -Original Message-
> From: Jon Maloy [mailto:jon.ma...@ericsson.com]
> Sent: Thursday, 07 July, 2016 10:54
> To: Parthasarathy Bhuvaragan; tipc-discussion@lists.sourceforge.net
> Subject: Re: [tipc-discussion] Driver crash
>
> > -Original Message-
and non-generic. We definitely need this when
the broadcast link resets in a large cluster.
Jon Maloy (2):
tipc: make bearer packet filtering generic
tipc: ensure that link congestion and wakeup use same criteria
net/tipc/bearer.c| 77 ++---
. We definitely need this when
the broadcast link resets in a large cluster.
Jon Maloy (2):
tipc: make bearer packet filtering generic
tipc: ensure that link congestion and wakeup use same criteria
net/tipc/bearer.c| 77 ++--
net/tip
201 - 300 of 1197 matches
Mail list logo
