1. 19 10月, 2007 2 次提交
  2. 18 10月, 2007 15 次提交
  3. 16 10月, 2007 18 次提交
  4. 15 10月, 2007 2 次提交
  5. 12 10月, 2007 3 次提交
    • I
      [TCP]: Limit processing lost_retrans loop to work-to-do cases · b08d6cb2
      Ilpo Järvinen 提交于
      This addition of lost_retrans_low to tcp_sock might be
      unnecessary, it's not clear how often lost_retrans worker is
      executed when there wasn't work to do.
      Signed-off-by: NIlpo Järvinen <ilpo.jarvinen@helsinki.fi>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b08d6cb2
    • I
      [TCP]: Fix lost_retrans loop vs fastpath problems · f785a8e2
      Ilpo Järvinen 提交于
      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: NIlpo Järvinen <ilpo.jarvinen@helsinki.fi>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f785a8e2
    • I
      [TCP]: No need to re-count fackets_out/sacked_out at RTO · 4cd82999
      Ilpo Järvinen 提交于
      Both sacked_out and fackets_out are directly known from how
      parameter. Since fackets_out is accurate, there's no need for
      recounting (sacked_out was previously unnecessarily counted
      in the loop anyway).
      Signed-off-by: NIlpo Järvinen <ilpo.jarvinen@helsinki.fi>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4cd82999