소스 검색

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>
Vlad Yasevich 15 년 전
부모
커밋
b29e790728
1개의 변경된 파일3개의 추가작업 그리고 2개의 파일을 삭제
  1. 3 2
      net/sctp/output.c

+ 3 - 2
net/sctp/output.c

@@ -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;
 		}