Re: [tipc-discussion] [PATCH net-next v2 1/1] tipc: add neighbor monitoring framework

> -Original Message- > From: Parthasarathy Bhuvaragan > Sent: Monday, 25 April, 2016 04:25 > To: Jon Maloy; tipc-discussion@lists.sourceforge.net; Ying Xue; Richard Alpe > Cc: ma...@donjonn.com > Subject: Re: [PATCH net-next v2 1/1] tipc: add neighbor mo

[tipc-discussion] [PATCH net-next v7 3/4] tipc: add neighbor monitoring framework

he 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 eliminates the risk of avalanche link losses

[tipc-discussion] [PATCH net-next v7 4/4] tipc: debugging_tracing_profiling support for neighbor monitoring code

oring: - 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 <jon.ma...@ericsson.com> --- net/tipc/addr.c| 1

[tipc-discussion] [PATCH net-next v7 1/4] tipc: correct error in node fsm

LF_DOWN_ |<---+ SELF_DOWN_EVT| +--->| PEER_DOWN |<+ +--+ Signed-off-by: Jon Maloy <jon.ma...@ericsson.com> --- net/tipc/node.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/n

[tipc-discussion] [PATCH net-next v7 2/4] tipc: change node timer unit from jiffies to ms

ntation. Signed-off-by: Jon Maloy <jon.ma...@ericsson.com> --- 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/

Re: [tipc-discussion] tipc_sk_rcv: Kernel panic on one of the card on 4.4.0

> -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

Re: [tipc-discussion] [zeromq/libzmq] Tests and Protocol Support for TIPC partially broken (#1968)

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

Re: [tipc-discussion] [PATCH net-next 1/2] tipc: add neighbor monitoring framework

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

Re: [tipc-discussion] [zeromq/libzmq] Tests and Protocol Support for TIPC partially broken (#1968)

On 05/11/2016 10:05 AM, Erik Hugne wrote: > > > On May 11, 2016 14:34, "Jon Maloy" <ma...@donjonn.com > <mailto:ma...@donjonn.com>> wrote: > > > > > > > > On 05/10/2016 04:22 PM, Erik Hugne wrote: > > > Proble

[tipc-discussion] [PATCH net-next 1/1] tipc: change node timer unit to from jiffies to ms

ntation. Signed-off-by: Jon Maloy <jon.ma...@ericsson.com> --- 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-discussion] [PATCH net-next 1/1] tipc: eliminate risk of double link_up events

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 <jon.ma...@ericsson.com> --- net/tipc/node.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/net/tipc/node.c

Re: [tipc-discussion] [PATCH net-next] tipc: fix nametable publication field in nl compat

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

Re: [tipc-discussion] [PATCH net-next v6 4/4] tipc: debugging_tracing_profiling support for neighbor monitoring code

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; Jon

[tipc-discussion] [PATCH net-next v6 3/4] tipc: rate control acceptance of new neighbor nodes

icoseconds 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 time. Signed-o

[tipc-discussion] [PATCH net-next v6 4/4] tipc: debugging_tracing_profiling support for neighbor monitoring code

oring: - 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 <jon.ma...@ericsson.com> --- net/tipc/addr.c| 1

[tipc-discussion] [PATCH net-next v6 0/4] tipc: neighbor monitoring etc

to 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

[tipc-discussion] [PATCH net-next v6 0/4] tipc: neighbor monitoring etc

the 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

Re: [tipc-discussion] tipc utility: No tipc binary in iproute2

If you are using Ubuntu 16.04 you just do an apt-get install iproute2, and it will be there. If you need to build yourself you need to first install libmnl-dev, since building the tipc tool depends on this. If it is not there, it will only be silently bypassed. ///jon > -Original

Re: [tipc-discussion] [PATCH net-next 3/3] tipc: redesign connecton-level flow control

> -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-

Re: [tipc-discussion] [PATCH] tipc: Only process unicast on intended node

> -Original Message- > From: Hamish Martin [mailto:hamish.mar...@alliedtelesis.co.nz] > Sent: Sunday, 01 May, 2016 16:44 > To: Jon Maloy; Jon Maloy > Cc: tipc-discussion@lists.sourceforge.net; Ying Xue; Xue Ying > (ying.x...@gmail.com); Richard Alpe; Parthasarathy Bh

[tipc-discussion] [PATCH net-next 2/3] tipc: propagate peer node capabilities to socket layer

adds this functionality. Acked-by: Ying Xue <ying@windriver.com> Signed-off-by: Jon Maloy <jon.ma...@ericsson.com> --- net/tipc/node.c | 21 +++-- net/tipc/node.h | 1 + net/tipc/socket.c | 2 ++ 3 files changed, 22 insertions(+), 2 deletions(-) diff --gi

[tipc-discussion] [PATCH net-next 3/3] tipc: redesign connection-level flow control

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 <ying@windriver.com> Signed-off-by: Jon Maloy <jon.ma...@eri

[tipc-discussion] [PATCH net-next 1/3] tipc: re-enable compensation for socket receive buffer double counting

ensable when we reduce this buffer limit later in this series. We now fix this by inverting the mentioned condition. Acked-by: Ying Xue <ying@windriver.com> Signed-off-by: Jon Maloy <jon.ma...@ericsson.com> --- net/tipc/socket.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) di

[tipc-discussion] [PATCH net-next 2/3] tipc: propagate peer node capabilities to socket layer

adds this functionality. Acked-by: Ying Xue <ying@windriver.com> Signed-off-by: Jon Maloy <jon.ma...@ericsson.com> --- net/tipc/node.c | 21 +++-- net/tipc/node.h | 1 + net/tipc/socket.c | 2 ++ 3 files changed, 22 insertions(+), 2 deletions(-) diff --gi

[tipc-discussion] [PATCH net-next 3/3] tipc: redesign connection-level flow control

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 <ying@windriver.com> Signed-off-by: Jon Maloy <jon.ma...@eri

[tipc-discussion] [PATCH net-next 1/3] tipc: re-enable compensation for socket receive buffer double counting

ensable when we reduce this buffer limit later in this series. We now fix this by inverting the mentioned condition. Acked-by: Ying Xue <ying@windriver.com> Signed-off-by: Jon Maloy <jon.ma...@ericsson.com> --- net/tipc/socket.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) di

[tipc-discussion] [PATCH net-next 1/2] tipc: add neighbor monitoring framework

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 <jon.ma...@ericsson.com> --- net/tipc/Makefile

[tipc-discussion] [PATCH net-next 0/2] tipc: add monitoring framework

orst 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

Re: [tipc-discussion] [PATCH net-next 0/2] tipc: add monitoring framework

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 potent

Re: [tipc-discussion] [PATCH net-next v1] tipc: add the ability to get UDP options via netlink

Acked-by: jon ///j > -Original Message- > From: Richard Alpe > Sent: Monday, 25 April, 2016 04:51 > To: tipc-discussion@lists.sourceforge.net > Cc: Jon Maloy; Ying Xue; Richard Alpe > Subject: [PATCH net-next v1] tipc: add the ability to get UDP options via > netlin

[tipc-discussion] FW: [Bug 1567064] Re: tipc: missing linearization of sk_buff

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

[tipc-discussion] [PATCH net-next 3/5] tipc: refactor function tipc_link_timeout()

The function tipc_link_timeout() is unnecessary complex, and can easily be made more readable. We do that with this commit. The only functional change is that we remove a redundant test for whether the broadcast link is up or not. Acked-by: Ying Xue <ying@windriver.com> Signed-off-b

[tipc-discussion] [PATCH net-next 4/5] tipc: ensure that first packets on link are sent in order

en extra send call to the bearer immediately after the link has come up. Acked-by: Ying Xue <ying@windriver.com> Signed-off-by: Jon Maloy <jon.ma...@ericsson.com> --- net/tipc/node.c | 4 1 file changed, 4 insertions(+) diff --git a/net/tipc/node.c b/net/tipc/node.c i

[tipc-discussion] [PATCH net-next 1/5] tipc: guarantee peer bearer id exchange after reboot

Xue <ying@windriver.com> Signed-off-by: Jon Maloy <jon.ma...@ericsson.com> --- net/tipc/link.c | 10 +- net/tipc/msg.h | 10 ++ 2 files changed, 19 insertions(+), 1 deletion(-) diff --git a/net/tipc/link.c b/net/tipc/link.c index 7d2bb3e..8b98faf 100644 --- a/net

[tipc-discussion] [PATCH net-next 0/5] tipc: improvements to the link setup algorithm

This series addresses some smaller issues regarding the link setup algorithm. The first commit fixes a rare bug we have discovered during testing; the second one may have some future impact on cluster scalabilty, while remaining ones can be regarded as cosmetic in a wider sense of the word. Jon

Re: [tipc-discussion] [PATCH net-next v2 1/1] tipc: add neighbor monitoring framework

> -Original Message- > From: Parthasarathy Bhuvaragan > Sent: Monday, 18 April, 2016 09:30 > To: Jon Maloy; tipc-discussion@lists.sourceforge.net; Ying Xue; Richard Alpe > Cc: ma...@donjonn.com > Subject: Re: [PATCH net-next v2 1/1] tipc: add neighbor monitoring fra

Re: [tipc-discussion] [PATCH net-next v2 1/1] tipc: add neighbor monitoring framework

> -Original Message- > From: Parthasarathy Bhuvaragan > Sent: Monday, 18 April, 2016 09:30 > To: Jon Maloy; tipc-discussion@lists.sourceforge.net; Ying Xue; Richard Alpe > Cc: ma...@donjonn.com > Subject: Re: [PATCH net-next v2 1/1] tipc: add neighbor monitoring fra

Re: [tipc-discussion] [PATCH net-next v2 1/1] tipc: add neighbor monitoring framework

> -Original Message- > From: Parthasarathy Bhuvaragan > Sent: Tuesday, 19 April, 2016 09:53 > To: Jon Maloy; tipc-discussion@lists.sourceforge.net; Ying Xue; Richard Alpe > Cc: ma...@donjonn.com > Subject: Re: [PATCH net-next v2 1/1] tipc: add neighbor mo

[tipc-discussion] [PATCH net-next v3 1/1] tipc: add neighbor monitoring framework

r it is always off. v3: - Renamed "mon_breakpoint" to "mon_threshold" - Added code to revert to full-mesh monitoring when a node is removed and we reach the monitor threshold from above. Signed-off-by: Jon Maloy <jon.ma...@ericsson.com> --- net/tipc/Makefile

[tipc-discussion] [PATCH net-next 2/3] tipc: propagate peer node capabilities to socket layer

adds this functionality. Signed-off-by: Jon Maloy <jon.ma...@ericsson.com> --- 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 68d9f7b..d

[tipc-discussion] [PATCH net-next 0/3] tipc: redesign socket-level flow control

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 connecton-level flow control

[tipc-discussion] [PATCH net-next 3/3] tipc: redesign connecton-level flow control

. In order to keep this solution backwards compatible, we introduce a new capabability bit in the discovery protocol, and use this throughout the message sending/reception path to always select the right base unit. Signed-off-by: Jon Maloy <jon.ma...@ericsson.com> --- net/tipc/core.c

[tipc-discussion] [PATCH net-next 1/3] tipc: re-enable compensation for socket receive buffer double counting

ensable when we reduce this buffer limit later in this series. We now fix this by inverting the mentioned condition. Signed-off-by: Jon Maloy <jon.ma...@ericsson.com> --- net/tipc/socket.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/net/tipc/socket.c b/net/tipc/socket.c i

[tipc-discussion] [PATCH net-next v4 1/1] tipc: add neighbor monitoring framework

edback from Ying. - Removed unused function and flag for disabling the monitor. This functionality was later superseded by commit 5b7066c3dd24 ("tipc: stricter filtering of packets in bearer layer"), I just forgot to remove it. Signed-off-by: Jon Maloy <jon.ma...@e

[tipc-discussion] [PATCH net-next v4 2/2] tipc: ensure that link congestion and wakeup use same criteria

, 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 <jon.ma...@ericsson.com> --

[tipc-discussion] [PATCH net-next v4 1/2] tipc: make bearer packet filtering generic

nd reset at the same locations as with the previous solution, while the packet filtering is moved to the generic code for the sending side. On the receiving side, the filtering is still done in media specific code, but now including the UDP bearer. Signed-off-by: Jon Maloy <jon.ma...@ericsson.com&

[tipc-discussion] [PATCH net-next v4 0/2] tipc: bearer and link improvements

the media interface. v4: - Backed to v2, but made set/clear of the 'up' flag architecture safe according to comment from Ying. Jon Maloy (2): tipc: make bearer packet filtering generic tipc: ensure that link congestion and wakeup use same criteria net/t

[tipc-discussion] [PATCH net-next v4 0/2] tipc: bearer and link improvements

tion is ugly and non-generic. We definitely need this when the broadcast link resets in a large cluster. v3: - Made #1 rcu-safe by placing the block/unblock functions in the media specific code, and added acces to those from the generic code via two new function pointers in the m

Re: [tipc-discussion] [PATCH net-next v1 0/5] tipc: netlink updates for neighbour monitor

Partha, David was late with re-applying my latest three patches for 'net' so this is not your fault. Just remember to re-order the "reviewed-by" and the "signed-off-by" tags when you resubmit. ///jon On 07/25/2016 01:36 PM, David Miller wrote: > From: Parthasarathy Bhuvaragan

Re: [tipc-discussion] [PATCH iproute2 v5 00/10] tipc: updates for neighbour monitor

Sorry, my bad. When I finally used the right binary it worked fine, so forget about previous mail. Tested and acked-by: jon ///jon PS: net-next is at rc6+ now, so it might close any day. > -Original Message- > From: Jon Maloy > Sent: Thursday, 21 July, 2016 13:24 > To: P

[tipc-discussion] [PATCH net-next v5 1/2] tipc: make bearer packet filtering generic

nd reset at the same locations as with the previous solution, while the packet filtering is moved to the generic code for the sending side. On the receiving side, the filtering is still done in media specific code, but now including the UDP bearer. Signed-off-by: Jon Maloy <jon.ma...@ericsson.com&

[tipc-discussion] [PATCH net-next v5 2/2] tipc: ensure that link congestion and wakeup use same criteria

, 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 <jon.ma...@ericsson.com> --

Re: [tipc-discussion] tipc utils test cases

Hi Dennis, Which kernel version are you using? Which distro? Which CPU architecture ? What does your configuration look like? BR ///jon On 07/28/2016 11:08 AM, Dennis Yao wrote: > Hi, > I am trying to run all tipc-utils demo cases and only hello_word demo can > pass without issue. any one

Re: [tipc-discussion] [PATCH net-next v3 1/2] tipc: make bearer packet filtering generic

l Message- > From: Xue, Ying [mailto:ying....@windriver.com] > Sent: Wednesday, 20 July, 2016 05:14 > To: Ying Xue; Jon Maloy; Jon Maloy; tipc-discussion@lists.sourceforge.net; > Parthasarathy Bhuvaragan; Richard Alpe > Subject: RE: [tipc-discussion] [PATCH net-next v3 1/2] tipc: make

Re: [tipc-discussion] [PATCH net-next v3 1/2] tipc: make bearer packet filtering generic

whatever setting > bearer_list[i] to NULL or setting check dev->tipc_ptr to NULL occurs before > "up" is changed as true or false, it doesn't have any negative impact on our > desired behavior. > > Regards, > Ying > > -Original Message- > From: Jon

Re: [tipc-discussion] [PATCH iproute2 v4 00/10] tipc: updates for neighbour monitor

On 07/19/2016 07:30 AM, Parthasarathy Bhuvaragan wrote: > Hi Jon, > > On 07/15/2016 04:07 PM, Jon Maloy wrote: >> Hi Partha, >> >> 1: Last line in help text is unaligned: >> >> list - List links >> get

Re: [tipc-discussion] [PATCH net-next v3 0/5] tipc: netlink updates for neighbour monitor

Nice job! Reviewed-by: jon On 07/13/2016 07:20 AM, Parthasarathy Bhuvaragan wrote: > This series contains the updates to configure and read the monitor attributes. > > v3: - rebase the series on netnext > > v2: - updated #2, #3, #5 Variables ordering in stack from longest to shortest > -

Re: [tipc-discussion] [PATCH iproute2 v4 00/10] tipc: updates for neighbour monitor

Hi Partha, 1: Last line in help text is unaligned: list - List links get - Get various link properties set - Set various link properties statistics- Show or reset statistics monitor- Show or set link

[tipc-discussion] [PATCH net-next v3 1/2] tipc: make bearer packet filtering generic

unctions also test for whether the bearer is blocked or not before sending/delivering a packet. Signed-off-by: Jon Maloy <jon.ma...@ericsson.com> --- net/tipc/bearer.c| 63 +++- net/tipc/bearer.h| 5 - net/tipc/eth_media.c | 2 ++ ne

[tipc-discussion] [PATCH net-next v3 2/2] tipc: ensure that link congestion and wakeup use same criteria

, 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 <jon.ma...@ericsson.com> --

[tipc-discussion] [PATCH net-next v3 0/2] tipc: bearer and link improvements

tion is ugly and non-generic. We definitely need this when the broadcast link resets in a large cluster. v3: - Made #1 rcu-safe by placing the block/unblock functions in the media specific code, and added acces to those from the generic code via two new function pointers in the m

[tipc-discussion] [PATCH net 1/3] tipc: extend broadcast link initialization criteria

for a non-zero unicast acknowledge value in the arriving STATE messages, and once that is confirmed we know we are safe and can set the mentioned field. Before this moment, we must ignore all broadcast acknowledges from the peer. Acked-by: Ying Xue <ying@windriver.com> Signed-off-by: Jon

Re: [tipc-discussion] [PATCH net-next v3 1/2] tipc: make bearer packet filtering generic

far, I cannot find more simpler method to do this except that we reset > dev->tipc_ptr pointer on workqueue context under the protection of RTNL lock. > > Regards, > Ying > > -Original Message- > From: Jon Maloy [mailto:jon.ma...@ericsson.com] > Sent: Sa

[tipc-discussion] [PATCH net-next 3/3] tipc: ensure that link congestion and wakeup use same criteria

, 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 <jon.ma...@ericsson.com> --

Re: [tipc-discussion] Driver crash

t 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, July 06, 2

[tipc-discussion] [PATCH net v3 1/3] tipc: extend broadcast link initialization criteria

-by: Jon Maloy <jon.ma...@ericsson.com> --- 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(

[tipc-discussion] [PATCH net v3 2/3] tipc: ensure correct broadcast send buffer release when peer is lost

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 <jon.ma...@ericsson.

[tipc-discussion] [PATCH net v3 3/3] tipc: reset all unicast links when broadcast send link fails

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 <jon.ma...@ericsson.com> --- net/tipc/bearer.c | 15 +++ ne

Re: [tipc-discussion] [PATCH net-next v2 1/2] tipc: make bearer packet filtering generic

On 07/08/2016 07:17 AM, Xue, Ying wrote: > > -Original Message- > From: Jon Maloy [mailto:jon.ma...@ericsson.com] > Sent: Friday, July 08, 2016 4:21 AM > To: tipc-discussion@lists.sourceforge.net; > parthasarathy.bhuvara...@ericsson.com; Xue, Ying; richard.a...@erics

Re: [tipc-discussion] Driver crash

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

[tipc-discussion] [PATCH net v2 2/3] tipc: ensure correct broadcast send buffer release when peer is lost

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 <jon.ma...@ericsson.

[tipc-discussion] [PATCH net-next v2 0/2] tipc: bearer and link improvements

itely 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/tipc/bearer.h

[tipc-discussion] [PATCH net-next v2 2/2] tipc: ensure that link congestion and wakeup use same criteria

, 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 <jon.ma...@ericsson.com> --

Re: [tipc-discussion] [PATCH iproute2 v5 00/10] tipc: updates for neighbour monitor

:~# tipc l m l error, missing bearer media root@xenial1:~# I thought this was what you had fixed? I must have misunderstood something. ///jon > -Original Message- > From: Parthasarathy Bhuvaragan > Sent: Tuesday, 19 July, 2016 11:16 > To: tipc-discussion@lists.sourceforge.net; J

Re: [tipc-discussion] [PATCH net-next 4/6] tipc: add replicast peer discovery

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 >

Re: [tipc-discussion] [PATCH net-next 3/6] tipc: introduce UDP replicast

> -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 > >

Re: [tipc-discussion] [PATCH net-next] tipc: remove unused function declarations from bearer.h

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

Re: [tipc-discussion] [PATCH net-next 3/6] tipc: introduce UDP replicast

> -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 > > >

Re: [tipc-discussion] [PATCH net-next 3/6] tipc: introduce UDP replicast

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

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: introduc

[tipc-discussion] [PATCH net-next 3/3] tipc: send broadcast nack directly upon sequence gap detection

among the nodes in order to avoid NACK storms. Signed-off-by: Jon Maloy <jon.ma...@ericsson.com> --- net/tipc/link.c | 23 --- 1 file changed, 16 insertions(+), 7 deletions(-) diff --git a/net/tipc/link.c b/net/tipc/link.c index 58bb44d..b36e16c 100644 --- a/net/tipc/

[tipc-discussion] [PATCH net-next 0/3] tipc: improve broadcast NACK mechanism

The broadcast protocol has turned out to not scale well beyond 70-80 nodes, while it is now possible to build TIPC clusters of at least 1000 nodes. This commit series improves the NACK/retransmission mechanism of the broadcast protocol to make is at scalable as the rest of TIPC. Jon Maloy (3

[tipc-discussion] [PATCH net-next 1/3] tipc: transfer broadcast nacks in link state messages

d-off-by: Jon Maloy <jon.ma...@ericsson.com> --- net/tipc/bcast.c | 8 --- net/tipc/bcast.h | 4 ++-- net/tipc/link.c | 64 net/tipc/link.h | 6 +++--- net/tipc/msg.h | 10 + net/tipc/n

[tipc-discussion] [PATCH net-next 2/3] tipc: rate limit broadcast retransmissions

retransmissions, so that a retransmitted range cannot be retransmitted again until after at least 10 ms. This reduces the frequency of duplicate retransmissions by an order of magnitude, while having a significant positive impact on throughput and scalability. Signed-off-by: Jon Maloy <jon

Re: [tipc-discussion] tipc tool bash completions merged

Thanks Richard. A great job that should really enhance the experience of using tipc both by new and experienced users. ///jon > -Original Message- > From: Richard Alpe [mailto:richard.a...@ericsson.com] > Sent: Thursday, 04 August, 2016 03:20 > To: tipc-discussion@lists.sourceforge.net

Re: [tipc-discussion] [PATCH v2] tipc: add peer removal functionality

he tipc user space tool in iproute2. > > Signed-off-by: Richard Alpe <richard.a...@ericsson.com> > Reviewed-by: Jon Maloy <jon.ma...@ericsson.com> > Acked-by: Ying Xue <ying@windriver.com> > --- > include/uapi/linux/tipc_netlink.h | 1 + > net/tipc/net.

Re: [tipc-discussion] [PATCH v3] tipc: add peer removal functionality

t; > Signed-off-by: Richard Alpe <richard.a...@ericsson.com> > Reviewed-by: Jon Maloy <jon.ma...@ericsson.com> > Acked-by: Ying Xue <ying@windriver.com> > --- > include/uapi/linux/tipc_netlink.h | 1 + > net/tipc/net.h| 2 ++ > net/tipc/

Re: [tipc-discussion] [PATCH net-next v7 0/6] topology server fixes for nametable soft lockup

ra...@ericsson.com>; tipc- > discuss...@lists.sourceforge.net; Jon Maloy <jon.ma...@ericsson.com>; > thompa@gmail.com > Subject: RE: [PATCH net-next v7 0/6] topology server fixes for nametable soft > lockup > > Hi Partha, > > As long as you can confirm the

Re: [tipc-discussion] [PATCH net-next v2 2/2] tipc: allow rdm/dgram socketpairs

Thursday, 26 January, 2017 02:47 > To: tipc-discussion@lists.sourceforge.net; Jon Maloy <jon.ma...@ericsson.com>; > Ying Xue <ying@windriver.com> > Cc: erik.hu...@gmail.com > Subject: [PATCH net-next v2 2/2] tipc: allow rdm/dgram socketpairs > > From: Erik Hugne <

Re: [tipc-discussion] [PATCH net-next v3 1/2] tipc: add support for stream socketpairs

Both patches acked-by: jon ///jon > -Original Message- > From: Parthasarathy Bhuvaragan > Sent: Friday, January 27, 2017 11:14 AM > To: tipc-discussion@lists.sourceforge.net; Jon Maloy > <jon.ma...@ericsson.com>; Ying Xue <ying@windriver.com> > Cc: Er

Re: [tipc-discussion] [PATCH net-next v2 2/2] tipc: allow rdm/dgram socketpairs

> -Original Message- > From: Parthasarathy Bhuvaragan > Sent: Friday, January 27, 2017 3:02 AM > To: Jon Maloy <jon.ma...@ericsson.com>; tipc- > discuss...@lists.sourceforge.net; Ying Xue <ying@windriver.com> > Cc: erik.hu...@gmail.com > Subject:

Re: [tipc-discussion] [PATCH net-next v2 2/2] tipc: allow rdm/dgram socketpairs

> -Original Message- > From: Jon Maloy [mailto:jon.ma...@ericsson.com] > Sent: Friday, January 27, 2017 7:13 AM > To: Parthasarathy Bhuvaragan <parthasarathy.bhuvara...@ericsson.com>; > tipc-discussion@lists.sourceforge.net; Ying Xue <ying@windriver.com>

Re: [tipc-discussion] [net 0/5] solve two deadlock issues

go into net-next ? Regards ///jon > -Original Message- > From: Ying Xue [mailto:ying@windriver.com] > Sent: Monday, February 20, 2017 06:39 AM > To: Jon Maloy <jon.ma...@ericsson.com>; Parthasarathy Bhuvaragan > <parthasarathy.bhuvara...@ericsson.com>; thom

Re: [tipc-discussion] [net 0/5] solve two deadlock issues

Ok. So go for it to net-next. Reviewed-by: Jon ///jon > -Original Message- > From: Ying Xue [mailto:ying@windriver.com] > Sent: Wednesday, February 22, 2017 06:47 AM > To: Jon Maloy <jon.ma...@ericsson.com>; Parthasarathy Bhuvaragan > <parthasarathy.bhuvara.

[tipc-discussion] FW: [PATCH next 0/4] bonding: winter cleanup

Ying, Net-next *is* closed. ///jon -Original Message- From: netdev-ow...@vger.kernel.org [mailto:netdev-ow...@vger.kernel.org] On Behalf Of David Miller Sent: Tuesday, February 21, 2017 10:30 PM To: mah...@bandewar.net Cc: j.vosbu...@gmail.com; a...@greyhouse.net; vfal...@gmail.com;

Re: [tipc-discussion] TIPC Oops in tipc_sk_recv

Hi Peter, I don't think this is any known bug. Is it repeatable? ///jon > -Original Message- > From: Butler, Peter [mailto:pbut...@sonusnet.com] > Sent: Tuesday, February 21, 2017 12:14 PM > To: tipc-discussion@lists.sourceforge.net > Cc: Butler, Peter > Subject:

Re: [tipc-discussion] TIPC Oops in tipc_sk_recv

> -Original Message- > From: Butler, Peter [mailto:pbut...@sonusnet.com] > Sent: Wednesday, February 22, 2017 01:04 PM > To: Jon Maloy <jon.ma...@ericsson.com>; tipc- > discuss...@lists.sourceforge.net > Cc: Butler, Peter <pbut...@sonusnet.com> > Subje

Re: [tipc-discussion] tipc multicast stuck (hit max window) due to invalid bc_ack value

nge anyway since no one uses bc_ack before validate. > > We are checking that if we have your recommended patch. Is that patch > already in kernel 4.9.11? Yes, it is. ///jon > > Thanks, > Matthew > > > -Original Message- > From: Jon Maloy [mailto:jon.ma.

Re: [tipc-discussion] TIPC Oops in tipc_sk_recv

02:48 PM > To: Jon Maloy <jon.ma...@ericsson.com>; tipc- > discuss...@lists.sourceforge.net; Parthasarathy Bhuvaragan > <parthasarathy.bhuvara...@ericsson.com> > Cc: Butler, Peter <pbut...@sonusnet.com> > Subject: RE: TIPC Oops in tipc_sk_recv > > I hav

Re: [tipc-discussion] TIPC Oops in tipc_sk_recv

> -Original Message- > From: Butler, Peter [mailto:pbut...@sonusnet.com] > Sent: Thursday, February 23, 2017 03:30 PM > To: Jon Maloy <jon.ma...@ericsson.com>; tipc- > discuss...@lists.sourceforge.net; Parthasarathy Bhuvaragan > <parthasarathy.bhuvara...@ericss

<    1   2   3   4   5   6   7   8   9   10   >