O'Brien, Chris | 25 Jul 22:47 2014

Intra-node statistics

Hello,

First things first I would like to say thanks for supporting TIPC.

I am using TIPC 2.0 in a multi-node environment that includes intra-node communication using
connectionless sockets. Using tipc-config I can see statistics as expected against the links when
traffic goes to other nodes and uses a link. We are seeing TIPC_ERR_OVERLOAD returned messages and I was
curious how much this path was being used. I do not see a way to get statistics on the number and size of
messages sent that bypass the links.

Is there a way to get statistics similar to the link statistics for the intra-node communication?

I also noticed that on the master branch socket.c function filter_rcv() has been changed to support a
calculation based on sk->sk_rcvbuf and SO_RCVBUF. I think this might actually give me a way to increase
the buffers without recompiling the kernel (once we take the changes in our kernel). Did I interpret this properly?

Thanks,
Chris

============================================================
The information contained in this message may be privileged
and confidential and protected from disclosure. If the reader
of this message is not the intended recipient, or an employee
or agent responsible for delivering this message to the
intended recipient, you are hereby notified that any reproduction,
dissemination or distribution of this communication is strictly
prohibited. If you have received this communication in error,
please notify us immediately by replying to the message and
deleting it from your computer. Thank you. Coriant-Tellabs
============================================================
(Continue reading)

Butler, Peter | 25 Jul 15:58 2014

tipc_port_get_ports() continually overwrites same (single) entry

With TIPC 2.0 (on TIPC 1.7 this was not an issue) the port listing is always truncated after a single entry.  (I
am testing this with kernel 3.4.2 but in looking at 3.15.6 I can see the same bug upon code inspection.)

For example:

[root <at> Lab230slot5 ~]# tipc-config -p
Ports:
1714937942: connected to <1.1.3:552255677> via {50000,14002}

However there are around 200 entries that should be listed here in my setup.

I instrumented the code such that the kernel would printk the string associated with each port entry as it is
generated for the TLV buffer (i.e. around 200 lines are output to the kernel log ring buffer).  The last of
these lines is the only one that appears in user space (i.e. output from the tipc-config command).

I made a quick fix to the kernel code in tipc_port_get_ports() which seems to fix the problem.  For example,
now I get:

[root <at> Lab230slot5 ~]# tipc-config -p | more
Ports:
2037866497: bound to {1,1}
2037866498: bound to {0,16781317}
2037981187: connected to <1.1.5:2037866500> via {1,1}
2037866500: connected to <1.1.5:2037981187>
2037866501: connected to <1.1.2:1722089553> via {50000,14002}
2037866502: connected to <1.1.13:1709883427> via {50000,14013}
2037866503: connected to <1.1.5:2037866504> via {1,1}
2037866504: connected to <1.1.5:2037866503>
2037866505: connected to <1.1.5:2037866506> via {1,1}
2037866506: connected to <1.1.5:2037866505>
(Continue reading)

Jon Maloy | 24 Jul 07:05 2014
Picon

[PATCH net-next v2 00/14] Merge port and socket layer code

After the removal of the TIPC native interface, there is no reason to
keep a distinction between a "generic" port layer and the "specific"
socket layer in the stack. Throughout the last months, we have posted
several series that aimed at facilitating removal of the port layer,
and in particular the port spinlock, which in reality duplicates the
role normally kept by lock_sock()/bh_lock_sock().

In this series, we finalize this work, by making a significant number of
changes to the link, node, port and socket code, all with the purpose to
reduce dependencies between the layers, and hence create the conditions
for simplifying the locking aand data structure. In the final three
commits, we remove the port spinlock and the files port.c/port.h
altogether.

After this series, we have a socket layer that has only few dependencies
to the rest of the stack, and vice versa. It should now be possible to
continue cleanups of the socket code without significantly affecting
other layers of the stack.

Jon Maloy (14):
  tipc: introduce new function tipc_msg_create()
  tipc: use pseudo message to wake up sockets after link congestion
  tipc: use message to abort connections when losing contact to node
  tipc: clean up socket timer function
  tipc: eliminate function tipc_port_shutdown()
  tipc: elimintate port_connect/disconnect functions
  tipc: redefine message acknowledge function
  tipc: eliminate functions tipc_port_init/tipc_port_destroy
  tipc: use lock_sock instead of port_lock when scanning ports
  tipc: replace port pointer with socket pointer in registry
(Continue reading)

Jon Maloy | 15 Jul 12:23 2014
Picon

[PATCH net-next v7 0/7] tipc: multicast and internal users to new send functions

We move the remaining data transmit users: multicast, name table
distributor, and link internal protocols to use the new data
transmission framework introduced in a previous commit series
("tipc: new unicast transmission code").

Finally, we remove the code obsoleted by the new functions.

v2: Major changes to commits #3 and 4:
    - #3: bcast_xmit2() takes no parameter "local" and "remote" anymore.
      Instead, it unconditionally sends a cloned copy of the message to
      the receive function in the socket before, also unconditionally,
      sending it out on the broadcast link.
    - Renamed the clone+reassemly function in msg.c to 
      tipc_msg_reassemble().
    - #4:  Removed the initial lookup at the send side of a multicast.
      The lookup is now made only in one place, in tipc_sk_mcast_rcv().
    - I discovered that the current code violates the spec by completely
      ignoring the 'lookup scope' given to the message by the sender, and
      replacing it with hard-coded values. This is unfortunate, but
      I dare not change this now, so we will have to live with it.
    - Fixed two problems reported by Ying: a potential small memory leak,
      and a send failure due to a wrong return value from the multicast
      send function.

v3: - Fixed a typo in commit #v3/3 discovered by Ying.
    - Added a new commit #1, fixing a very serious bug in broadcast msg
      reassmbly. This is the same as the one David applied to 'net' a
      few days ago.
    - Added a new commit #2, fixing a problem that the last of a
      reassembled buffer chain may have a non-NULL next pointer.
(Continue reading)

Jon Maloy | 15 Jul 04:45 2014
Picon

[PATCH net-next v6 0/9] tipc: multicast and internal users to new send functions

In the two first commits, we fix a couple of bugs in tipc_buf_append()
that have impact on multicast/broadcast reasembly. Commit #1 has already
been applied to 'net', but we need it in 'net-next too, for the rest of
this series to work properly

We then move the remaining data transmit users: multicast, name table
distributor, and link internal protocols to use the new data
transmission framework.

Finally, we clean up the code obsoleted by the new functions.

v2: Major changes to commits #3 and 4:
    - #3: bcast_xmit2() takes no parameter "local" and "remote" anymore.
      Instead, it unconditionally sends a cloned copy of the message to
      the receive function in the socket before, also unconditionally,
      sending it out on the broadcast link.
    - Renamed the clone+reassemly function in msg.c to 
      tipc_msg_reassemble().
    - #4:  Removed the initial lookup at the send side of a multicast.
      The lookup is now made only in one place, in tipc_sk_mcast_rcv().
    - I discovered that the current code violates the spec by completely
      ignoring the 'lookup scope' given to the message by the sender, and
      replacing it with hard-coded values. This is unfortunate, but
      I dare not change this now, so we will have to live with it.
    - Fixed two problems reported by Ying: a potential small memory leak,
      and a send failure due to a wrong return value from the multicast
      send function.

v3: - Fixed a typo in commit #v3/3 discovered by Ying.
    - Added a new commit #1, fixing a very serious bug in broadcast msg
(Continue reading)

Jon Maloy | 14 Jul 04:31 2014
Picon

[PATCH net-next v5 0/9] tipc: multicast and internal users to new send functions


In the two first commits, we fix a couple of bugs in tipc_buf_append()
that have impact on multicast/broadcast reasembly. Commit #1 has already
been applied to 'net', but we need it in 'net-next too, for the rest of
this series to work properly

We then move the remaining data transmit users: multicast, name table
distributor, and link internal protocols to use the new data
transmission framework.

Finally, we clean up the code obsoleted by the new functions.

v2: Major changes to commits #3 and 4:
    - #3: bcast_xmit2() takes no parameter "local" and "remote" anymore.
      Instead, it unconditionally sends a cloned copy of the message to
      the receive function in the socket before, also unconditionally,
      sending it out on the broadcast link.
    - Renamed the clone+reassemly function in msg.c to 
      tipc_msg_reassemble().
    - #4:  Removed the initial lookup at the send side of a multicast.
      The lookup is now made only in one place, in tipc_sk_mcast_rcv().
    - I discovered that the current code violates the spec by completely
      ignoring the 'lookup scope' given to the message by the sender, and
      replacing it with hard-coded values. This is unfortunate, but
      I dare not change this now, so we will have to live with it.
    - Fixed two problems reported by Ying: a potential small memory leak,
      and a send failure due to a wrong return value from the multicast
      send function.

v3: - Fixed a typo in commit #v3/3 discovered by Ying.
(Continue reading)

Jon Maloy | 14 Jul 04:03 2014
Picon

[PATCH net-next v4 0/8] tipc: multicast and internal users to new send functions

In the two first commits, we fix a couple of bugs in tipc_buf_append()
that have impact on multicast/broadcast reasembly. Commit #1 has already
been applied to 'net', but we need it in 'net-next too, for the rest of
this series to work properly

We then move the remaining data transmit users: multicast, name table
distributor, and link internal protocols to use the new data
transmission framework.

Finally, we clean up the code obsoleted by the new functions.

v2: Major changes to commits #3 and 4:
    - #3: bcast_xmit2() takes no parameter "local" and "remote" anymore.
      Instead, it unconditionally sends a cloned copy of the message to
      the receive function in the socket before, also unconditionally,
      sending it out on the broadcast link.
    - Renamed the clone+reassemly function in msg.c to 
      tipc_msg_reassemble().
    - #4:  Removed the initial lookup at the send side of a multicast.
      The lookup is now made only in one place, in tipc_sk_mcast_rcv().
    - I discovered that the current code violates the spec by completely
      ignoring the 'lookup scope' given to the message by the sender, and
      replacing it with hard-coded values. This is unfortunate, but
      I dare not change this now, so we will have to live with it.
    - Fixed two problems reported by Ying: a potential small memory leak,
      and a send failure due to a wrong return value from the multicast
      send function.

v3: - Fixed a typo in commit #v3/3 discovered by Ying.
    - Added a new commit #1, fixing a very serious bug in broadcast msg
(Continue reading)

Jon Maloy | 11 Jul 03:20 2014
Picon

[PATCH net-next v3 0/8] tipc: multicast and internal users to new send functions

In the two first commits, we fix a couple of bugs in tipc_buf_append()
that have impact on multicast/broadcast reassembly. Commit #1 has already
been applied to 'net', but we need it in 'net-next' too, for the rest of
this series to work properly

We then move the remaining data transmit users: multicast, name table
distributor, and link internal protocols to use the new data
transmission framework introduced in a recent commit series.

Finally, we clean up the code obsoleted by the new functions.

v2: Major changes to commits #3 and 4:
    - #3: bcast_xmit2() takes no parameter "local" and "remote" anymore.
      Instead, it unconditionally sends a cloned copy of the message to
      the receive function in the socket before, also unconditionally,
      sending it out on the broadcast link.
    - Renamed the clone+reassemly function in msg.c to 
      tipc_msg_reassemble().
    - #4:  Removed the initial lookup at the send side of a multicast.
      The lookup is now made only in one place, in tipc_sk_mcast_rcv().
    - I discovered that the current code violates the spec by completely
      ignoring the 'lookup scope' given to the message by the sender, and
      replacing it with hard-coded values. This is unfortunate, but
      I dare not change this now, so we will have to live with it.
    - Fixed two problems reported by Ying: a potential small memory leak,
      and a send failure due to a wrong return value from the multicast
      send function.

v3: - Fixed a typo in commit #v3/3 discovered by Ying.
    - Added a new commit #1, fixing a very serious bug in broadcast msg
(Continue reading)

Jon Maloy | 8 Jul 20:07 2014
Picon

[PATCH net-next v2 0/6] tipc: multicast and internal users to new send functions

In this series, we move the remaining data transmit users: multicast
data users, the name table distributor, and the link internal protocols
to use the new data transmission framework.

We also clean up the code obsoleted by the new functions.

v2: Major changes to commits #3 and 4:
    - #3: bcast_xmit2() takes no parameter "local" and "remote" anymore.
      Instead, it unconditionally sends a cloned copy of the message to
      the receive function in the socket before, also unconditionally,
      sending it out on the broadcast link.
    - Renamed the clone+reassemly function in msg.c to 
      tipc_msg_reassemble().
    - #4:  Removed the initial lookup at the send side of a multicast.
      The lookup is now made only in one place, in tipc_sk_mcast_rcv().
    - I discovered that the current code violates the spec by completely
      ignoring the 'lookup scope' given to the message by the sender, and
      replacing it with hard-coded values. This is unfortunate, but
      I dare not change this now, so we will have to live with it.
    - Fixed two problems reported by Ying: a potential small memory leak,
      and a send failure due to a wrong return value from the multicast
      send function.

Jon Maloy (6):
  tipc: tipc: make name table distributor use new send function
  tipc: let internal link users call the new link send function
  tipc: add new functions for multicast and broadcast distribution
  tipc: start using the new multicast functions
  tipc: remove unreferenced functions
  tipc: rename temporarily named functions
(Continue reading)

Jon Maloy | 4 Jul 02:17 2014
Picon

[PATCH net-next 0/6] tipc: multicast and internal users to new send functions

In this series, we move the remaining data transmit users: multicast
data users, the name table distributor, and the link internal protocols
to use the new data transmission framework.

We also clean up the code obsoleted by the new functions.

Jon Maloy (6):
  tipc: tipc: make name table distributor use new send function
  tipc: let internal link users call the new link send function
  tipc: add new functions for multicast and broadcast distribution
  tipc: start using the new multicast functions
  tipc: remove unreferenced functions
  tipc: rename temporarily named functions

 net/tipc/bcast.c      |   60 ++++++----
 net/tipc/bcast.h      |    5 +-
 net/tipc/link.c       |  307 ++-----------------------------------------------
 net/tipc/link.h       |    9 +-
 net/tipc/msg.c        |   78 +++++++------
 net/tipc/msg.h        |    9 +-
 net/tipc/name_distr.c |   76 ++++++------
 net/tipc/name_distr.h |    2 +-
 net/tipc/name_table.c |   34 ++++++
 net/tipc/name_table.h |    2 +
 net/tipc/node.c       |   13 +--
 net/tipc/port.c       |  122 +-------------------
 net/tipc/port.h       |   10 --
 net/tipc/socket.c     |   93 +++++++++++----
 net/tipc/socket.h     |    2 +
 15 files changed, 259 insertions(+), 563 deletions(-)
(Continue reading)

erik.hugne | 2 Jul 14:06 2014
Picon

[PATCH v2] tipc: fix a memleak when sending data

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

This fixes a regression bug caused by:
067608e9d019d6477fd45dd948e81af0e5bf599f ("tipc: introduce direct
iovec to buffer chain fragmentation function")

If data is sent on a nonblocking socket and the destination link
is congested, the buffer chain is leaked. We fix this by freeing
the chain in this case.

Signed-off-by: Erik Hugne <erik.hugne <at> ericsson.com>
---
 net/tipc/socket.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/net/tipc/socket.c b/net/tipc/socket.c
index ede78b1..8c5600c 100644
--- a/net/tipc/socket.c
+++ b/net/tipc/socket.c
 <at>  <at>  -784,8 +784,9  <at>  <at>  new_mtu:
 			break;

 		rc = tipc_wait_for_sndmsg(sock, &timeo);
+		if (rc)
+			kfree_skb_list(buf);
 	} while (!rc);
-
 exit:
 	if (iocb)
 		release_sock(sk);
(Continue reading)


Gmane