All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
To: Xin Long <lucien.xin@gmail.com>
Cc: network dev <netdev@vger.kernel.org>,
	linux-sctp@vger.kernel.org, Neil Horman <nhorman@tuxdriver.com>,
	davem@davemloft.net, Matteo Croce <mcroce@redhat.com>,
	Vladis Dronov <vdronov@redhat.com>
Subject: Re: [PATCH net-next 1/2] sctp: implement memory accounting on tx path
Date: Tue, 02 Apr 2019 11:48:09 +0000	[thread overview]
Message-ID: <20190402114809.GP16876@localhost.localdomain> (raw)
In-Reply-To: <57b7c29e160acf1a7e5f86ae8549b23ba8946c4b.1554022192.git.lucien.xin@gmail.com>

On Sun, Mar 31, 2019 at 04:53:46PM +0800, Xin Long wrote:
> Now when sending packets, sk_mem_charge() and sk_mem_uncharge() have been
> used to set sk_forward_alloc. We just need to call sk_wmem_schedule() to
> check if the allocated should be raised, and call sk_mem_reclaim() to
> check if the allocated should be reduced when it's under memory pressure.
> 
> If sk_wmem_schedule() returns false, which means no memory is allowed to
> allocate, it will block and wait for memory to become available.
> 
> Note different from tcp, sctp wait_for_buf happens before allocating any
> skb, so memory accounting check is done with the whole msg_len before it
> too.
> 
> Signed-off-by: Xin Long <lucien.xin@gmail.com>

Acked-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>

> ---
>  net/sctp/socket.c | 10 ++++++++--
>  1 file changed, 8 insertions(+), 2 deletions(-)
> 
> diff --git a/net/sctp/socket.c b/net/sctp/socket.c
> index 6140471..06c6f4a 100644
> --- a/net/sctp/socket.c
> +++ b/net/sctp/socket.c
> @@ -1913,7 +1913,10 @@ static int sctp_sendmsg_to_asoc(struct sctp_association *asoc,
>  	if (sctp_wspace(asoc) < (int)msg_len)
>  		sctp_prsctp_prune(asoc, sinfo, msg_len - sctp_wspace(asoc));
>  
> -	if (sctp_wspace(asoc) <= 0) {
> +	if (sk_under_memory_pressure(sk))
> +		sk_mem_reclaim(sk);
> +
> +	if (sctp_wspace(asoc) <= 0 || !sk_wmem_schedule(sk, msg_len)) {
>  		timeo = sock_sndtimeo(sk, msg->msg_flags & MSG_DONTWAIT);
>  		err = sctp_wait_for_sndbuf(asoc, &timeo, msg_len);
>  		if (err)
> @@ -8891,7 +8894,10 @@ static int sctp_wait_for_sndbuf(struct sctp_association *asoc, long *timeo_p,
>  			goto do_error;
>  		if (signal_pending(current))
>  			goto do_interrupted;
> -		if ((int)msg_len <= sctp_wspace(asoc))
> +		if (sk_under_memory_pressure(sk))
> +			sk_mem_reclaim(sk);
> +		if ((int)msg_len <= sctp_wspace(asoc) &&
> +		    sk_wmem_schedule(sk, msg_len))
>  			break;
>  
>  		/* Let another process have a go.  Since we are going
> -- 
> 2.1.0
> 

WARNING: multiple messages have this Message-ID (diff)
From: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
To: Xin Long <lucien.xin@gmail.com>
Cc: network dev <netdev@vger.kernel.org>,
	linux-sctp@vger.kernel.org, Neil Horman <nhorman@tuxdriver.com>,
	davem@davemloft.net, Matteo Croce <mcroce@redhat.com>,
	Vladis Dronov <vdronov@redhat.com>
Subject: Re: [PATCH net-next 1/2] sctp: implement memory accounting on tx path
Date: Tue, 2 Apr 2019 08:48:09 -0300	[thread overview]
Message-ID: <20190402114809.GP16876@localhost.localdomain> (raw)
In-Reply-To: <57b7c29e160acf1a7e5f86ae8549b23ba8946c4b.1554022192.git.lucien.xin@gmail.com>

On Sun, Mar 31, 2019 at 04:53:46PM +0800, Xin Long wrote:
> Now when sending packets, sk_mem_charge() and sk_mem_uncharge() have been
> used to set sk_forward_alloc. We just need to call sk_wmem_schedule() to
> check if the allocated should be raised, and call sk_mem_reclaim() to
> check if the allocated should be reduced when it's under memory pressure.
> 
> If sk_wmem_schedule() returns false, which means no memory is allowed to
> allocate, it will block and wait for memory to become available.
> 
> Note different from tcp, sctp wait_for_buf happens before allocating any
> skb, so memory accounting check is done with the whole msg_len before it
> too.
> 
> Signed-off-by: Xin Long <lucien.xin@gmail.com>

Acked-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>

> ---
>  net/sctp/socket.c | 10 ++++++++--
>  1 file changed, 8 insertions(+), 2 deletions(-)
> 
> diff --git a/net/sctp/socket.c b/net/sctp/socket.c
> index 6140471..06c6f4a 100644
> --- a/net/sctp/socket.c
> +++ b/net/sctp/socket.c
> @@ -1913,7 +1913,10 @@ static int sctp_sendmsg_to_asoc(struct sctp_association *asoc,
>  	if (sctp_wspace(asoc) < (int)msg_len)
>  		sctp_prsctp_prune(asoc, sinfo, msg_len - sctp_wspace(asoc));
>  
> -	if (sctp_wspace(asoc) <= 0) {
> +	if (sk_under_memory_pressure(sk))
> +		sk_mem_reclaim(sk);
> +
> +	if (sctp_wspace(asoc) <= 0 || !sk_wmem_schedule(sk, msg_len)) {
>  		timeo = sock_sndtimeo(sk, msg->msg_flags & MSG_DONTWAIT);
>  		err = sctp_wait_for_sndbuf(asoc, &timeo, msg_len);
>  		if (err)
> @@ -8891,7 +8894,10 @@ static int sctp_wait_for_sndbuf(struct sctp_association *asoc, long *timeo_p,
>  			goto do_error;
>  		if (signal_pending(current))
>  			goto do_interrupted;
> -		if ((int)msg_len <= sctp_wspace(asoc))
> +		if (sk_under_memory_pressure(sk))
> +			sk_mem_reclaim(sk);
> +		if ((int)msg_len <= sctp_wspace(asoc) &&
> +		    sk_wmem_schedule(sk, msg_len))
>  			break;
>  
>  		/* Let another process have a go.  Since we are going
> -- 
> 2.1.0
> 

  parent reply	other threads:[~2019-04-02 11:48 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-31  8:53 [PATCH net-next 0/2] sctp: fully support memory accounting Xin Long
2019-03-31  8:53 ` Xin Long
2019-03-31  8:53 ` [PATCH net-next 1/2] sctp: implement memory accounting on tx path Xin Long
2019-03-31  8:53   ` Xin Long
2019-03-31  8:53   ` [PATCH net-next 2/2] sctp: implement memory accounting on rx path Xin Long
2019-03-31  8:53     ` Xin Long
2019-04-02 11:48     ` Marcelo Ricardo Leitner
2019-04-02 11:48       ` Marcelo Ricardo Leitner
2019-04-02 11:48   ` Marcelo Ricardo Leitner [this message]
2019-04-02 11:48     ` [PATCH net-next 1/2] sctp: implement memory accounting on tx path Marcelo Ricardo Leitner
2019-03-31  8:56 ` [PATCH net-next 0/2] sctp: fully support memory accounting Xin Long
2019-03-31  8:56   ` Xin Long
2019-03-31 18:02   ` David Miller
2019-03-31 18:02     ` David Miller
2019-04-04  9:45     ` Xin Long
2019-04-04  9:45       ` Xin Long
2019-04-04 17:38       ` David Miller
2019-04-04 17:38         ` David Miller
2019-04-05  4:49         ` Xin Long
2019-04-05  4:49           ` Xin Long
2019-03-31 19:22 ` Matteo Croce
2019-03-31 19:22   ` Matteo Croce
2019-03-31 20:10 ` Marcelo Ricardo Leitner
2019-03-31 20:10   ` Marcelo Ricardo Leitner
2019-03-31 21:04   ` David Miller
2019-03-31 21:04     ` David Miller
2019-04-01  7:25 ` Xin Long
2019-04-01  7:25   ` Xin Long
2019-04-01 11:31 ` Neil Horman
2019-04-01 11:31   ` Neil Horman
2019-04-02  3:36   ` Marcelo Ricardo Leitner
2019-04-02  3:36     ` Marcelo Ricardo Leitner
2019-04-02 11:41     ` Neil Horman
2019-04-02 11:41       ` Neil Horman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190402114809.GP16876@localhost.localdomain \
    --to=marcelo.leitner@gmail.com \
    --cc=davem@davemloft.net \
    --cc=linux-sctp@vger.kernel.org \
    --cc=lucien.xin@gmail.com \
    --cc=mcroce@redhat.com \
    --cc=netdev@vger.kernel.org \
    --cc=nhorman@tuxdriver.com \
    --cc=vdronov@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.