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 <[email protected]>
> Sent: 1-Apr-19 04:47
> To: [email protected]; Jon Maloy
> <[email protected]>; [email protected]; [email protected]
> 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 <[email protected]>
> ---
>  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
[email protected]
https://lists.sourceforge.net/lists/listinfo/tipc-discussion

Reply via email to