1. 19 5月, 2012 3 次提交
  2. 18 5月, 2012 4 次提交
  3. 17 5月, 2012 1 次提交
  4. 16 5月, 2012 5 次提交
  5. 12 5月, 2012 1 次提交
    • E
      net/ipv6/af_inet6.c: checkpatch cleanup · 647c0c70
      Eldad Zack 提交于
      af_inet6.c:80: ERROR: do not initialise statics to 0 or NULL
      af_inet6.c:259: ERROR: spaces required around that '=' (ctx:VxV)
      af_inet6.c:394: WARNING: EXPORT_SYMBOL(foo); should immediately follow its function/variable
      af_inet6.c:412: WARNING: EXPORT_SYMBOL(foo); should immediately follow its function/variable
      af_inet6.c:422: ERROR: do not use assignment in if condition
      af_inet6.c:425: ERROR: do not use assignment in if condition
      af_inet6.c:433: ERROR: do not use assignment in if condition
      af_inet6.c:437: WARNING: EXPORT_SYMBOL(foo); should immediately follow its function/variable
      af_inet6.c:446: ERROR: spaces required around that '=' (ctx:VxV)
      af_inet6.c:478: WARNING: EXPORT_SYMBOL(foo); should immediately follow its function/variable
      af_inet6.c:485: ERROR: that open brace { should be on the previous line
      af_inet6.c:485: ERROR: space required before the open parenthesis '('
      af_inet6.c:513: WARNING: EXPORT_SYMBOL(foo); should immediately follow its function/variable
      af_inet6.c:629: WARNING: EXPORT_SYMBOL(foo); should immediately follow its function/variable
      af_inet6.c:647: WARNING: EXPORT_SYMBOL(foo); should immediately follow its function/variable
      af_inet6.c:687: WARNING: EXPORT_SYMBOL(foo); should immediately follow its function/variable
      af_inet6.c:709: WARNING: EXPORT_SYMBOL(foo); should immediately follow its function/variable
      af_inet6.c:1073: ERROR: space required before the open parenthesis '('
      Signed-off-by: NEldad Zack <eldad@fogrefinery.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      647c0c70
  6. 11 5月, 2012 1 次提交
    • A
      6lowpan: IPv6 link local address · 06a4c1c5
      alex.bluesman.smirnov@gmail.com 提交于
      According to the RFC4944 (Transmission of IPv6 Packets over
      IEEE 802.15.4 Networks), chapter 7:
      
      The IPv6 link-local address [RFC4291] for an IEEE 802.15.4 interface
      is formed by appending the Interface Identifier, as defined above, to
      the prefix FE80::/64.
      
        10 bits            54 bits                  64 bits
      +----------+-----------------------+----------------------------+
      |1111111010|         (zeros)       |    Interface Identifier    |
      +----------+-----------------------+----------------------------+
      
      This patch adds IPv6 address generation support for the 6lowpan
      interfaces.
      Signed-off-by: NAlexander Smirnov <alex.bluesman.smirnov@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      06a4c1c5
  7. 09 5月, 2012 2 次提交
  8. 05 5月, 2012 1 次提交
    • E
      tcp: be more strict before accepting ECN negociation · bd14b1b2
      Eric Dumazet 提交于
      It appears some networks play bad games with the two bits reserved for
      ECN. This can trigger false congestion notifications and very slow
      transferts.
      
      Since RFC 3168 (6.1.1) forbids SYN packets to carry CT bits, we can
      disable TCP ECN negociation if it happens we receive mangled CT bits in
      the SYN packet.
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Cc: Perry Lorier <perryl@google.com>
      Cc: Matt Mathis <mattmathis@google.com>
      Cc: Yuchung Cheng <ycheng@google.com>
      Cc: Neal Cardwell <ncardwell@google.com>
      Cc: Wilmer van der Gaast <wilmer@google.com>
      Cc: Ankur Jain <jankur@google.com>
      Cc: Tom Herbert <therbert@google.com>
      Cc: Dave Täht <dave.taht@bufferbloat.net>
      Acked-by: NNeal Cardwell <ncardwell@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      bd14b1b2
  9. 01 5月, 2012 1 次提交
  10. 29 4月, 2012 3 次提交
  11. 27 4月, 2012 1 次提交
    • E
      ipv6: RTAX_FEATURE_ALLFRAG causes inefficient TCP segment sizing · 67469601
      Eric Dumazet 提交于
      Quoting Tore Anderson from :
      https://bugzilla.kernel.org/show_bug.cgi?id=42572
      
      When RTAX_FEATURE_ALLFRAG is set on a route, the effective TCP segment
      size does not take into account the size of the IPv6 Fragmentation
      header that needs to be included in outbound packets, causing every
      transmitted TCP segment to be fragmented across two IPv6 packets, the
      latter of which will only contain 8 bytes of actual payload.
      
      RTAX_FEATURE_ALLFRAG is typically set on a route in response to
      receving a ICMPv6 Packet Too Big message indicating a Path MTU of less
      than 1280 bytes. 1280 bytes is the minimum IPv6 MTU, however ICMPv6
      PTBs with MTU < 1280 are still valid, in particular when an IPv6
      packet is sent to an IPv4 destination through a stateless translator.
      Any ICMPv4 Need To Fragment packets originated from the IPv4 part of
      the path will be translated to ICMPv6 PTB which may then indicate an
      MTU of less than 1280.
      
      The Linux kernel refuses to reduce the effective MTU to anything below
      1280 bytes, instead it sets it to exactly 1280 bytes, and
      RTAX_FEATURE_ALLFRAG is also set. However, the TCP segment size appears
      to be set to 1240 bytes (1280 Path MTU - 40 bytes of IPv6 header),
      instead of 1232 (additionally taking into account the 8 bytes required
      by the IPv6 Fragmentation extension header).
      
      This in turn results in rather inefficient transmission, as every
      transmitted TCP segment now is split in two fragments containing
      1232+8 bytes of payload.
      
      After this patch, all the outgoing packets that includes a
      Fragmentation header all are "atomic" or "non-fragmented" fragments,
      i.e., they both have Offset=0 and More Fragments=0.
      
      With help from David S. Miller
      Reported-by: NTore Anderson <tore@fud.no>
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Cc: Maciej Żenczykowski <maze@google.com>
      Cc: Tom Herbert <therbert@google.com>
      Tested-by: NTore Anderson <tore@fud.no>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      67469601
  12. 26 4月, 2012 1 次提交
  13. 24 4月, 2012 2 次提交
    • E
      tcp: sk_add_backlog() is too agressive for TCP · da882c1f
      Eric Dumazet 提交于
      While investigating TCP performance problems on 10Gb+ links, we found a
      tcp sender was dropping lot of incoming ACKS because of sk_rcvbuf limit
      in sk_add_backlog(), especially if receiver doesnt use GRO/LRO and sends
      one ACK every two MSS segments.
      
      A sender usually tweaks sk_sndbuf, but sk_rcvbuf stays at its default
      value (87380), allowing a too small backlog.
      
      A TCP ACK, even being small, can consume nearly same truesize space than
      outgoing packets. Using sk_rcvbuf + sk_sndbuf as a limit makes sense and
      is fast to compute.
      
      Performance results on netperf, single flow, receiver with disabled
      GRO/LRO : 7500 Mbits instead of 6050 Mbits, no more TCPBacklogDrop
      increments at sender.
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Cc: Neal Cardwell <ncardwell@google.com>
      Cc: Tom Herbert <therbert@google.com>
      Cc: Maciej Żenczykowski <maze@google.com>
      Cc: Yuchung Cheng <ycheng@google.com>
      Cc: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi>
      Cc: Rick Jones <rick.jones2@hp.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      da882c1f
    • E
      net: add a limit parameter to sk_add_backlog() · f545a38f
      Eric Dumazet 提交于
      sk_add_backlog() & sk_rcvqueues_full() hard coded sk_rcvbuf as the
      memory limit. We need to make this limit a parameter for TCP use.
      
      No functional change expected in this patch, all callers still using the
      old sk_rcvbuf limit.
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Cc: Neal Cardwell <ncardwell@google.com>
      Cc: Tom Herbert <therbert@google.com>
      Cc: Maciej Żenczykowski <maze@google.com>
      Cc: Yuchung Cheng <ycheng@google.com>
      Cc: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi>
      Cc: Rick Jones <rick.jones2@hp.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f545a38f
  14. 23 4月, 2012 2 次提交
  15. 22 4月, 2012 2 次提交
  16. 21 4月, 2012 7 次提交
  17. 20 4月, 2012 2 次提交
  18. 16 4月, 2012 1 次提交