1. 02 12月, 2009 11 次提交
  2. 30 11月, 2009 1 次提交
  3. 29 11月, 2009 5 次提交
    • E
      pktgen: NUMA aware · 3291b9db
      Eric Dumazet 提交于
      pktgen threads are bound to given CPU, we can allocate memory for
      these threads in a NUMA aware way.
      
      After a pktgen session on two threads, we can check flows memory was
      allocated on right node, instead of a not related one.
      
      # grep pktgen_thread_write /proc/vmallocinfo
      0xffffc90007204000-0xffffc90007385000 1576960 pktgen_thread_write+0x3a4/0x6b0 [pktgen] pages=384 vmalloc N0=384
      0xffffc90007386000-0xffffc90007507000 1576960 pktgen_thread_write+0x3a4/0x6b0 [pktgen] pages=384 vmalloc N1=384
      Signed-off-by: NEric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      3291b9db
    • A
      X25: Fix oops and refcnt problems from x25_dev_get · 429d33ac
      andrew hendry 提交于
      Calls to x25_dev_get check for dev = NULL which was not set.
      It allowed x25 to set routes and ioctls on down interfaces.
      This caused oopses and refcnt problems on device_unregister.
      Signed-off-by: NAndrew Hendry <andrew.hendry@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      429d33ac
    • A
      X25: Check for errors in x25_init · 1fd975a0
      andrew hendry 提交于
      Adds error checking to x25_init.
      Signed-off-by: NAndrew Hendry <andrew.hendry@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      1fd975a0
    • A
      X25: Move SYSCTL ifdefs into header · 2f5517ae
      andrew hendry 提交于
      Moves the CONFIG_SYSCTL ifdefs in x25_init into header.
      Signed-off-by: NAndrew Hendry <andrew.hendry@gmail.com>
      Acked-by: N"Eric W. Biederman" <ebiederm@xmission.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      2f5517ae
    • A
      sctp: on T3_RTX retransmit all the in-flight chunks · 5fdd4bae
      Andrei Pelinescu-Onciul 提交于
      When retransmitting due to T3 timeout, retransmit all the
      in-flight chunks for the corresponding  transport/path, including
      chunks sent less then 1 rto ago.
      This is the correct behaviour according to rfc4960 section 6.3.3
      E3 and
      "Note: Any DATA chunks that were sent to the address for which the
       T3-rtx timer expired but did not fit in one MTU (rule E3 above)
       should be marked for retransmission and sent as soon as cwnd
       allows (normally, when a SACK arrives). ".
      
      This fixes problems when more then one path is present and the T3
      retransmission of the first chunk that timeouts stops the T3 timer
      for the initial active path, leaving all the other in-flight
      chunks waiting forever or until a new chunk is transmitted on the
      same path and timeouts (and this will happen only if the cwnd
      allows sending new chunks, but since cwnd was dropped to MTU by
      the timeout => it will wait until the first heartbeat).
      
      Example: 10 packets in flight, sent at 0.1 s intervals on the
      primary path. The primary path is down and the first packet
      timeouts. The first packet is retransmitted on another path, the
      T3 timer for the primary path is stopped and cwnd is set to MTU.
      All the other 9 in-flight packets will not be retransmitted
      (unless more new packets are sent on the primary path which depend
      on cwnd allowing it, and even in this case the 9 packets will be
      retransmitted only after a new packet timeouts which even in the
      best case would be more then RTO).
      
      This commit reverts d0ce9291 and
      also removes the now unused transport->last_rto, introduced in
       b6157d8e.
      
      p.s  The problem is not only when multiple paths are there.  It
      can happen in a single homed environment.  If the application
      stops sending data, it possible to have a hung association.
      Signed-off-by: NAndrei Pelinescu-Onciul <andrei@iptel.org>
      Signed-off-by: NVlad Yasevich <vladislav.yasevich@hp.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      5fdd4bae
  4. 27 11月, 2009 2 次提交
  5. 26 11月, 2009 5 次提交
  6. 25 11月, 2009 2 次提交
  7. 24 11月, 2009 14 次提交