* [PATCH net 1/1] tipc: fix problem with parallel link synchronization mechanism
@ 2015-04-28 20:59 Jon Maloy
2015-04-29 19:09 ` David Miller
0 siblings, 1 reply; 2+ messages in thread
From: Jon Maloy @ 2015-04-28 20:59 UTC (permalink / raw)
To: davem
Cc: netdev, Paul Gortmaker, erik.hugne, ying.xue, maloy,
tipc-discussion, Jon Maloy
Currently, we try to accumulate arrived packets in the links's
'deferred' queue during the parallel link syncronization phase.
This entails two problems:
- With an unlucky combination of arriving packets the algorithm
may go into a lockstep with the out-of-sequence handling function,
where the synch mechanism is adding a packet to the deferred queue,
while the out-of-sequence handling is retrieving it again, thus
ending up in a loop inside the node_lock scope.
- Even if this is avoided, the link will very often send out
unnecessary protocol messages, in the worst case leading to
redundant retransmissions.
We fix this by just dropping arriving packets on the upcoming link
during the synchronization phase, thus relying on the retransmission
protocol to resolve the situation once the two links have arrived to
a synchronized state.
Reviewed-by: Erik Hugne <erik.hugne@ericsson.com>
Reviewed-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
---
net/tipc/link.c | 7 ++-----
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/net/tipc/link.c b/net/tipc/link.c
index 57be6e6..f97c235 100644
--- a/net/tipc/link.c
+++ b/net/tipc/link.c
@@ -1145,11 +1145,8 @@ void tipc_rcv(struct net *net, struct sk_buff *skb, struct tipc_bearer *b_ptr)
}
/* Synchronize with parallel link if applicable */
if (unlikely((l_ptr->flags & LINK_SYNCHING) && !msg_dup(msg))) {
- link_handle_out_of_seq_msg(l_ptr, skb);
- if (link_synch(l_ptr))
- link_retrieve_defq(l_ptr, &head);
- skb = NULL;
- goto unlock;
+ if (!link_synch(l_ptr))
+ goto unlock;
}
l_ptr->next_in_no++;
if (unlikely(!skb_queue_empty(&l_ptr->deferdq)))
--
1.9.1
^ permalink raw reply related [flat|nested] 2+ messages in thread
* Re: [PATCH net 1/1] tipc: fix problem with parallel link synchronization mechanism
2015-04-28 20:59 [PATCH net 1/1] tipc: fix problem with parallel link synchronization mechanism Jon Maloy
@ 2015-04-29 19:09 ` David Miller
0 siblings, 0 replies; 2+ messages in thread
From: David Miller @ 2015-04-29 19:09 UTC (permalink / raw)
To: jon.maloy
Cc: netdev, paul.gortmaker, erik.hugne, ying.xue, maloy, tipc-discussion
From: Jon Maloy <jon.maloy@ericsson.com>
Date: Tue, 28 Apr 2015 16:59:04 -0400
> Currently, we try to accumulate arrived packets in the links's
> 'deferred' queue during the parallel link syncronization phase.
>
> This entails two problems:
>
> - With an unlucky combination of arriving packets the algorithm
> may go into a lockstep with the out-of-sequence handling function,
> where the synch mechanism is adding a packet to the deferred queue,
> while the out-of-sequence handling is retrieving it again, thus
> ending up in a loop inside the node_lock scope.
>
> - Even if this is avoided, the link will very often send out
> unnecessary protocol messages, in the worst case leading to
> redundant retransmissions.
>
> We fix this by just dropping arriving packets on the upcoming link
> during the synchronization phase, thus relying on the retransmission
> protocol to resolve the situation once the two links have arrived to
> a synchronized state.
>
> Reviewed-by: Erik Hugne <erik.hugne@ericsson.com>
> Reviewed-by: Ying Xue <ying.xue@windriver.com>
> Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Applied, thanks Jon.
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2015-04-29 19:09 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-04-28 20:59 [PATCH net 1/1] tipc: fix problem with parallel link synchronization mechanism Jon Maloy
2015-04-29 19:09 ` David Miller
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).