Hi Tung, I am afraid we will have to define a new socket option for this. Although the risk probably is very low, we don't want to break any possible users who are designed from the assumption that it received messages, not bytes.
BR ///jon > -----Original Message----- > From: Tung Nguyen <tung.q.ngu...@dektech.com.au> > Sent: 1-Apr-19 04:47 > To: tipc-discussion@lists.sourceforge.net; Jon Maloy > <jon.ma...@ericsson.com>; ma...@donjonn.com; ying....@windriver.com > Subject: [tipc-discussion][PATCH v1 1/1] tipc: return allocated buffer when > using TIPC_SOCK_RECVQ_DEPTH > > When using TIPC_SOCK_RECVQ_DEPTH for getsockopt(), it returns the > number of buffer elements in receive socket buffer which is not so helpful > for user applications. > > By returning the current number of allocated bytes of the receive socket > buffer, applications can dimension its buffer usage to avoid buffer overload > issue. > > Signed-off-by: Tung Nguyen <tung.q.ngu...@dektech.com.au> > --- > net/tipc/socket.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/net/tipc/socket.c b/net/tipc/socket.c index > b542f14ed444..43a60a808493 100644 > --- a/net/tipc/socket.c > +++ b/net/tipc/socket.c > @@ -3062,7 +3062,7 @@ static int tipc_getsockopt(struct socket *sock, int > lvl, int opt, > value = 0; /* was tipc_queue_size, now obsolete */ > break; > case TIPC_SOCK_RECVQ_DEPTH: > - value = skb_queue_len(&sk->sk_receive_queue); > + value = sk_rmem_alloc_get(sk); > break; > case TIPC_GROUP_JOIN: > seq.type = 0; > -- > 2.17.1 _______________________________________________ tipc-discussion mailing list tipc-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tipc-discussion
