On 10/05/2016 05:25 PM, Jon Maloy wrote: > > >> -----Original Message----- >> From: Parthasarathy Bhuvaragan >> Sent: Wednesday, 05 October, 2016 04:18 >> To: Jon Maloy <jon.ma...@ericsson.com>; >> tipc-discussion@lists.sourceforge.net; >> ma...@donjonn.com; Ying Xue <ying....@windriver.com> >> Subject: Re: [PATCH net v1 2/3] tipc: return early for non-blocking sockets >> at link >> congestion >> >> On 10/04/2016 09:26 PM, Jon Maloy wrote: >>> >>> >>>> -----Original Message----- >>>> From: Parthasarathy Bhuvaragan >>>> Sent: Tuesday, 04 October, 2016 08:29 >>>> To: tipc-discussion@lists.sourceforge.net; Jon Maloy >> <jon.ma...@ericsson.com>; >>>> ma...@donjonn.com; Ying Xue <ying....@windriver.com> >>>> Subject: [PATCH net v1 2/3] tipc: return early for non-blocking sockets at >>>> link >>>> congestion >>>> >>>> Until now, in stream/mcast send() we pass the message to the link >>>> layer even when the link is congested and add the socket to the >>>> link's wakeup queue. This is unnecessary for non-blocking sockets. >>>> If a socket is set to non-blocking and sends multicast with zero >>>> back off time while receiving EAGAIN, we exhaust the memory. >>>> >>>> In this commit, we return immediately at stream/mcast send() for >>>> non-blocking sockets. >>>> >>>> Signed-off-by: Parthasarathy Bhuvaragan >>>> <parthasarathy.bhuvara...@ericsson.com> >>>> --- >>>> net/tipc/socket.c | 6 ++++++ >>>> 1 file changed, 6 insertions(+) >>>> >>>> diff --git a/net/tipc/socket.c b/net/tipc/socket.c >>>> index f9f5f3c3dab5..adf3e6ecf61e 100644 >>>> --- a/net/tipc/socket.c >>>> +++ b/net/tipc/socket.c >>>> @@ -697,6 +697,9 @@ static int tipc_sendmcast(struct socket *sock, struct >>>> tipc_name_seq *seq, >>>> uint mtu; >>>> int rc; >>>> >>>> + if (!timeo && tsk->link_cong) >>>> + return -ELINKCONG; >>> >>> Why is the !timeo test needed ? >> [partha] When a socket with a non-zero sndtimeo experiences congestion, >> the socket is put to sleep for the specified duration and is woken if >> congestion ceases and we attempt to transmit the buffer. If we had >> experienced congestion for the entire duration, then we return >> ELINKLCONG to the user. Hence I can return immediately only when timeout >> == 0. > > Are you saying that we can have non-blocking sockets with a non-zero timeout? > I guess my point was that if the socket is blocking, i.e., the timeout is != > 0, you will never get into this second call in the first place, since the > socket already is blocked if sk->link_cong is true. Hence no need for testing > on the timer value. Unsure if this is valid with multiple threads though. [partha] zero timeout means that either the socket is non-blocking or this message has MSG_DONTWAIT flag set (irrespective of the socket being blocking or non-blocking). From the timeout I derive that this user has no intention of waiting. For multi-threaded applications, each thread can call a blocking sendmsg() or call sendmsg() with MSG_DONTWAIT flag or use several thread instances of both. The fix should cover all the above. > >>> >>> ///jon >>> >>>> + >>>> msg_set_type(mhdr, TIPC_MCAST_MSG); >>>> msg_set_lookup_scope(mhdr, TIPC_CLUSTER_SCOPE); >>>> msg_set_destport(mhdr, 0); >>>> @@ -1072,6 +1075,9 @@ static int __tipc_send_stream(struct socket *sock, >>>> struct msghdr *m, size_t dsz) >>>> } >>>> >>>> timeo = sock_sndtimeo(sk, m->msg_flags & MSG_DONTWAIT); >>>> + if (!timeo && tsk->link_cong) >>>> + return -ELINKCONG; >>>> + >>>> dnode = tsk_peer_node(tsk); >>>> skb_queue_head_init(&pktchain); >>>> >>>> -- >>>> 2.1.4 >>>
------------------------------------------------------------------------------ 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 tipc-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tipc-discussion
