sctp: Nagle delay should be based on path mtu
The decision to delay due to Nagle should be based on the path mtu and future packet size. We currently incorrectly base it on 'frag_point' which is the SCTP DATA segment size, and also we do not count DATA chunk header overhead in the computation. This actuall allows situations where a user can set low 'frag_point', and then send small messages without delay. Signed-off-by: Vlad Yasevich <vladislav.yasevich@hp.com>
This commit is contained in:
		
					parent
					
						
							
								d4d6fb5787
							
						
					
				
			
			
				commit
				
					
						b29e790728
					
				
			
		
					 1 changed files with 3 additions and 2 deletions
				
			
		| 
						 | 
				
			
			@ -697,13 +697,14 @@ static sctp_xmit_t sctp_packet_can_append_data(struct sctp_packet *packet,
 | 
			
		|||
	 */
 | 
			
		||||
	if (!sctp_sk(asoc->base.sk)->nodelay && sctp_packet_empty(packet) &&
 | 
			
		||||
	    inflight && sctp_state(asoc, ESTABLISHED)) {
 | 
			
		||||
		unsigned len = datasize + q->out_qlen;
 | 
			
		||||
		unsigned max = transport->pathmtu - packet->overhead;
 | 
			
		||||
		unsigned 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.
 | 
			
		||||
		 */
 | 
			
		||||
		if (len < asoc->frag_point) {
 | 
			
		||||
		if (len < max) {
 | 
			
		||||
			retval = SCTP_XMIT_NAGLE_DELAY;
 | 
			
		||||
			goto finish;
 | 
			
		||||
		}
 | 
			
		||||
| 
						 | 
				
			
			
 | 
			
		|||
		Loading…
	
	Add table
		Add a link
		
	
		Reference in a new issue