netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Vlad Yasevich <vyasevich@gmail.com>
To: David Laight <David.Laight@ACULAB.COM>,
	"'netdev@vger.kernel.org'" <netdev@vger.kernel.org>,
	"'linux-sctp@vger.kernel.org'" <linux-sctp@vger.kernel.org>
Cc: "'davem@davemloft.net'" <davem@davemloft.net>
Subject: Re: [PATCH v2 net-next 1/3] net: sctp: Open out the check for Nagle
Date: Fri, 11 Jul 2014 16:01:04 -0400	[thread overview]
Message-ID: <53C04280.8020809@gmail.com> (raw)
In-Reply-To: <063D6719AE5E284EB5DD2968C1650D6D1726EEB9@AcuExch.aculab.com>

On 07/09/2014 04:29 AM, David Laight wrote:
> The check for Nagle contains 6 separate checks all of which must be true
> before a data packet is delayed.
> Separate out each into its own 'if (test) return SCTP_XMIT_OK' so that
> the reasons can be individually described.
> 
> Also return directly with SCTP_XMIT_RWND_FULL.
> Delete the now-unused 'retval' variable and 'finish' label from
> sctp_packet_can_append_data().
> 
> Signed-off-by: David Laight <david.laight@aculab.com>
> ---
>  net/sctp/output.c | 69 +++++++++++++++++++++++++++++--------------------------
>  1 file changed, 36 insertions(+), 33 deletions(-)
> 
> diff --git a/net/sctp/output.c b/net/sctp/output.c
> index 0f4d15f..553ba1d 100644
> --- a/net/sctp/output.c
> +++ b/net/sctp/output.c
> @@ -633,7 +633,6 @@ nomem:
>  static sctp_xmit_t sctp_packet_can_append_data(struct sctp_packet *packet,
>  					   struct sctp_chunk *chunk)
>  {
> -	sctp_xmit_t retval = SCTP_XMIT_OK;
>  	size_t datasize, rwnd, inflight, flight_size;
>  	struct sctp_transport *transport = packet->transport;
>  	struct sctp_association *asoc = transport->asoc;
> @@ -658,15 +657,11 @@ static sctp_xmit_t sctp_packet_can_append_data(struct sctp_packet *packet,
>  
>  	datasize = sctp_data_size(chunk);
>  
> -	if (datasize > rwnd) {
> -		if (inflight > 0) {
> -			/* We have (at least) one data chunk in flight,
> -			 * so we can't fall back to rule 6.1 B).
> -			 */
> -			retval = SCTP_XMIT_RWND_FULL;
> -			goto finish;
> -		}
> -	}
> +	if (datasize > rwnd && inflight > 0)
> +		/* We have (at least) one data chunk in flight,
> +		 * so we can't fall back to rule 6.1 B).
> +		 */
> +		return SCTP_XMIT_RWND_FULL;
>  
>  	/* RFC 2960 6.1  Transmission of DATA Chunks
>  	 *
> @@ -680,36 +675,44 @@ static sctp_xmit_t sctp_packet_can_append_data(struct sctp_packet *packet,
>  	 *    When a Fast Retransmit is being performed the sender SHOULD
>  	 *    ignore the value of cwnd and SHOULD NOT delay retransmission.
>  	 */
> -	if (chunk->fast_retransmit != SCTP_NEED_FRTX)
> -		if (flight_size >= transport->cwnd) {
> -			retval = SCTP_XMIT_RWND_FULL;
> -			goto finish;
> -		}
> +	if (chunk->fast_retransmit != SCTP_NEED_FRTX &&
> +	    flight_size >= transport->cwnd)
> +		return SCTP_XMIT_RWND_FULL;
>  
>  	/* Nagle's algorithm to solve small-packet problem:
>  	 * Inhibit the sending of new chunks when new outgoing data arrives
>  	 * if any previously transmitted data on the connection remains
>  	 * unacknowledged.
>  	 */
> -	if (!sctp_sk(asoc->base.sk)->nodelay && sctp_packet_empty(packet) &&
> -	    inflight && sctp_state(asoc, ESTABLISHED)) {
> -		unsigned int max = transport->pathmtu - packet->overhead;
> -		unsigned int len = chunk->skb->len + q->out_qlen;
> -
> -		/* Check whether this chunk and all the rest of pending
> -		 * data will fit or delay in hopes of bundling a full
> -		 * sized packet.
> -		 * Don't delay large message writes that may have been
> -		 * fragmeneted into small peices.
> -		 */
> -		if ((len < max) && chunk->msg->can_delay) {
> -			retval = SCTP_XMIT_NAGLE_DELAY;
> -			goto finish;
> -		}
> -	}
>  
> -finish:
> -	return retval;
> +	if (sctp_sk(asoc->base.sk)->nodelay)
> +		/* Nagle disabled */
> +		return SCTP_XMIT_OK;
> +
> +	if (!sctp_packet_empty(packet))
> +		/* Append to packet */
> +		return SCTP_XMIT_OK;
> +
> +	if (inflight != 0)
> +		/* Nothing unacked */
> +		return SCTP_XMIT_OK;

This doesn't look right.  First, the comment doesn't match the condition.
Second, when we have stuff in-flight we might be affected be Nagle.  Thus,
I think the condition should be:
       if (!inflight)

Then the commend and logic holds.

-vlad

> +	
> +	if (!sctp_state(asoc, ESTABLISHED))
> +		return SCTP_XMIT_OK;
> +
> +	/* Check whether this chunk and all the rest of pending data will fit
> +	 * or delay in hopes of bundling a full sized packet.
> +	 */
> +	if (chunk->skb->len + q->out_qlen >= transport->pathmtu - packet->overhead)
> +		/* Enough data queued to fill a packet */
> +		return SCTP_XMIT_OK;
> +
> +	/* Don't delay large message writes that may have been fragmented */
> +	if (!chunk->msg->can_delay)
> +		return SCTP_XMIT_OK;
> +
> +	/* Defer until all data acked or packet full */
> +	return SCTP_XMIT_NAGLE_DELAY;
>  }
>  
>  /* This private function does management things when adding DATA chunk */
> 

  reply	other threads:[~2014-07-11 20:01 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-09  8:29 [PATCH v2 net-next 1/3] net: sctp: Open out the check for Nagle David Laight
2014-07-11 20:01 ` Vlad Yasevich [this message]
2014-07-14  9:12   ` David Laight

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=53C04280.8020809@gmail.com \
    --to=vyasevich@gmail.com \
    --cc=David.Laight@ACULAB.COM \
    --cc=davem@davemloft.net \
    --cc=linux-sctp@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).