(added Ying and tipc_discussion to thread)
Hi Tung,
The purpose of the 'filter' argument is to reduce the risk that two threads
simultaneously try to deliver messages to the same socket, with unnecessary
contention as result:
The algorithm goes as follows:
1: thread 1: tipc_skb_rcv()
2: thread 1: peek head of inputq queue to find the destination port of the
first message
If thread 2 tries to peek here, it will likely get the same port and try
to deliver to the same socket. We will have contention.
3: thread 1: Let tipc_sk_enqueue() dequeue (from inputq), filter and enqueue
(into sk_rcv_queue) all, or as many as can be processed during 2 ms, messages
destined for that same destination port.
If thread 2 tries to peek during the 2 ms interval, chances are good
that it will peek a different destination to work on.
4: thread 1 : Peek input queue again, this time ignoring messages for the
previous destination port, if any, and all messages in the input queue ahead
of the first message for that port.
If thread 2 tries to peek here and finds dest port 1, or if it was
already working on it, it is ok, because thread 1 will not be working on it at
this moment.
5: thread 1: Let tipc_sk_enqueue() handle all message for the new destination
port.
6: thread 1: Peek again, now ignoring the second destination port. The result
now may be a third destination port, but it may also be the first one, if there
are any messages for it.
To set the filter to 0 before in each call to tipc_skb_peek() would make this
parameter useless, as all thread always would end up with peeking the first
message/destination port from the queue anyway. So, this is not a good idea.
That said, the algorithm is far from perfect, and an improvement wouldn't hurt.
I wonder if we could find a way to *guarantee* that two threads never work on
the same socket? I am open to suggestions.
BR
///jon
From: tung quang nguyen [mailto:[email protected]]
Sent: Monday, March 05, 2018 06:17
To: Jon Maloy <[email protected]>
Cc: Canh Duc Luu <[email protected]>; Hoang Huu Le
<[email protected]>; Mohan Krishna Ghanta Krishnamurthy
<[email protected]>
Subject: tipc: improve socket rcv function
In tipc_sk_rcv() function, after 1 skb is consumed by
tipc_sk_enqueue(), its destination port is passed
to tipc_skb_peek_port() as a filter. If there are
consecutive skb(s) of the same port in skb list,
they will not be consumed later on though socket lock
is not held by user. This costs overhead for other skb
list iterations.
This commit fixes it by resetting the filter after each
skb consumption.
Signed-off-by: Tung Nguyen
<[email protected]<mailto:[email protected]>>
---
net/tipc/socket.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/tipc/socket.c b/net/tipc/socket.c
index f934771..032315e 100644
--- a/net/tipc/socket.c
+++ b/net/tipc/socket.c
@@ -2233,6 +2233,7 @@ void tipc_sk_rcv(struct net *net, struct sk_buff_head
*inputq)
if (likely(spin_trylock_bh(&sk->sk_lock.slock))) {
tipc_sk_enqueue(inputq, sk, dport, &xmitq);
spin_unlock_bh(&sk->sk_lock.slock);
+ dport = 0;
}
/* Send pending response/rejected messages, if any */
tipc_node_distr_xmit(sock_net(sk), &xmitq);
--
2.1.4
--
Best regards,
Tung Nguyen
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
tipc-discussion mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/tipc-discussion
