> -Original Message-
> From: Parthasarathy Bhuvaragan
> Sent: Thursday, 06 October, 2016 04:35
> To: Jon Maloy ; tipc-discussion@lists.sourceforge.net;
> ma...@donjonn.com; Ying Xue
> Subject: Re: [PATCH net v1 2/3] tipc: return early for non-blocking sockets
> at link
> congestion
>
>
>
> 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 ; tipc-
> discuss...@lists.sourceforge.net;
> >> ma...@donjonn.com; Ying Xue
> >> 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
> >> ;
> ma...@donjonn.com; Ying Xue
> 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
>
> ---
> 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.
Ok. It seems I haven't fully understood this aspect of the API.
Acked-by: jon
> >
> >>>
> >>> ///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
