1. 28 Sep, 2014 5 commits
    • Florian Fainelli's avatar
      net: dsa: allow enabling and disable switch ports · b2f2af21
      Florian Fainelli authored
      Whenever a per-port network device is used/unused, invoke the switch
      driver port_enable/port_disable callbacks to allow saving as much power
      as possible by disabling unused parts of the switch (RX/TX logic, memory
      arrays, PHYs...). We supply a PHY device argument to make sure the
      switch driver can act on the PHY device if needed (like putting/taking
      the PHY out of deep low power mode).
      Signed-off-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b2f2af21
    • Eric Dumazet's avatar
      tcp: change tcp_skb_pcount() location · cd7d8498
      Eric Dumazet authored
      Our goal is to access no more than one cache line access per skb in
      a write or receive queue when doing the various walks.
      
      After recent TCP_SKB_CB() reorganizations, it is almost done.
      
      Last part is tcp_skb_pcount() which currently uses
      skb_shinfo(skb)->gso_segs, which is a terrible choice, because it needs
      3 cache lines in current kernel (skb->head, skb->end, and
      shinfo->gso_segs are all in 3 different cache lines, far from skb->cb)
      
      This very simple patch reuses space currently taken by tcp_tw_isn
      only in input path, as tcp_skb_pcount is only needed for skb stored in
      write queue.
      
      This considerably speeds up tcp_ack(), granted we avoid shinfo->tx_flags
      to get SKBTX_ACK_TSTAMP, which seems possible.
      
      This also speeds up all sack processing in general.
      
      This speeds up tcp_sendmsg() because it no longer has to access/dirty
      shinfo.
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      cd7d8498
    • Eric Dumazet's avatar
      tcp: better TCP_SKB_CB layout to reduce cache line misses · 971f10ec
      Eric Dumazet authored
      TCP maintains lists of skb in write queue, and in receive queues
      (in order and out of order queues)
      
      Scanning these lists both in input and output path usually requires
      access to skb->next, TCP_SKB_CB(skb)->seq, and TCP_SKB_CB(skb)->end_seq
      
      These fields are currently in two different cache lines, meaning we
      waste lot of memory bandwidth when these queues are big and flows
      have either packet drops or packet reorders.
      
      We can move TCP_SKB_CB(skb)->header at the end of TCP_SKB_CB, because
      this header is not used in fast path. This allows TCP to search much faster
      in the skb lists.
      
      Even with regular flows, we save one cache line miss in fast path.
      
      Thanks to Christoph Paasch for noticing we need to cleanup
      skb->cb[] (IPCB/IP6CB) before entering IP stack in tx path,
      and that I forgot IPCB use in tcp_v4_hnd_req() and tcp_v4_save_options().
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      971f10ec
    • Eric Dumazet's avatar
      ipv6: add a struct inet6_skb_parm param to ipv6_opt_accepted() · a224772d
      Eric Dumazet authored
      ipv6_opt_accepted() assumes IP6CB(skb) holds the struct inet6_skb_parm
      that it needs. Lets not assume this, as TCP stack might use a different
      place.
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a224772d
    • Eric Dumazet's avatar
      ipv4: rename ip_options_echo to __ip_options_echo() · 24a2d43d
      Eric Dumazet authored
      ip_options_echo() assumes struct ip_options is provided in &IPCB(skb)->opt
      Lets break this assumption, but provide a helper to not change all call points.
      
      ip_send_unicast_reply() gets a new struct ip_options pointer.
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      24a2d43d
  2. 26 Sep, 2014 1 commit
    • LEROY Christophe's avatar
      net: optimise csum_replace4() · 4565af0d
      LEROY Christophe authored
      csum_partial() is a generic function which is not optimised for small fixed
      length calculations, and its use requires to store "from" and "to" values in
      memory while we already have them available in registers. This also has impact,
      especially on RISC processors. In the same spirit as the change done by
      Eric Dumazet on csum_replace2(), this patch rewrites inet_proto_csum_replace4()
      taking into account RFC1624.
      
      I spotted during a NATted tcp transfert that csum_partial() is one of top 5
      consuming functions (around 8%), and the second user of csum_partial() is
      inet_proto_csum_replace4().
      
      I have proposed the same modification to inet_proto_csum_replace4() in another
      patch.
      Signed-off-by: default avatarChristophe Leroy <christophe.leroy@c-s.fr>
      Acked-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      4565af0d
  3. 23 Sep, 2014 1 commit
    • Eric Dumazet's avatar
      icmp: add a global rate limitation · 4cdf507d
      Eric Dumazet authored
      Current ICMP rate limiting uses inetpeer cache, which is an RBL tree
      protected by a lock, meaning that hosts can be stuck hard if all cpus
      want to check ICMP limits.
      
      When say a DNS or NTP server process is restarted, inetpeer tree grows
      quick and machine comes to its knees.
      
      iptables can not help because the bottleneck happens before ICMP
      messages are even cooked and sent.
      
      This patch adds a new global limitation, using a token bucket filter,
      controlled by two new sysctl :
      
      icmp_msgs_per_sec - INTEGER
          Limit maximal number of ICMP packets sent per second from this host.
          Only messages whose type matches icmp_ratemask are
          controlled by this limit.
          Default: 1000
      
      icmp_msgs_burst - INTEGER
          icmp_msgs_per_sec controls number of ICMP packets sent per second,
          while icmp_msgs_burst controls the burst size of these packets.
          Default: 50
      
      Note that if we really want to send millions of ICMP messages per
      second, we might extend idea and infra added in commit 04ca6973
      ("ip: make IP identifiers less predictable") :
      add a token bucket in the ip_idents hash and no longer rely on inetpeer.
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      4cdf507d
  4. 22 Sep, 2014 5 commits
    • Eric Dumazet's avatar
      tcp: avoid possible arithmetic overflows · fcdd1cf4
      Eric Dumazet authored
      icsk_rto is a 32bit field, and icsk_backoff can reach 15 by default,
      or more if some sysctl (eg tcp_retries2) are changed.
      
      Better use 64bit to perform icsk_rto << icsk_backoff operations
      
      As Joe Perches suggested, add a helper for this.
      
      Yuchung spotted the tcp_v4_err() case.
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      fcdd1cf4
    • Daniel Borkmann's avatar
      ipv6: mld: answer mldv2 queries with mldv1 reports in mldv1 fallback · 35f7aa53
      Daniel Borkmann authored
      RFC2710 (MLDv1), section 3.7. says:
      
        The length of a received MLD message is computed by taking the
        IPv6 Payload Length value and subtracting the length of any IPv6
        extension headers present between the IPv6 header and the MLD
        message. If that length is greater than 24 octets, that indicates
        that there are other fields present *beyond* the fields described
        above, perhaps belonging to a *future backwards-compatible* version
        of MLD. An implementation of the version of MLD specified in this
        document *MUST NOT* send an MLD message longer than 24 octets and
        MUST ignore anything past the first 24 octets of a received MLD
        message.
      
      RFC3810 (MLDv2), section 8.2.1. states for *listeners* regarding
      presence of MLDv1 routers:
      
        In order to be compatible with MLDv1 routers, MLDv2 hosts MUST
        operate in version 1 compatibility mode. [...] When Host
        Compatibility Mode is MLDv2, a host acts using the MLDv2 protocol
        on that interface. When Host Compatibility Mode is MLDv1, a host
        acts in MLDv1 compatibility mode, using *only* the MLDv1 protocol,
        on that interface. [...]
      
      While section 8.3.1. specifies *router* behaviour regarding presence
      of MLDv1 routers:
      
        MLDv2 routers may be placed on a network where there is at least
        one MLDv1 router. The following requirements apply:
      
        If an MLDv1 router is present on the link, the Querier MUST use
        the *lowest* version of MLD present on the network. This must be
        administratively assured. Routers that desire to be compatible
        with MLDv1 MUST have a configuration option to act in MLDv1 mode;
        if an MLDv1 router is present on the link, the system administrator
        must explicitly configure all MLDv2 routers to act in MLDv1 mode.
        When in MLDv1 mode, the Querier MUST send periodic General Queries
        truncated at the Multicast Address field (i.e., 24 bytes long),
        and SHOULD also warn about receiving an MLDv2 Query (such warnings
        must be rate-limited). The Querier MUST also fill in the Maximum
        Response Delay in the Maximum Response Code field, i.e., the
        exponential algorithm described in section 5.1.3. is not used. [...]
      
      That means that we should not get queries from different versions of
      MLD. When there's a MLDv1 router present, MLDv2 enforces truncation
      and MRC == MRD (both fields are overlapping within the 24 octet range).
      
      Section 8.3.2. specifies behaviour in the presence of MLDv1 multicast
      address *listeners*:
      
        MLDv2 routers may be placed on a network where there are hosts
        that have not yet been upgraded to MLDv2. In order to be compatible
        with MLDv1 hosts, MLDv2 routers MUST operate in version 1 compatibility
        mode. MLDv2 routers keep a compatibility mode per multicast address
        record. The compatibility mode of a multicast address is determined
        from the Multicast Address Compatibility Mode variable, which can be
        in one of the two following states: MLDv1 or MLDv2.
      
        The Multicast Address Compatibility Mode of a multicast address
        record is set to MLDv1 whenever an MLDv1 Multicast Listener Report is
        *received* for that multicast address. At the same time, the Older
        Version Host Present timer for the multicast address is set to Older
        Version Host Present Timeout seconds. The timer is re-set whenever a
        new MLDv1 Report is received for that multicast address. If the Older
        Version Host Present timer expires, the router switches back to
        Multicast Address Compatibility Mode of MLDv2 for that multicast
        address. [...]
      
      That means, what can happen is the following scenario, that hosts can
      act in MLDv1 compatibility mode when they previously have received an
      MLDv1 query (or, simply operate in MLDv1 mode-only); and at the same
      time, an MLDv2 router could start up and transmits MLDv2 startup query
      messages while being unaware of the current operational mode.
      
      Given RFC2710, section 3.7 we would need to answer to that with an MLDv1
      listener report, so that the router according to RFC3810, section 8.3.2.
      would receive that and internally switch to MLDv1 compatibility as well.
      
      Right now, I believe since the initial implementation of MLDv2, Linux
      hosts would just silently drop such MLDv2 queries instead of replying
      with an MLDv1 listener report, which would prevent a MLDv2 router going
      into fallback mode (until it receives other MLDv1 queries).
      
      Since the mapping of MRC to MRD in exactly such cases can make use of
      the exponential algorithm from 5.1.3, we cannot [strictly speaking] be
      aware in MLDv1 of the encoding in MRC, it seems also not mentioned by
      the RFC. Since encodings are the same up to 32767, assume in such a
      situation this value as a hard upper limit we would clamp. We have asked
      one of the RFC authors on that regard, and he mentioned that there seem
      not to be any implementations that make use of that exponential algorithm
      on startup messages. In any case, this patch fixes this MLD
      interoperability issue.
      Signed-off-by: default avatarDaniel Borkmann <dborkman@redhat.com>
      Acked-by: default avatarHannes Frederic Sowa <hannes@stressinduktion.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      35f7aa53
    • Florian Fainelli's avatar
      net: dsa: add {get, set}_wol callbacks to slave devices · 19e57c4e
      Florian Fainelli authored
      Allow switch drivers to implement per-port Wake-on-LAN getter and
      setters.
      Signed-off-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      19e57c4e
    • Florian Fainelli's avatar
      net: dsa: allow switch drivers to implement suspend/resume hooks · 24462549
      Florian Fainelli authored
      Add an abstraction layer to suspend/resume switch devices, doing the
      following split:
      
      - suspend/resume the slave network devices and their corresponding PHY
        devices
      - suspend/resume the switch hardware using switch driver callbacks
      Signed-off-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      24462549
    • Eric Dumazet's avatar
      net: sched: shrink struct qdisc_skb_cb to 28 bytes · 25711786
      Eric Dumazet authored
      We cannot make struct qdisc_skb_cb bigger without impacting IPoIB,
      or increasing skb->cb[] size.
      
      Commit e0f31d84 ("flow_keys: Record IP layer protocol in
      skb_flow_dissect()") broke IPoIB.
      
      Only current offender is sch_choke, and this one do not need an
      absolutely precise flow key.
      
      If we store 17 bytes of flow key, its more than enough. (Its the actual
      size of flow_keys if it was a packed structure, but we might add new
      fields at the end of it later)
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Fixes: e0f31d84 ("flow_keys: Record IP layer protocol in skb_flow_dissect()")
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      25711786
  5. 19 Sep, 2014 6 commits
  6. 16 Sep, 2014 2 commits
  7. 15 Sep, 2014 2 commits
    • Alexander Duyck's avatar
      dsa: Replace mii_bus with a generic host device · b4d2394d
      Alexander Duyck authored
      This change makes it so that instead of passing and storing a mii_bus we
      instead pass and store a host_dev.  From there we can test to determine the
      exact type of device, and can verify it is the correct device for our switch.
      
      So for example it would be possible to pass a device pointer from a pci_dev
      and instead of checking for a PHY ID we could check for a vendor and/or device
      ID.
      Signed-off-by: default avatarAlexander Duyck <alexander.h.duyck@intel.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b4d2394d
    • Alexander Duyck's avatar
      dsa: Split ops up, and avoid assigning tag_protocol and receive separately · 5075314e
      Alexander Duyck authored
      This change addresses several issues.
      
      First, it was possible to set tag_protocol without setting the ops pointer.
      To correct that I have reordered things so that rcv is now populated before
      we set tag_protocol.
      
      Second, it didn't make much sense to keep setting the device ops each time a
      new slave was registered.  So by moving the receive portion out into root
      switch initialization that issue should be addressed.
      
      Third, I wanted to avoid sending tags if the rcv pointer was not registered
      so I changed the tag check to verify if the rcv function pointer is set on
      the root tree.  If it is then we start sending DSA tagged frames.
      
      Finally I split the device ops pointer in the structures into two spots.  I
      placed the rcv function pointer in the root switch since this makes it
      easiest to access from there, and I placed the xmit function pointer in the
      slave for the same reason.
      Signed-off-by: default avatarAlexander Duyck <alexander.h.duyck@intel.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      5075314e
  8. 13 Sep, 2014 6 commits
  9. 12 Sep, 2014 1 commit
  10. 11 Sep, 2014 5 commits
  11. 09 Sep, 2014 6 commits