1. 22 11月, 2014 1 次提交
  2. 20 11月, 2014 2 次提交
  3. 19 11月, 2014 1 次提交
  4. 13 11月, 2014 2 次提交
  5. 12 11月, 2014 5 次提交
    • J
      irda: Remove IRDA_<TYPE> logging macros · 6c91023d
      Joe Perches 提交于
      And use the more common mechanisms directly.
      
      Other miscellanea:
      
      o Coalesce formats
      o Add missing newlines
      o Realign arguments
      o Remove unnecessary OOM message logging as
        there's a generic stack dump already on OOM.
      Signed-off-by: NJoe Perches <joe@perches.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      6c91023d
    • J
      irda: Simplify IRDA logging macros · d65c4e4e
      Joe Perches 提交于
      These are the same as net_<level>_ratelimited, so
      use the more common style in the macro definition.
      Signed-off-by: NJoe Perches <joe@perches.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d65c4e4e
    • W
      neigh: remove dynamic neigh table registration support · d7480fd3
      WANG Cong 提交于
      Currently there are only three neigh tables in the whole kernel:
      arp table, ndisc table and decnet neigh table. What's more,
      we don't support registering multiple tables per family.
      Therefore we can just make these tables statically built-in.
      
      Cc: David S. Miller <davem@davemloft.net>
      Signed-off-by: NCong Wang <xiyou.wangcong@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d7480fd3
    • J
      net: Convert LIMIT_NETDEBUG to net_dbg_ratelimited · ba7a46f1
      Joe Perches 提交于
      Use the more common dynamic_debug capable net_dbg_ratelimited
      and remove the LIMIT_NETDEBUG macro.
      
      All messages are still ratelimited.
      
      Some KERN_<LEVEL> uses are changed to KERN_DEBUG.
      
      This may have some negative impact on messages that were
      emitted at KERN_INFO that are not not enabled at all unless
      DEBUG is defined or dynamic_debug is enabled.  Even so,
      these messages are now _not_ emitted by default.
      
      This also eliminates the use of the net_msg_warn sysctl
      "/proc/sys/net/core/warnings".  For backward compatibility,
      the sysctl is not removed, but it has no function.  The extern
      declaration of net_msg_warn is removed from sock.h and made
      static in net/core/sysctl_net_core.c
      
      Miscellanea:
      
      o Update the sysctl documentation
      o Remove the embedded uses of pr_fmt
      o Coalesce format fragments
      o Realign arguments
      Signed-off-by: NJoe Perches <joe@perches.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ba7a46f1
    • E
      net: introduce SO_INCOMING_CPU · 2c8c56e1
      Eric Dumazet 提交于
      Alternative to RPS/RFS is to use hardware support for multiple
      queues.
      
      Then split a set of million of sockets into worker threads, each
      one using epoll() to manage events on its own socket pool.
      
      Ideally, we want one thread per RX/TX queue/cpu, but we have no way to
      know after accept() or connect() on which queue/cpu a socket is managed.
      
      We normally use one cpu per RX queue (IRQ smp_affinity being properly
      set), so remembering on socket structure which cpu delivered last packet
      is enough to solve the problem.
      
      After accept(), connect(), or even file descriptor passing around
      processes, applications can use :
      
       int cpu;
       socklen_t len = sizeof(cpu);
      
       getsockopt(fd, SOL_SOCKET, SO_INCOMING_CPU, &cpu, &len);
      
      And use this information to put the socket into the right silo
      for optimal performance, as all networking stack should run
      on the appropriate cpu, without need to send IPI (RPS/RFS).
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      2c8c56e1
  6. 11 11月, 2014 2 次提交
  7. 07 11月, 2014 3 次提交
  8. 06 11月, 2014 6 次提交
  9. 05 11月, 2014 2 次提交
    • F
      net: allow setting ecn via routing table · f7b3bec6
      Florian Westphal 提交于
      This patch allows to set ECN on a per-route basis in case the sysctl
      tcp_ecn is not set to 1. In other words, when ECN is set for specific
      routes, it provides a tcp_ecn=1 behaviour for that route while the rest
      of the stack acts according to the global settings.
      
      One can use 'ip route change dev $dev $net features ecn' to toggle this.
      
      Having a more fine-grained per-route setting can be beneficial for various
      reasons, for example, 1) within data centers, or 2) local ISPs may deploy
      ECN support for their own video/streaming services [1], etc.
      
      There was a recent measurement study/paper [2] which scanned the Alexa's
      publicly available top million websites list from a vantage point in US,
      Europe and Asia:
      
      Half of the Alexa list will now happily use ECN (tcp_ecn=2, most likely
      blamed to commit 255cac91 ("tcp: extend ECN sysctl to allow server-side
      only ECN") ;)); the break in connectivity on-path was found is about
      1 in 10,000 cases. Timeouts rather than receiving back RSTs were much
      more common in the negotiation phase (and mostly seen in the Alexa
      middle band, ranks around 50k-150k): from 12-thousand hosts on which
      there _may_ be ECN-linked connection failures, only 79 failed with RST
      when _not_ failing with RST when ECN is not requested.
      
      It's unclear though, how much equipment in the wild actually marks CE
      when buffers start to fill up.
      
      We thought about a fallback to non-ECN for retransmitted SYNs as another
      global option (which could perhaps one day be made default), but as Eric
      points out, there's much more work needed to detect broken middleboxes.
      
      Two examples Eric mentioned are buggy firewalls that accept only a single
      SYN per flow, and middleboxes that successfully let an ECN flow establish,
      but later mark CE for all packets (so cwnd converges to 1).
      
       [1] http://www.ietf.org/proceedings/89/slides/slides-89-tsvarea-1.pdf, p.15
       [2] http://ecn.ethz.ch/
      
      Joint work with Daniel Borkmann.
      
      Reference: http://thread.gmane.org/gmane.linux.network/335797Suggested-by: NHannes Frederic Sowa <hannes@stressinduktion.org>
      Acked-by: NEric Dumazet <edumazet@google.com>
      Signed-off-by: NDaniel Borkmann <dborkman@redhat.com>
      Signed-off-by: NFlorian Westphal <fw@strlen.de>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f7b3bec6
    • F
      syncookies: split cookie_check_timestamp() into two functions · f1673381
      Florian Westphal 提交于
      The function cookie_check_timestamp(), both called from IPv4/6 context,
      is being used to decode the echoed timestamp from the SYN/ACK into TCP
      options used for follow-up communication with the peer.
      
      We can remove ECN handling from that function, split it into a separate
      one, and simply rename the original function into cookie_decode_options().
      cookie_decode_options() just fills in tcp_option struct based on the
      echoed timestamp received from the peer. Anything that fails in this
      function will actually discard the request socket.
      
      While this is the natural place for decoding options such as ECN which
      commit 172d69e6 ("syncookies: add support for ECN") added, we argue
      that in particular for ECN handling, it can be checked at a later point
      in time as the request sock would actually not need to be dropped from
      this, but just ECN support turned off.
      
      Therefore, we split this functionality into cookie_ecn_ok(), which tells
      us if the timestamp indicates ECN support AND the tcp_ecn sysctl is enabled.
      
      This prepares for per-route ECN support: just looking at the tcp_ecn sysctl
      won't be enough anymore at that point; if the timestamp indicates ECN
      and sysctl tcp_ecn == 0, we will also need to check the ECN dst metric.
      
      This would mean adding a route lookup to cookie_check_timestamp(), which
      we definitely want to avoid. As we already do a route lookup at a later
      point in cookie_{v4,v6}_check(), we can simply make use of that as well
      for the new cookie_ecn_ok() function w/o any additional cost.
      
      Joint work with Daniel Borkmann.
      Acked-by: NEric Dumazet <edumazet@google.com>
      Signed-off-by: NDaniel Borkmann <dborkman@redhat.com>
      Signed-off-by: NFlorian Westphal <fw@strlen.de>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f1673381
  10. 04 11月, 2014 4 次提交
  11. 31 10月, 2014 6 次提交
  12. 30 10月, 2014 6 次提交