1. 27 8月, 2007 1 次提交
  2. 03 8月, 2007 2 次提交
  3. 31 7月, 2007 3 次提交
    • I
      [TCP]: Bidir flow must not disregard SACK blocks for lost marking · b8ed601c
      Ilpo Järvinen 提交于
      It's possible that new SACK blocks that should trigger new LOST
      markings arrive with new data (which previously made is_dupack
      false). In addition, I think this fixes a case where we get
      a cumulative ACK with enough SACK blocks to trigger the fast
      recovery (is_dupack would be false there too).
      
      I'm not completely pleased with this solution because readability
      of the code is somewhat questionable as 'is_dupack' in SACK case
      is no longer about dupacks only but would mean something like
      'lost_marker_work_todo' too... But because of Eifel stuff done
      in CA_Recovery, the FLAG_DATA_SACKED check cannot be placed to
      the if statement which seems attractive solution. Nevertheless,
      I didn't like adding another variable just for that either... :-)
      Signed-off-by: NIlpo Järvinen <ilpo.jarvinen@helsinki.fi>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b8ed601c
    • I
      [TCP]: Fix ratehalving with bidirectional flows · 1e757f99
      Ilpo Järvinen 提交于
      Actually, the ratehalving seems to work too well, as cwnd is
      reduced on every second ACK even though the packets in flight
      remains unchanged. Recoveries in a bidirectional flows suffer
      quite badly because of this, both NewReno and SACK are affected.
      
      After this patch, rate halving is performed for ACK only if
      packets in flight was supposedly changed too.
      Signed-off-by: NIlpo Järvinen <ilpo.jarvinen@helsinki.fi>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      1e757f99
    • S
      [TCP]: congestion control API pass RTT in microseconds · 30cfd0ba
      Stephen Hemminger 提交于
      This patch changes the API for the callback that is done after an ACK is
      received. It solves a couple of issues:
      
        * Some congestion controls want higher resolution value of RTT
          (controlled by TCP_CONG_RTT_SAMPLE flag). These don't really want a ktime, but
          all compute a RTT in microseconds.
      
        * Other congestion control could use RTT at jiffies resolution.
      
      To keep API consistent the units should be the same for both cases, just the
      resolution should change.
      Signed-off-by: NStephen Hemminger <shemminger@linux-foundation.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      30cfd0ba
  4. 18 7月, 2007 1 次提交
  5. 15 7月, 2007 1 次提交
  6. 16 6月, 2007 2 次提交
  7. 15 6月, 2007 1 次提交
  8. 13 6月, 2007 1 次提交
  9. 04 6月, 2007 1 次提交
  10. 20 5月, 2007 2 次提交
  11. 30 4月, 2007 2 次提交
  12. 26 4月, 2007 23 次提交