1. 24 Oct, 2017 23 commits
  2. 23 Oct, 2017 17 commits
    • Sven Eckelmann's avatar
      batman-adv: use inline kernel-doc for uapi constants · 40b16b9b
      Sven Eckelmann authored
      The enums of constants for netlink tends to become rather large over time.
      Documenting them is easier when the kernel-doc is actually next to constant
      and not in a different block above the enum.
      
      Also inline kernel-doc allows multi-paragraph description. This could be
      required to better document the netlink command types and the expected
      return values.
      Signed-off-by: default avatarSven Eckelmann <sven@narfation.org>
      Signed-off-by: default avatarSimon Wunderlich <sw@simonwunderlich.de>
      40b16b9b
    • Gustavo A. R. Silva's avatar
      net: core: rtnetlink: use BUG_ON instead of if condition followed by BUG · 058c8d59
      Gustavo A. R. Silva authored
      Use BUG_ON instead of if condition followed by BUG in do_setlink.
      
      This issue was detected with the help of Coccinelle.
      Signed-off-by: default avatarGustavo A. R. Silva <garsilva@embeddedor.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      058c8d59
    • Florian Fainelli's avatar
      net: systemport: Guard against unmapped TX ring · e83b1715
      Florian Fainelli authored
      Because SYSTEMPORT is a (semi) normal network device, the stack may attempt to
      queue packets on it oustide of the DSA slave transmit path.  When that happens,
      the DSA layer has not had a chance to tag packets with the appropriate per-port
      and per-queue information, and if that happens and we don't have a port 0 queue
      0 available (e.g: on boards where this does not exist), we will hit a NULL
      pointer de-reference in bcm_sysport_select_queue().
      
      Guard against such cases by testing for the TX ring validity.
      
      Fixes: 84ff33eeb23d ("net: systemport: Establish DSA network device queue mapping")
      Signed-off-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e83b1715
    • David S. Miller's avatar
      Merge branch 'mlxsw-Add-support-for-non-equal-cost-multi-path' · fbd15f48
      David S. Miller authored
      Jiri Pirko says:
      
      ====================
      mlxsw: Add support for non-equal-cost multi-path
      
      Ido says:
      
      In the device, nexthops are stored as adjacency entries in an array
      called the KVD linear (KVDL). When a multi-path route is hit the
      packet's headers are hashed and then converted to an index into KVDL
      based on the adjacency group's size and base index.
      
      Up until now the driver ignored the `weight` parameter for multi-path
      routes and allocated only one adjacency entry for each nexthop with a
      limit of 32 nexthops in a group. This set makes the driver take the
      `weight` parameter into account when allocating adjacency entries.
      
      First patch teaches dpipe to show the size of the adjacency group, so
      that users will be able to determine the actual weight of each nexthop.
      The second patch refactors the KVDL allocator, making it more receptive
      towards the addition of another partition later in the set.
      
      Patches 3-5 introduce small changes towards the actual change in the
      sixth patch that populates the adjacency entries according to their
      relative weight.
      
      Last two patches finally add another partition to the KVDL, which allows
      us to allocate more than 32 entries per-group and thus support more
      nexthops and also provide higher accuracy with regards to the requested
      weights.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      fbd15f48
    • Ido Schimmel's avatar
      mlxsw: spectrum: Add another partition to KVD linear · 330e2cc6
      Ido Schimmel authored
      The KVD linear is currently partitioned into two partitions. One for
      single entries and another for groups of 32 entries.
      
      Add another partition consisting of groups of 512 entries which will
      allow us to more accurately represent the nexthop weights in non-equal
      cost multi-path routing.
      Signed-off-by: default avatarIdo Schimmel <idosch@mellanox.com>
      Signed-off-by: default avatarJiri Pirko <jiri@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      330e2cc6
    • Ido Schimmel's avatar
      mlxsw: spectrum: Increase number of linear entries · f11fbaf8
      Ido Schimmel authored
      The memory region where adjacency entries (nexthops) are stored is
      called the KVD linear and is configured during initialization with a
      size of 64K.
      
      Extend this area with 32K more entries, that will be partitioned into 64
      groups of 0.5K entries, thereby allowing us to support weighted nexthops
      with high accuracy.
      
      Change the ratio between both types of hash entries, so as to prevent
      reduction in the number of double hash entries, which are used for IPv6
      neighbours and routes with a prefix length greater than 64.
      
      Note that the user will be able to control all these sizes once the
      devlink resource manager is introduced.
      Signed-off-by: default avatarIdo Schimmel <idosch@mellanox.com>
      Signed-off-by: default avatarJiri Pirko <jiri@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f11fbaf8
    • Ido Schimmel's avatar
      mlxsw: spectrum_router: Populate adjacency entries according to weights · eb789980
      Ido Schimmel authored
      Up until now the driver assumed all the nexthops have an equal weight
      and wrote each to a single adjacency entry.
      
      This patch takes the `weight` parameter into account and populates the
      adjacency group according to the relative weight of each nexthop.
      
      Specifically, the weights of all the nexthops that should be offloaded
      are first normalized and then used to calculate the upper adjacency
      index of each nexthop. This is done according to the hash-threshold
      algorithm used by the kernel for IPv4 multi-path routing.
      
      Adjacency groups are currently limited to 32 entries which limits the
      weights that can be used, but follow-up patches will introduce groups of
      512 entries.
      Signed-off-by: default avatarIdo Schimmel <idosch@mellanox.com>
      Signed-off-by: default avatarJiri Pirko <jiri@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      eb789980
    • Ido Schimmel's avatar
      mlxsw: spectrum_router: Prepare for large adjacency groups · 425a08c6
      Ido Schimmel authored
      The device has certain restrictions regarding the size of an adjacency
      group.
      
      Have the router determine the size of the adjacency group according to
      available KVDL allocation sizes and these restrictions.
      
      This was not needed until now since only allocations of up 32 entries
      were supported and these are all valid sizes for an adjacency group.
      Signed-off-by: default avatarIdo Schimmel <idosch@mellanox.com>
      Signed-off-by: default avatarJiri Pirko <jiri@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      425a08c6
    • Ido Schimmel's avatar
      mlxsw: spectrum_router: Store weight in nexthop struct · 408bd946
      Ido Schimmel authored
      As the first step towards non-equal-cost multi-path support, store each
      nexthop's weight.
      
      For IPv6 nexthops always set the weight to 1, as it only supports ECMP.
      Signed-off-by: default avatarIdo Schimmel <idosch@mellanox.com>
      Signed-off-by: default avatarJiri Pirko <jiri@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      408bd946
    • Ido Schimmel's avatar
      mlxsw: spectrum: Add ability to query KVDL allocation size · d672aec4
      Ido Schimmel authored
      The current KVDL allocation API allows the user to specify the requested
      number of entries, but the user has no way of knowing how many entries
      were actually allocated.
      
      This works because existing users (e.g., router) request the exact
      number they end up using. With the introduction of large adjacency
      groups, this will change, as the router will have the ability to choose
      from several allocation sizes, where larger allocations provide higher
      accuracy with respect to requested weights and better resilience against
      nexthop failures.
      
      One option is to have the router try several allocations of descending
      size until one succeeds, but a better way is to simply allow it to query
      the actual allocation size and then size its request accordingly.
      Signed-off-by: default avatarIdo Schimmel <idosch@mellanox.com>
      Signed-off-by: default avatarJiri Pirko <jiri@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d672aec4
    • Ido Schimmel's avatar
      mlxsw: spectrum: Better represent KVDL partitions · a875a2ee
      Ido Schimmel authored
      The KVD linear (KVDL) allocator currently consists of a very large
      bitmap that reflects the KVDL's usage. The boundaries of each partition
      as well as their allocation size are represented using defines.
      
      This representation requires us to patch all the functions that act on a
      partition whenever the partitioning scheme is changed. In addition, it
      does not enable the dynamic configuration of the KVDL using the
      up-coming resource manager.
      
      Add objects to represent these partitions as well as the accompanying
      code that acts on them to perform allocations and de-allocations.
      
      In the following patches, this will allow us to easily add another
      partition as well as new operations to act on these partitions.
      Signed-off-by: default avatarIdo Schimmel <idosch@mellanox.com>
      Signed-off-by: default avatarJiri Pirko <jiri@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a875a2ee
    • Ido Schimmel's avatar
      mlxsw: spectrum_dpipe: Add adjacency group size · e69cd9d7
      Ido Schimmel authored
      The adjacency group size is part of the match on the adjacency group and
      should therefore be exposed using dpipe.
      
      When non-equal-cost multi-path support will be introduced, the group's
      size will help users understand the exact number of adjacency entries
      each nexthop occupies, as a nexthop will no longer correspond to a
      single entry.
      
      The output for a multi-path route with two nexthops, one with weight 255
      and the second 1 will be:
      
      Example:
      
      $ devlink dpipe table dump pci/0000:01:00.0 name mlxsw_adj
      pci/0000:01:00.0:
        index 0
        match_value:
          type field_exact header mlxsw_meta field adj_index value 65536
          type field_exact header mlxsw_meta field adj_size value 512
          type field_exact header mlxsw_meta field adj_hash_index value 0
        action_value:
          type field_modify header ethernet field destination mac value e4:1d:2d:a5:f3:64
          type field_modify header mlxsw_meta field erif_port mapping ifindex mapping_value 3 value 1
      
        index 1
        match_value:
          type field_exact header mlxsw_meta field adj_index value 65536
          type field_exact header mlxsw_meta field adj_size value 512
          type field_exact header mlxsw_meta field adj_hash_index value 510
        action_value:
          type field_modify header ethernet field destination mac value e4:1d:2d:a5:f3:65
          type field_modify header mlxsw_meta field erif_port mapping ifindex mapping_value 4 value 2
      
      Thus, the first nexthop occupies 510 adjacency entries and the second 2,
      which leads to a ratio of 255 to 1.
      Signed-off-by: default avatarIdo Schimmel <idosch@mellanox.com>
      Signed-off-by: default avatarJiri Pirko <jiri@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e69cd9d7
    • David S. Miller's avatar
      Merge branch 'bcm_sf2-Add-support-for-IPv6-CFP-rules' · bc9db417
      David S. Miller authored
      Florian Fainelli says:
      
      ====================
      net: dsa: bcm_sf2: Add support for IPv6 CFP rules
      
      This patch series adds support for matching IPv6 addresses to the existing CFP
      support code. Because IPv6 addresses are four times bigger than IPv4, we can
      fit them anymore in a single slice, so we need to chain two in order to have
      a complete match. This makes us require a second bitmap tracking unique rules
      so we don't over populate the TCAM.
      
      Finally, because the code had to be re-organized, it became a lot easier to
      support arbitrary prefix/mask lengths, so the last two patches do just that.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      bc9db417
    • Florian Fainelli's avatar
      net: dsa: bcm_sf2: Allow matching arbitrary IPv6 masks/lengths · dd8eff68
      Florian Fainelli authored
      There is no reason why we should limit ourselves to matching only
      full IPv4 addresses (/32), the same logic applies between the DATA and
      MASK ports, so just make it more configurable to accept both.
      Signed-off-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      dd8eff68
    • Florian Fainelli's avatar
      net: dsa: bcm_sf2: Allow matching arbitrary IPv4 mask lengths · bc3fc44c
      Florian Fainelli authored
      There is no reason why we should limit ourselves to matching only full
      IPv4 addresses (/32), the same logic applies between the DATA and MASK
      ports, so just make it more configurable to accept both.
      Signed-off-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      bc3fc44c
    • Florian Fainelli's avatar
      net: dsa: bcm_sf2: Add support for IPv6 CFP rules · ba0696c2
      Florian Fainelli authored
      Inserting IPv6 CFP rules complicates the code a little bit in that we
      need to insert two rules side by side and chain them to match a full
      IPv6 tuple (src, dst IPv6 + port + protocol).
      Signed-off-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ba0696c2
    • Florian Fainelli's avatar
      net: dsa: bcm_sf2: Simplify bcm_sf2_cfp_rule_get_all() · 4daa70cf
      Florian Fainelli authored
      There is no need to do a HW search of the TCAMs which is something slow
      and expensive. Since we already maintain a bitmask of active CFP rules,
      just iterate over those, starting from bit 1 (after the reserved entry)
      to get a count and index position to store the rule later on.
      
      As a result we can remove the code in bcm_sf2_cfp_rule_get() which acted
      on the "search" argument, and remove that argument.
      Signed-off-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      4daa70cf