• Ilpo Järvinen's avatar
    [TCP]: Fix lost_retrans loop vs fastpath problems · f785a8e2
    Ilpo Järvinen authored
    Detection implemented with lost_retrans must work also when
    fastpath is taken, yet most of the queue is skipped including
    (very likely) those retransmitted skb's we're interested in.
    This problem appeared when the hints got added, which removed
    a need to always walk over the whole write queue head.
    Therefore decicion for the lost_retrans worker loop entry must
    be separated from the sacktag processing more than it was
    necessary before.
    
    It turns out to be problematic to optimize the worker loop
    very heavily because ack_seqs of skb may have a number of
    discontinuity points. Maybe similar approach as currently is
    implemented could be attempted but that's becoming more and
    more complex because the trend is towards less skb walking
    in sacktag marker. Trying a simple work until all rexmitted
    skbs heve been processed approach.
    
    Maybe after(highest_sack_end_seq, tp->high_seq) checking is not
    sufficiently accurate and causes entry too often in no-work-to-do
    cases. Since that's not known, I've separated solution to that
    from this patch.
    
    Noticed because of report against a related problem from TAKANO
    Ryousei <takano@axe-inc.co.jp>. He also provided a patch to
    that part of the problem. This patch includes solution to it
    (though this patch has to use somewhat different placement).
    TAKANO's description and patch is available here:
    
      http://marc.info/?l=linux-netdev&m=119149311913288&w=2
    
    ...In short, TAKANO's problem is that end_seq the loop is using
    not necessarily the largest SACK block's end_seq because the
    current ACK may still have higher SACK blocks which are later
    by the loop.
    Signed-off-by: default avatarIlpo Järvinen <ilpo.jarvinen@helsinki.fi>
    Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    f785a8e2
tcp_input.c 148 KB