erik.hugne | 18 Dec 17:44 2014
Picon

[PATCH 0/5] tipc: add IPv4/UDP bearer support

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

This have probably been idling for a few years by now.. and i just stumbled
upon this which caused me to do a resend of the udp set:
https://www.buckhill.co.uk/blog/how-to-enable-broadcast-and-multicast-on-amazon-aws-ec2/2#.VJMCGB-c1hE

I haven't changed much (hardly anything) since last round. Ying
wanted to have UDP bearer opt-in, but i disagree with that and
kept it always-on. He also had a point about the deferred setup
work that i have not addressed yet.
http://thread.gmane.org/gmane.network.tipc.general/7238/focus=7244

I know IPv6 is missing, but i think that adding that (and all MLD
stuff needed for mcast discovery) is best saved for a followup
patchset.

Going on christmas holiday tomorrow, back 7'th of January. If net-next
is open by then i will send it off.

Erik Hugne (5):
  tipc: rename media/msg related definitions
  tipc: make media address offset a common define
  tipc: allow ':' character in link names
  tipc: expand interface/bearer/link name limits
  tipc: add ip/udp media type

 include/uapi/linux/tipc.h |  12 +-
 net/tipc/Makefile         |   2 +-
 net/tipc/bearer.c         |   1 +
 net/tipc/bearer.h         |  11 +-
(Continue reading)

Ying Xue | 15 Dec 09:50 2014

[PATCH net-next v2] tipc: convert tipc reference table to use generic rhashtable

As now tipc reference table is statically allocated, its memory size
requested on stack initialization stage is quite big even if it only
allows port numbers to reach its maximum value - 8191 although tipc
can support the maximum ports to 2^32 in theory. In addition, heavy
tipc users spend a considerable amount of time in tipc_sk_get() due
to the read-lock on ref_table_lock.

To relieve the lock contention, we makes use of the new resizable
hash table to avoid locking on the lookup. Meanwhile, another benefit
obtained from the conversion is that smaller memory size is required
from the beginning than the way of static allocation port, such as,
256 hash bucket slots are requested initially instead of allocating the
entire 8191 slots in old mode. Additionally, the hash table will grow
if entries exceeds 75% of table size up to a total table size of 1M.
It will automatically shrink if usage falls below 30%, but the minimum
table size is allowed down to 256.

Also splits ref_table_lock into a separate mutex to protect hash table
mutations and allow synchronize_rcu() to sleep while waiting for readers
during expansion and shrinking. Meanwhile, before socket is destroyed
through calling sock_put() in tipc_release(), synchronize_rcu() should
be called to wait for all readers' accomplishment for socket access.
However, synchronize_rcu() is so expensive that the performance of
closing socket is unacceptable. To resolve the issue, socket is
asynchronously destroyed in tipc_release() by calling call_rcu(), that
is, the time really freeing socket instance is postponed to the moment
when no user depends on the socket.

Signed-off-by: Ying Xue <ying.xue <at> windriver.com>
---
(Continue reading)

Ying Xue | 11 Dec 08:22 2014

[PATCH] tipc: simplify tipc socket wakeup mechanism

Currently when tipc socket sends messages through link, link may be
congested as its outgoing queue length exceeds its persetting
threshold. Once link congestion occurs, link first inserts the socket
to its socket waiting list and returns link congested status to the
socket sending function so that it will be blocked until tipc
SOCK_WAKEUP message from link is received. Meanwhile, when link
outgoing queue length is reduced due to the arrival of acknowledgment
message from remote node, link will create a SOCK_WAKEUP message and
dispatch it to socket in order to wake up corresponding blocked socket.

The most disadvantage of the wakeup mechanism is too complex, such as
link and node must maintain two socket waiting list. Instead, if all
SKBs generated with tipc_msg_build() are initialized with
skb_set_owner_w(), their "skb->destructor" fields are set
with sock_wfree(). When link releases SKBs stored in its outgoing
queue with kfree_skb() as acknowledgment messages are received,
sock_wfree() will be called through kfree_skb(). As the sock_wfree
function pointer was already initialized with tipc_write_space() on
socket creation, all relevant blocked sockets will be woken up by
tipc_write_space(). As no waiting lists and no SOCK_WAKEUP messages
in the latter method exist, it cna help us extremely simplify tipc
socket wakeup mechanism.

Signed-off-by: Ying Xue <ying.xue <at> windriver.com>
---
 net/tipc/bcast.c  |   21 ----------------
 net/tipc/bcast.h  |    1 -
 net/tipc/link.c   |   72 ++++++-----------------------------------------------
 net/tipc/link.h   |    3 ---
 net/tipc/msg.h    |    4 ---
(Continue reading)

erik.hugne | 10 Dec 15:58 2014
Picon

[PATCH] tipc: eliminate unnecessary wakeup events

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

If a link was congested at the time of send(), generate a single
wakeup event only. the 'link_cong' socket flag is used to track if
wakeups have already been scheduled.

Signed-off-by: Erik Hugne <erik.hugne <at> ericsson.com>
---
 net/tipc/core.h   |  2 +-
 net/tipc/link.c   |  2 +-
 net/tipc/socket.c | 15 +++++++++++++--
 3 files changed, 15 insertions(+), 4 deletions(-)

diff --git a/net/tipc/core.h b/net/tipc/core.h
index 8460213..ea3e96a 100644
--- a/net/tipc/core.h
+++ b/net/tipc/core.h
 <at>  <at>  -191,7 +191,7  <at>  <at>  struct tipc_skb_cb {
 	void *handle;
 	struct sk_buff *tail;
 	bool deferred;
-	bool wakeup_pending;
+	bool wakeup;
 	bool bundling;
 	u16 chain_sz;
 	u16 chain_imp;
diff --git a/net/tipc/link.c b/net/tipc/link.c
index 23bcc11..4758208 100644
--- a/net/tipc/link.c
+++ b/net/tipc/link.c
(Continue reading)

Jon Maloy | 9 Dec 22:05 2014
Picon

[PATCH net-next v4 0/8] tipc: resolve message disordering problem

When TIPC receives messages from multi-threaded device drivers it may
occasionally deliver messages to their destination sockets in the wrong
order. This happens despite correct resequencing at the link layer,
because the upcall path from link to socket is not protected by any
locks.

These commits solve this problem by introducing an 'input' message
queue in each link, though which messages must be delivered to the
upper layers.

Note that although the first four commits may look unrelated to the
above, they should be seen as preparation steps facilitating the later
commits.

v3:
   - Commit #1:    Changed names on some stack variables, as suggested by
                   Ying
   - Commit #2/3:  Moved introduction of function -tipc_sk_enqueue_msg()
                   to #2, to make it cleaner. I did NOT re-introduce the
                   'exit' label in tipc_sk_rcv(), because it would end up
                   inside a loop, something I consider an abomination.
   - Commit #6:    Realizing that we may have to kick several input
                   queues at the same reception occasion, I introduced a
                   new bit map 'inputq_map' in node::bclink, indicating
                   which input queues need to be delivered. This is
                   because messages extracted from the same bundle may
                   have different originating port, and will end up
                   in different queues.

v4: - Introduced new commit #3, where we avoid allocating and initializing
(Continue reading)

erik.hugne | 9 Dec 15:53 2014
Picon

[PATCH v3] tipc: refactor tipc_bclink_xmit

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

Small simplification/cosmetic change to the broadcast send function
where we replace the redundant bc flag and check with a else/goto
clause.

Signed-off-by: Erik Hugne <erik.hugne <at> ericsson.com>
Reviewed-by: Ying Xue <ying.xue <at> windriver.com>
Reviewed-by: Jon Maloy <jon.maloy <at> ericsson.com>
---
v3: Resend of v2, fixed syntax error...

Had to do a respin of this, changes in v2:
If we return -ELINKCONG the skb list must not be freed.

 net/tipc/bcast.c | 24 +++++++++++-------------
 1 file changed, 11 insertions(+), 13 deletions(-)

diff --git a/net/tipc/bcast.c b/net/tipc/bcast.c
index 96ceefe..df19352 100644
--- a/net/tipc/bcast.c
+++ b/net/tipc/bcast.c
 <at>  <at>  -408,14 +408,13  <at>  <at>  static void bclink_peek_nack(struct tipc_msg *msg)
 int tipc_bclink_xmit(struct sk_buff_head *list)
 {
 	int rc = 0;
-	int bc = 0;
 	struct sk_buff *skb;

 	/* Prepare clone of message for local node */
(Continue reading)

erik.hugne | 9 Dec 15:46 2014
Picon

[PATCH v2] tipc: refactor tipc_bclink_xmit

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

Small simplification/cosmetic change to the broadcast send function
where we replace the redundant bc flag and check with a else/goto
clause.

Signed-off-by: Erik Hugne <erik.hugne <at> ericsson.com>
Reviewed-by: Ying Xue <ying.xue <at> windriver.com>
Reviewed-by: Jon Maloy <jon.maloy <at> ericsson.com>
---
Had to do a respin of this, changes in v2:
If we return -ELINKCONG the skb list must not be freed.

 net/tipc/bcast.c | 24 +++++++++++-------------
 1 file changed, 11 insertions(+), 13 deletions(-)

diff --git a/net/tipc/bcast.c b/net/tipc/bcast.c
index 96ceefe..053a1c8 100644
--- a/net/tipc/bcast.c
+++ b/net/tipc/bcast.c
 <at>  <at>  -408,14 +408,13  <at>  <at>  static void bclink_peek_nack(struct tipc_msg *msg)
 int tipc_bclink_xmit(struct sk_buff_head *list)
 {
 	int rc = 0;
-	int bc = 0;
 	struct sk_buff *skb;

 	/* Prepare clone of message for local node */
 	skb = tipc_msg_reassemble(list);
 	if (unlikely(!skb)) {
(Continue reading)

Ying Xue | 9 Dec 08:54 2014

[PATCH net-next] tipc: staticze tipc_node_abort_sock_conns routine

tipc_node_abort_sock_conns() is only used locally, so mark it as
'static' to fix the following sparse warning:

net/tipc/node.c:204:6: warning: symbol 'tipc_node_abort_sock_conns' was not declared. Should it be static?

Signed-off-by: Ying Xue <ying.xue <at> windriver.com>
---
 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 69b96be..d5352b5 100644
--- a/net/tipc/node.c
+++ b/net/tipc/node.c
 <at>  <at>  -201,7 +201,7  <at>  <at>  void tipc_node_remove_conn(u32 dnode, u32 port)
 	tipc_node_unlock(node);
 }

-void tipc_node_abort_sock_conns(struct list_head *conns)
+static void tipc_node_abort_sock_conns(struct list_head *conns)
 {
 	struct tipc_sock_conn *conn, *safe;
 	struct sk_buff *buf;
--

-- 
1.7.9.5

------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
(Continue reading)

Erik Hugne | 8 Dec 11:09 2014
Picon

Redundant SOCK_WAKEUP's generated

The internal wakeup messages, generated as a response to link congestion to
wake up the sending socket once congestion has abated are also generated for
sockets with O_NONBLOCK set, and messages with MSG_DONTWAIT.
This serves no purpose, and i'd like to discuss ways of supressing the
generation of these.

First thing that comes to mind is adding an extra parameter to the *link_xmit
functions (and passing this further down the callchain) to indicate if wakeup's
should be generated, but maybe there are better ways of dealing with this?

//E

------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
Aho, Tero | 8 Dec 10:50 2014

Testing namespaces, part 3, hard/soft lockups

When running tipc in multiple namespaces I sometimes get hard/soft
lockups. I think this just might be the final issue left for
namespace support. However, I just cannot point out the bug but
maybe you tipc locking experts can see what goes wrong here.

Here's where it starts:

[ 1564.144837] BUG: spinlock lockup suspected on CPU#2, migration/2/164
[ 1564.144881]  lock: 0xffff880d89bb4e08, .magic: dead4ead, .owner: LU-APPI/13179, .owner_cpu: 9
[ 1564.144951] CPU: 2 PID: 164 Comm: migration/2 Tainted: G        W   EL 3.17.1+coriant.3+ #1
[ 1564.144953] Hardware name: Dell Inc. PowerEdge R420/0K29HN, BIOS 2.1.2 01/20/2014
[ 1564.144954]  ffff880d89bb4e08 ffff88080d003c10 ffffffff817ab802 ffff880cc347cb80
[ 1564.144959]  ffff88080d003c30 ffffffff817a7770 ffff880d89bb4e08 000000008f63a828
[ 1564.144964]  ffff88080d003c58 ffffffff810c4669 ffff880d89bb4e08 ffff880d89bb4e20
[ 1564.144968] Call Trace:
[ 1564.144969]  <IRQ>  [<ffffffff817ab802>] dump_stack+0x4d/0x6f
[ 1564.144976]  [<ffffffff817a7770>] spin_dump+0x91/0x96
[ 1564.144979]  [<ffffffff810c4669>] do_raw_spin_lock+0x79/0x170
[ 1564.144982]  [<ffffffff817b50b4>] _raw_spin_lock_bh+0x64/0x80
[ 1564.144984]  [<ffffffff81778392>] ? tipc_bclink_rcv+0x512/0x560
[ 1564.144987]  [<ffffffff81778392>] tipc_bclink_rcv+0x512/0x560
[ 1564.144990]  [<ffffffff81777e85>] ? tipc_bclink_rcv+0x5/0x560
[ 1564.144993]  [<ffffffff8177f625>] ? tipc_rcv+0x5/0xaa0
[ 1564.144996]  [<ffffffff8177ff62>] tipc_rcv+0x942/0xaa0
[ 1564.144998]  [<ffffffff8177f625>] ? tipc_rcv+0x5/0xaa0
[ 1564.145001]  [<ffffffff81779655>] ? tipc_l2_rcv_msg+0x5/0xd0
[ 1564.145003]  [<ffffffff817796be>] tipc_l2_rcv_msg+0x6e/0xd0
[ 1564.145005]  [<ffffffff81779655>] ? tipc_l2_rcv_msg+0x5/0xd0
[ 1564.145008]  [<ffffffff81682422>] __netif_receive_skb_core+0x602/0x810
[ 1564.145010]  [<ffffffff81681e74>] ? __netif_receive_skb_core+0x54/0x810
(Continue reading)

Klemen Pogacnik | 5 Dec 18:50 2014
Picon

Re: MAX number of interfaces on one node

We've already have two ethernet interfaces which are used for communication
between nodes in the same LAN. If I add usb interface (or vxlan), which
would be used for communication between geographically allocated nodes,
this is the 3rd interface.
I'll try what will happen if I set this constant to 3 or 4.
Regards! Klemen

On 5 Dec 2014 15:31, "Erik Hugne" <erik.hugne <at> ericsson.com> wrote:
>>
>> On Fri, Dec 05, 2014 at 12:19:31PM +0100, Klemen Pogacnik wrote:
>> > I tried to configure a node with more then 2 bearer interfaces, but
system
>> > rejected it. I haven't find this limitation in TIPC documentation, so I
>> > checked code.
>> > A constant MAX_BEARERS is defined in bearer.h, it's value is 2. Is
there
>> > any reason to have this limitation so low? Is it possible to change
this
>> > constant?
>>
>> Certainly possible, but i'm unaware of anyone testing with more than 2,
i have
>> no idea what will happen :)
>>
>> I'm guessing you want to increase this to be able to set up several
unicast
>> UDP bearers?
>>
>>
>> //E
(Continue reading)


Gmane