Open source TIPC (Transparent IPC) protocol mailing list

Jon Maloy | 22 May 2013 18:53

RDM and multicast flow control

Erik and I have been discussing how we can find a satisfactory solution to the RDM and
multicast message overload problem.

I now suggest a combination of two related mechanisms, partially based on Erik's original
suggestion to distribute "overload flags" to all distributed publication items when
overload happens.

A:
---
1) When a receiving socket is approaching overflow, e.g. at LOW_IMPORTANCE-level*0.75, it
scans through the receive queue and identifies the senders which are using LOW_IMPORTANCE.
2) Those senders, or if there are too many, those who contribute most of the load (say,
representing 50% of the load combined) will be sent a message of a new type, called
OVERLOAD_WARNING.
3) When a sender socket receives OVERLOAD_WARNING, it has to mark itself as OVERLOADED
and return -EAGAIN on all sendmsg() calls for the given port name until it receives
an OVERLOAD_FINISHED message from the same socket.
4) The receiving socket issues an OVERLOAD_FINISHED to all the warned senders when the
receive queue length goes below e.g. LOW_IMPORTANCE-level/2.

This procedure is repeated for each importance level.

B:
----
5) If the receiving socket queue still surpasses LOW_IMPORTANCE-level, it issues a new broadcast
NAME_DISTR message called NAME_OVERLOADED or similar. This carries information about
which importance level is affected, and the information is stored in each publish element
in the name table pertaining to the receiver in question.
6) A sender who wants to send a LOW_IMPORTANCE message to the socket in question will now
encounter a flag indicating that "LOW_IMPORTANCE is overloaded" during name lookup,

(Continue reading)

headers

erik.hugne | 17 May 2013 11:45

[PATCH 0/2] Add IP/UDP bearer support

From: Erik Hugne <erik.hugne <at> ericsson.com>

I've had this laying around for quite some time now and i figured
it's time to do a push.
The functionality is fairly isolated, the changes done in the core parts and
userspace API is to allow for longer link names that contains a ':' character.
IPv6 support is not yet possible, as that would violate the current protocol
spec (bearer level originating address field is too small).

An updated tipcutils required to configure UDP bearers can be found here:
git clone -b udp_bearer git <at> github.com:Hugne/tipc-config-dev.git

Erik Hugne (2):
  tipc: allow longer link names containing ':' character
  tipc: add ip/udp media type

 include/uapi/linux/tipc_config.h |    9 +-
 net/tipc/Makefile                |    2 +-
 net/tipc/bearer.h                |    3 +
 net/tipc/core.c                  |    4 +
 net/tipc/link.c                  |    5 +-
 net/tipc/udp_media.c             |  477 ++++++++++++++++++++++++++++++++++++++
 6 files changed, 494 insertions(+), 6 deletions(-)
 create mode 100644 net/tipc/udp_media.c

--

-- 
1.7.5.4

------------------------------------------------------------------------------
AlienVault Unified Security Management (USM) platform delivers complete

(Continue reading)

headers

Azeez Mohammad | 16 May 2013 21:48

TIPC 1.7.7 question.

Hi

I sent out emails before about a leak in TIPC 1.7.7 using Windriver 2.6.27.57-WR3.0.3bc_standard while
doing a performance test.

I was able to narrow it down to this code. Specifically to lines 1382, 1383 in tipc_socket.c file below.

The TIPC_ERR_OVERLOAD condition is not being checked in 1.7.7 while it was being checked in 1.7.6
Was it intentional?

When I added the code for checking the TIPC_ERR_OVERLOAD condition in tipc_socket.c, the slab is not
growing. I added statistics and there were a lot of messages that met the overload condition.

Please let me know if this is a bug or if it is per design.

Thanks
Azeez

tipc_socket.c from TIPC 1.7.7

   1360 static u32 dispatch(struct tipc_port *tport, struct sk_buff *buf)
   1361 {
   1362         struct sock *sk = (struct sock *)tport->usr_handle;
   1363         u32 res;
   1364
   1365         /*
   1366  *          * Process message if socket is unlocked; otherwise add to backlog queue
   1367  *                   *
   1368  *                            * This code is based on sk_receive_skb(), but must be distinct from it
   1369  *                                     * since a TIPC-specific filter/reject mechanism is utilized

(Continue reading)

headers

Erik Hugne | 13 May 2013 17:30

Getting link events from topology server?

A common problem in cluster environment is how to detect/
handle the loss of a logical connection between two
nodes. This loss can be caused by NIC failure, cable unplugged,
switch failure etc. 
TIPC handles this quite well, and it should be quite simple
to expose this information to userland.
I'd like to push for a feature that would allow an 
application to subscribe to link layer events through 
the topology server.

Some examples of applications that this would be useful for is
traffic loadbalancers or routing daemons.

Agree/Disagree?

//E

------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and 
their applications. This 200-page book is written by three acclaimed 
leaders in the field. The early access version is available now. 
Download your free book today! http://p.sf.net/sfu/neotech_d2d_may

headers

Jon Maloy | 7 May 2013 05:57

[PATCH net-next 0/8] tipc: removing remnants of native API

We remove the last remnants of the TIPC native API, to make it
possible to simplify locking policy and solve a problem with lost
topology events.

First, we introduce a socket-based alternative to the native API.

Second, we convert the two remaining users of the native API, the 
TIPC internal topology server and the configuarion server, to use the
new API. 

Third, we remove the remaining code pertaining to the native API.

Fourth we change the spinlock used in configuration server int mutexes

We also make some cosmetic changes that have become possible due to the
removed code.

Ying Xue (8):
  tipc: introduce new TIPC server infrastructure
  tipc: convert topology server to use new server facility
  tipc: convert configuration server to use new sever facility
  tipc: delete the truly orphaned code
  tipc: remove user_port instance from tipc_port structure
  tipc: rename tipc_createport_raw to tipc_createport
  tipc: convert config_lock from spinlock to mutex
  tipc: save sock structure pointer instead of void pointer to
    tipc_port

 net/tipc/Makefile |    2 +-
 net/tipc/config.c |  119 +++++------

(Continue reading)

headers

Jon Maloy | 6 May 2013 06:11

[PATCH net-next 1/1] tipc: allow implicit connect for stream sockets

From: Erik Hugne <erik.hugne <at> ericsson.com>

(Paul: This one seems to be urgent, as we must have this accepeted
in net-next before we can convince SUSE to allow it in their TIPC package.
Ericsson is using SUSE extensively as our Linux distribution provider)

TIPC's implied connect feature, aka piggyback connect, allows
applications to save one syscall and all SYN/SYN-ACK signalling
overhead when setting up a connection.
Until now this has only been supported for SEQPACKET sockets.
Make it possible to use this feature even with stream sockets.

At the connecting side, the connection is completed when the
first data message arrives from the accepting peer.
This means that we must allow the connecting user to call blocking
recv() before the socket has reached state SS_CONNECTED.
So we must must relax the state machine check at recv_stream(), and
allow the recv() call even if socket is in state SS_CONNECTING.

Signed-off-by: Erik Hugne <erik.hugne <at> ericsson.com>
Signed-off-by: Jon Maloy <jon.maloy <at> ericsson.com>
---
 net/tipc/socket.c |    6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/net/tipc/socket.c b/net/tipc/socket.c
index 515ce38..f0af614 100644
--- a/net/tipc/socket.c
+++ b/net/tipc/socket.c
 <at>  <at>  -519,8 +519,7  <at>  <at>  static int send_msg(struct kiocb *iocb, struct socket *sock,

(Continue reading)

headers

Erik Hugne | 3 May 2013 10:23

RTT link statistics?

Now that we're starting to get more bearer types in TIPC,
maybe it would be a good idea to add latency to the
link statistics?

There is already a (32bit) unused timestamp field in the link protocol
header, so this is likely not a new idea :)

T0   - calculated when a link state probe message is transmitted
T1   - set in the packet when a link state response message is transmitted
T2   - calculated when a link state response (probe reply) message is received

T0 is a new u32 field in the link struct, T2 is only used when doing the RTT 
calculations.

The nodes can then get:
RTT  = T2-T0
A->B = T1-T0	//Latency from the local node to the link peer
B->A = T2-T1	//Latency from the peer to the local node

It could be represented like this in the link statistics (last line)

Link <1.1.2:eth0-1.1.1:eth0>
  ACTIVE  MTU:1500  Priority:10  Tolerance:1500 ms  Window:192 packets
  RX packets:100526 fragments:0/0 bundles:0/0
  TX packets:586321 fragments:0/0 bundles:0/0
  TX profile sample:158 packets  average:1350 octets
  0-64:10% -256:0% -1024:0% -4096:90% -16384:0% -32768:0% -66000:0%
  RX states:36542 probes:2385 naks:275 defs:0 dups:0
  TX states:10155 probes:2371 naks:0 acks:5399 dups:6710
  Congestion link:58  Send queue max:192 avg:0

(Continue reading)

headers

Ying Xue | 28 Apr 2013 12:16

[PATCH net-next 0/8] tipc: removing remnants of native API

Hi All,

In this version, below changes are made:

- rebase patches on the latest net-next branch
- add restriction on rx patch of server
- removal of top_srv structure
- revise some error log
- revise incorrect comment style
- update patch #2, #3, and #7 commit header
- divide patch #4 into three small patches
- add another patch #8 to avoid unnecessary cast.

Ying Xue (8):
  tipc: introduce new TIPC server infrastructure
  tipc: convert topology server to use new server facility
  tipc: convert configuration server to use new sever facility
  tipc: delete the truly orphaned code
  tipc: remove user_port instance from tipc_port structure
  tipc: rename tipc_createport_raw to tipc_createport
  tipc: convert config_lock from spin lock to mutex
  tipc: save sock structure pointer instead of void pointer to
    tipc_port

 net/tipc/Makefile |    2 +-
 net/tipc/config.c |  119 +++++------
 net/tipc/core.c   |   13 +-
 net/tipc/core.h   |    9 +-
 net/tipc/link.c   |   54 +----
 net/tipc/msg.c    |   15 +-

(Continue reading)

headers

Rodrigo Campos | 27 Apr 2013 22:58

[PATCH] tipcutils: Fix a precedence bug and gcc warning

When compiling with gcc 4.7.2, this warning is thrown:
	tipc-pipe.c: In function ‘pipe_start’:
	tipc-pipe.c:290:3: warning: suggest parentheses around ‘&&’ within ‘||’

This patch just fixes it by adding the parentheses in a way that if either of
the fds receive a POLLHUP and no data_in_len, then it breaks and exits the
function.

Without parentheses "a || b && !c" is evaluated as "a || (b && !c)", so without
parentheses it will be true if "a" is true, no matter "c". And IIUC that is not
what we want, as we want to make sure it exits when no data is received.

Now it seems to work "by chance" and the bug is never hit. Because if we close
then "a" (the local POLLHUP) is true, and then the whole if is true (although
"c" is 0 in that case too) and exits. And when the other end closes, then "b" is
true (the other end POLLHUP) and "c" is 0 in that case (as it is initialized to
0 at the beggining of the loop) so b && !c is true, and the whole if is true.

But it seems that the right thing is to check a POLLHUP on any of the fds and no
data_in_len, as that is what we want to know. And on those cases will continue
to work with this change, because when "a" is true, "c" is 0 (so "(a || b) &&
!c" will be true) and when "b" is true, "c" is 0 too and the if will be true
too.
---

Hi,

This is my first patch to TIPC and I don't have a TIPC env to test right now.
I'll have time to test it on Monday or Tuesday probably, but wanted to know your
opinion about it.

(Continue reading)

headers

Rodrigo Campos | 27 Apr 2013 23:06

[PATCH] tipcutils: Fix a precedence bug and gcc warning

When compiling with gcc 4.7.2, this warning is thrown:
	tipc-pipe.c: In function ‘pipe_start’:
	tipc-pipe.c:290:3: warning: suggest parentheses around ‘&&’ within ‘||’

This patch just fixes it by adding the parentheses in a way that if either of
the fds receive a POLLHUP and no data_in_len, then it breaks and exits the
function.

Without parentheses "a || b && !c" is evaluated as "a || (b && !c)", so without
parentheses it will be true if "a" is true, no matter "c". And IIUC that is not
what we want, as we want to make sure it exits when no data is received.

Now it seems to work "by chance" and the bug is never hit. Because if we close
then "a" (the local POLLHUP) is true, and then the whole if is true (although
"c" is 0 in that case too) and exits. And when the other end closes, then "b" is
true (the other end POLLHUP) and "c" is 0 in that case (as it is initialized to
0 at the beggining of the loop) so b && !c is true, and the whole if is true.

But it seems that the right thing is to check a POLLHUP on any of the fds and no
data_in_len, as that is what we want to know. And on those cases will continue
to work with this change, because when "a" is true, "c" is 0 (so "(a || b) &&
!c" will be true) and when "b" is true, "c" is 0 too and the if will be true
too.
---

Hi,

This is my first patch to TIPC and I don't have a TIPC env to test right now.
I'll have time to test it on Monday or Tuesday probably, but wanted to know your
opinion about it.

(Continue reading)

headers

erik.hugne | 26 Apr 2013 16:57

[RFC PATCH] GRO for TIPC

From: Erik Hugne <erik.hugne <at> ericsson.com>

Extensive testing in larger clusters are needed, so i'm marking it RFC
for now.
We should also discuss if/how RDM GRO can be done, and what should trigger 
a flush for that traffic.
Also, how about fragmented traffic?
I'd like to avoid having separate *_gro_receive/complete routines for each
traffic type.. maybe we can do something smart here?

If you want to build/try it out, the patch is based on v3.8-9166-g998f7e6 
with the following extra patches:
tipc: increase the max allowed link windowsize
tipc: select default bearer window from interface txq len
tipc: pass desired link window in ndisc request/response exchange

Erik Hugne (1):
  tipc: add basic GRO support

 include/linux/skbuff.h |    2 +
 net/tipc/eth_media.c   |  127 +++++++++++++++++++++++++++++++++++++++++++++++-
 net/tipc/link.c        |    8 ++-
 net/tipc/port.c        |    6 ++-
 net/tipc/socket.c      |   15 +++++-
 5 files changed, 151 insertions(+), 7 deletions(-)

--

-- 
1.7.5.4

------------------------------------------------------------------------------

(Continue reading)

66	May 2013
156	April 2013
130	March 2013
28	February 2013
79	January 2013
51	December 2012
99	November 2012
43	October 2012
61	September 2012
28	August 2012
40	July 2012
146	June 2012
89	May 2012
25	April 2012
46	March 2012
35	February 2012
42	January 2012
30	December 2011
23	November 2011
10	October 2011
43	September 2011
35	August 2011
19	July 2011
13	June 2011
34	May 2011
19	April 2011
49	March 2011
45	February 2011
52	January 2011
36	December 2010
68	November 2010
54	October 2010
67	September 2010
50	August 2010
42	July 2010
53	June 2010
32	May 2010
28	April 2010
30	March 2010
21	February 2010
14	January 2010
17	December 2009
15	November 2009
19	October 2009
16	September 2009
61	August 2009
28	July 2009
9	June 2009
56	May 2009
18	April 2009
27	March 2009
12	February 2009
52	January 2009
90	December 2008
73	November 2008
78	October 2008
149	September 2008
75	August 2008
39	July 2008
50	June 2008
99	May 2008
19	April 2008
62	March 2008
81	February 2008
30	January 2008
33	December 2007
33	November 2007
49	October 2007
42	September 2007
41	August 2007
30	July 2007
32	June 2007
53	May 2007
40	April 2007
1	January 2006

Mon	Tue	Wed	Thu	Fri	Sat	Sun

		1	2	3	4	5
6	7	8	9	10	11	12
13	14	15	16	17	18	19
20	21	22	23	24	25	26
27	28	29	30	31