1. 05 7月, 2011 6 次提交
    • G
      dccp ccid-2: Perform congestion-window validation · 113ced1f
      Gerrit Renker 提交于
      CCID-2's cwnd increases like TCP during slow-start, which has implications for
       * the local Sequence Window value (should be > cwnd),
       * the Ack Ratio value.
      Hence an exponential growth, if it does not reflect the actual network
      conditions, can quickly lead to instability.
      
      This patch adds congestion-window validation (RFC2861) to CCID-2:
       * cwnd is constrained if the sender is application limited;
       * cwnd is reduced after a long idle period, as suggested in the '90 paper
         by Van Jacobson, in RFC 2581 (sec. 4.1);
       * cwnd is never reduced below the RFC 3390 initial window.
      
      As marked in the comments, the code is actually almost a direct copy of the
      TCP congestion-window-validation algorithms. By continuing this work, it may
      in future be possible to use the TCP code (not possible at the moment).
      
      The mechanism can be turned off using a module parameter. Sampling of the
      currently-used window (moving-maximum) is however done constantly; this is
      used to determine the expected window, which can be exploited to regulate
      DCCP's Sequence Window value.
      
      This patch also sets slow-start-after-idle (RFC 4341, 5.1), i.e. it behaves like
      TCP when net.ipv4.tcp_slow_start_after_idle = 1.
      Signed-off-by: NGerrit Renker <gerrit@erg.abdn.ac.uk>
      113ced1f
    • G
      dccp ccid-2: Use existing function to test for data packets · 58fdea0f
      Gerrit Renker 提交于
      This replaces a switch statement with a test, using the equivalent
      function dccp_data_packet(skb).  It also doubles the range of the field
      `rx_num_data_pkts' by changing the type from `int' to `u32', avoiding
      signed/unsigned comparison with the u16 field `dccps_r_ack_ratio'.
      Signed-off-by: NGerrit Renker <gerrit@erg.abdn.ac.uk>
      58fdea0f
    • G
      dccp ccid-2: move rfc 3390 function into header file · b4d5f4b2
      Gerrit Renker 提交于
      This moves CCID-2's initial window function into the header file, since several
      parts throughout the CCID-2 code need to call it (CCID-2 still uses RFC 3390).
      Signed-off-by: NGerrit Renker <gerrit@erg.abdn.ac.uk>
      Acked-by: NLeandro Melo de Sales <leandro@ic.ufal.br>
      b4d5f4b2
    • G
      dccp: cosmetics of info message · 1fd9d208
      Gerrit Renker 提交于
      Change the CCID (de)activation message to start with the
      protocol name, as 'CCID' is already in there.
      Signed-off-by: NGerrit Renker <gerrit@erg.abdn.ac.uk>
      1fd9d208
    • G
      dccp: combine the functionality of enqeueing and cloning · 8695e801
      Gerrit Renker 提交于
      Realising the following call pattern,
       * first dccp_entail() is called to enqueue a new skb and
       * then skb_clone() is called to transmit a clone of that skb,
      this patch integrates both into the same function.
      Signed-off-by: NGerrit Renker <gerrit@erg.abdn.ac.uk>
      8695e801
    • G
      dccp: Clean up slow-path input processing · c0c20150
      Gerrit Renker 提交于
      This patch rearranges the order of statements of the slow-path input processing
      (i.e. any other state than OPEN), to resolve the following issues.
      
       1. Dependencies: the order of statements now better matches RFC 4340, 8.5, i.e.
          step 7 is before step 9 (previously 9 was before 7), and parsing options in
          step 8 (which may consume resources) now comes after step 7.
       2. Sequence number checks are omitted if in state LISTEN/REQUEST, due to the
          note underneath the table in RFC 4340, 7.5.3.
          As a result, CCID processing is now indeed confined to OPEN/PARTOPEN states,
          i.e. congestion control is performed only on the flow of data packets. This
          avoids pathological cases of doing congestion control on those messages
          which set up and terminate the connection.
       3. Packets are now passed on to Ack Vector / CCID processing only after
          - step 7  (receive unexpected packets),
          - step 9  (receive Reset),
          - step 13 (receive CloseReq),
          - step 14 (receive Close)
          and only if the state is PARTOPEN. This simplifies CCID processing:
          - in LISTEN/CLOSED the CCIDs are non-existent;
          - in RESPOND/REQUEST the CCIDs have not yet been negotiated;
          - in CLOSEREQ and active-CLOSING the node has already closed this socket;
          - in passive-CLOSING the client is waiting for its Reset.
          In the last case, RFC 4340, 8.3 leaves it open to ignore further incoming
          data, which is the approach taken here.
      Signed-off-by: NGerrit Renker <gerrit@erg.abdn.ac.uk>
      c0c20150
  2. 04 7月, 2011 3 次提交
  3. 02 7月, 2011 14 次提交
  4. 30 6月, 2011 4 次提交
  5. 29 6月, 2011 1 次提交
  6. 28 6月, 2011 7 次提交
  7. 27 6月, 2011 1 次提交
    • J
      net_sched: fix dequeuer fairness · d5b8aa1d
      jamal 提交于
      Results on dummy device can be seen in my netconf 2011
      slides. These results are for a 10Gige IXGBE intel
      nic - on another i5 machine, very similar specs to
      the one used in the netconf2011 results.
      It turns out - this is a hell lot worse than dummy
      and so this patch is even more beneficial for 10G.
      
      Test setup:
      ----------
      
      System under test sending packets out.
      Additional box connected directly dropping packets.
      Installed prio qdisc on the eth device and default
      netdev default length of 1000 used as is.
      The 3 prio bands each were set to 100 (didnt factor in
      the results).
      
      5 packet runs were made and the middle 3 picked.
      
      results
      -------
      
      The "cpu" column indicates the which cpu the sample
      was taken on,
      The "Pkt runx" carries the number of packets a cpu
      dequeued when forced to be in the "dequeuer" role.
      The "avg" for each run is the number of times each
      cpu should be a "dequeuer" if the system was fair.
      
      3.0-rc4      (plain)
      cpu         Pkt run1        Pkt run2        Pkt run3
      ================================================
      cpu0        21853354        21598183        22199900
      cpu1          431058          473476          393159
      cpu2          481975          477529          458466
      cpu3        23261406        23412299        22894315
      avg         11506948        11490372        11486460
      
      3.0-rc4 with patch and default weight 64
      cpu 	     Pkt run1        Pkt run2        Pkt run3
      ================================================
      cpu0        13205312        13109359        13132333
      cpu1        10189914        10159127        10122270
      cpu2        10213871        10124367        10168722
      cpu3        13165760        13164767        13096705
      avg         11693714        11639405        11630008
      
      As you can see the system is still not perfect but
      is a lot better than what it was before...
      
      At the moment we use the old backlog weight, weight_p
      which is 64 packets. It seems to be reasonably fine
      with that value.
      The system could be made more fair if we reduce the
      weight_p (as per my presentation), but we are going
      to affect the shared backlog weight. Unless deemed
      necessary, I think the default value is fine. If not
      we could add yet another knob.
      Signed-off-by: NJamal Hadi Salim <jhs@mojatatu.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d5b8aa1d
  8. 25 6月, 2011 4 次提交