1. 01 Aug, 2015 6 commits
    • David S. Miller's avatar
      Merge branch 'ipv6-auto-flow-labels' · 17f901e8
      David S. Miller authored
      Tom Herbert says:
      
      ====================
      ipv6: Turn on auto IPv6 flow labels by default
      
      BSD (MacOS) has already turned on flow labels by default and this does
      not seem to be causing any problems in the Internet. Let's go ahead
      and turn them on by default. We'll continue to monitor for any devices
      start choking on them.
      
      Flow labels are important since they are the desired solution for
      network devices to perform ECMP and RSS (RFC6437 and RFC6438).
      Traditionally, devices perform a 5-tuple hash on packets that
      includes port numbers. For the most part, these devices can only
      compute 5-tuple hashes for TCP and UDP. This severely limits our ability
      to get good network load balancing for other protocols (IPIP, GRE,ESP,
      etc.), and hence we are limited in using other protocols. Unfortunately,
      this method is accepted as the de facto standard to the extent that
      there are several proposals to encapsulate protocols in UDP _just_ for
      the purposes for getting ECMP to work. With hosts generating flow labels
      and devices taking them as input into ECMP (several already do), we can
      start to fix this fundamental problem.
      
      This patch set:
       - Changes IPV6_FLOWINFO sockopt to be opt-out of flow labels for
         connections rather than opt-in
       - Disable flow label state ranges sysctl by default
       - Enable auto flow labels sysctl by default
      
      v2:
        - Added functions to create an skb->hash based on flowi4 and flowi6.
          These are called in output path when creating a packet
        - Call skb_get_hash_flowi6 in ip6_make_flowlabel
        - Implement the auto_flowlabels sysctl as a mode for auto flowlabels.
          There are four modes which correspond to flow labels being enabled
          and whether socket option can be used to opt in or opt out of
          using them
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      17f901e8
    • Tom Herbert's avatar
      ipv6: Enable auto flow labels by default · b5677416
      Tom Herbert authored
      Initialize auto_flowlabels to one. This enables automatic flow labels,
      individual socket may disable them using the IPV6_AUTOFLOWLABEL socket
      option.
      Signed-off-by: default avatarTom Herbert <tom@herbertland.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b5677416
    • Tom Herbert's avatar
      ipv6: Disable flowlabel state ranges by default · be26849b
      Tom Herbert authored
      Per RFC6437 stateful flow labels (e.g. labels set by flow label manager)
      cannot "disturb" nodes taking part in stateless flow labels. While the
      ranges only reduce the flow label entropy by one bit, it is conceivable
      that this might bias the algorithm on some routers causing a load
      imbalance. For best results on the Internet we really need the full
      20 bits.
      Signed-off-by: default avatarTom Herbert <tom@herbertland.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      be26849b
    • Tom Herbert's avatar
      ipv6: Implement different admin modes for automatic flow labels · 42240901
      Tom Herbert authored
      Change the meaning of net.ipv6.auto_flowlabels to provide a mode for
      automatic flow labels generation. There are four modes:
      
      0: flow labels are disabled
      1: flow labels are enabled, sockets can opt-out
      2: flow labels are allowed, sockets can opt-in
      3: flow labels are enabled and enforced, no opt-out for sockets
      
      np->autoflowlabel is initialized according to the sysctl value.
      Signed-off-by: default avatarTom Herbert <tom@herbertland.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      42240901
    • Tom Herbert's avatar
      ipv6: Call skb_get_hash_flowi6 to get skb->hash in ip6_make_flowlabel · 67800f9b
      Tom Herbert authored
      We can't call skb_get_hash here since the packet is not complete to do
      flow_dissector. Create hash based on flowi6 instead.
      Signed-off-by: default avatarTom Herbert <tom@herbertland.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      67800f9b
    • Tom Herbert's avatar
      net: Add functions to get skb->hash based on flow structures · f70ea018
      Tom Herbert authored
      Add skb_get_hash_flowi6 and skb_get_hash_flowi4 which derive an sk_buff
      hash from flowi6 and flowi4 structures respectively. These functions
      can be called when creating a packet in the output path where the new
      sk_buff does not yet contain a fully formed packet that is parsable by
      flow dissector.
      Signed-off-by: default avatarTom Herbert <tom@herbertland.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f70ea018
  2. 31 Jul, 2015 33 commits
  3. 30 Jul, 2015 1 commit
    • David S. Miller's avatar
      Merge branch 'for-upstream' of... · 29a3060a
      David S. Miller authored
      Merge branch 'for-upstream' of git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next
      
      Johan Hedberg says:
      
      ====================
      pull request: bluetooth-next 2015-07-30
      
      Here's a set of Bluetooth & 802.15.4 patches intended for the 4.3 kernel.
      
       - Cleanups & fixes to mac802154
       - Refactoring of Intel Bluetooth HCI driver
       - Various coding style fixes to Bluetooth HCI drivers
       - Support for Intel Lightning Peak Bluetooth devices
       - Generic class code in interface descriptor in btusb to match more HW
       - Refactoring of Bluetooth HS code together with a new config option
       - Support for BCM4330B1 Broadcom UART controller
      
      Let me know if there are any issues pulling. Thanks.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      29a3060a