jtl added a comment.

  I think something like this code will get you closer to what you want:
  
    Index: sys/netinet/tcp_output.c
    ===================================================================
    --- sys/netinet/tcp_output.c        (revision 298090)
    +++ sys/netinet/tcp_output.c        (working copy)
    @@ -1545,10 +1545,16 @@
                        tp->t_softerror = error;
                        return (error);
                case ENOBUFS:
    -                   if (!tcp_timer_active(tp, TT_REXMT) &&
    -                       !tcp_timer_active(tp, TT_PERSIST))
    -                           tcp_timer_activate(tp, TT_REXMT, tp->t_rxtcur);
    -                   tp->snd_cwnd = tp->t_maxseg;
    +                   if (len > 0 || (flags & (TH_SYN|TH_FIN))) {
    +                           if (!tcp_timer_active(tp, TT_REXMT) &&
    +                               !tcp_timer_active(tp, TT_PERSIST))
    +                                   tcp_timer_activate(tp, TT_REXMT,
    +                                       tp->t_rxtcur);
    +                           tp->snd_cwnd = tp->t_maxseg;
    +                   } else if (!tcp_timer_active(tp, TT_DELACK) &&
    +                       (flags & TH_RST) == 0)
    +                           tcp_timer_activate(tp, TT_DELACK,
    +                               tcp_delacktime);
                        return (0);
                case EMSGSIZE:
                        /*
  
  I think this code gets you closer to what you want.
  
  I agree that the present code seems wrong. Using the retransmit timers for 
ACKs seems inappropriate. But, I am generally concerned about how the system 
responds when loaded. I'm not sure its a good thing to add more work to a 
system that is already overloaded. Things will automatically fix themselves in 
the presence of lost ACKs. The reason to retransmit ACKs is simply to prevent 
unnecessary retransmissions and the latency that comes with waiting for the 
retransmission to timeout. But, on an overloaded system, that may or may not be 
a good thing.

REVISION DETAIL
  https://reviews.freebsd.org/D5872

EMAIL PREFERENCES
  https://reviews.freebsd.org/settings/panel/emailpreferences/

To: sepherosa_gmail.com, network, glebius, lstewart, adrian, delphij, 
decui_microsoft.com, honzhan_microsoft.com, howard0su_gmail.com, 
freebsd-net-list, transport, jtl, hiren
Cc: mike-karels.net, jtl
_______________________________________________
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Reply via email to