sctp: Nagle delay should be based on path mtu
Vlad Yasevich [Fri, 4 Sep 2009 22:20:59 +0000 (18:20 -0400)]
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>

net/sctp/output.c

index e25e2e2..d0b84f6 100644 (file)
@@ -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;
                }