1. 29 Sep, 2017 3 commits
  2. 28 Sep, 2017 28 commits
  3. 27 Sep, 2017 9 commits
    • David S. Miller's avatar
      Merge branch 'mlxsw-Add-support-for-offloading-IPv4-multicast-routes' · a2e4a219
      David S. Miller authored
      Jiri Pirko says:
      
      ====================
      mlxsw: Add support for offloading IPv4 multicast routes
      
      Yotam says:
      
      This patch-set introduces offloading of the kernel IPv4 multicast router
      logic in the Spectrum driver.
      
      The first patch makes the Spectrum driver ignore FIB notifications that are
      not of address family IPv4 or IPv6. This is needed in order to prevent
      crashes while the next patches introduce the RTNL_FAMILY_IPMR FIB
      notifications.
      
      Patches 2-5 update ipmr to use the FIB notification chain for both MFC and
      VIF notifications, and patches 8-12 update the Spectrum driver to register
      to these notifications and offload the routes.
      
      Similarly to IPv4 and IPv6, any failure will trigger the abort mechanism
      which is updated in this patch-set to eject multicast route tables too.
      
      At this stage, the following limitations apply:
       - A multicast MFC route will be offloaded by the driver if all the output
         interfaces are Spectrum router interfaces (RIFs). In any other case
         (which includes pimreg device, tunnel devices and management ports) the
         route will be trapped to the CPU and the packets will be forwarded by
         software.
       - ipmr proxy routes are not supported and will trigger the abort
         mechanism.
       - The MFC TTL values are currently treated as boolean: if the value is
         different than 255, the traffic is forwarded to the interface and if the
         value is 255 it is not forwarded. Dropping packets based on their TTL isn't
         currently supported.
      
      To allow users to have visibility on which of the routes are offloaded and
      which are not, patch 6 introduces a per-route offload indication similar to
      IPv4 and IPv6 routes which is sent to the user via the RTNetlink interface.
      
      The Spectrum driver multicast router offloading support, which is
      introduced in patches 8 and 9, is divided into two parts:
       - The hardware logic which abstracts the Spectrum hardware and provides a
         simple API for the upper levels.
       - The offloading logic which gets the MFC and VIF notifications from the
         kernel and updates the hardware using the hardware logic part.
      
      Finally, the last patch makes the Spectrum router logic not ignore the
      multicast FIB notifications and call the corresponding functions in the
      multicast router offloading logic.
      
      ---
      v2->v3:
       - Move the ipmr_rule_default function definition to be inside the already
         existing CONFIG_IP_MROUTE_MULTIPLE_TABLES ifdef block (patch 6)
       - Remove double =0 initialization in spectrum_mr.c (patch 7)
       - Fix route4 allocation size (patch 7)
      v1->v2:
       - Add comments for struct fields in mroute.h
       - Take the mrt_lock while dumping VIFs in the fib_notifier dump callback
       - Update the MFC lastuse field too
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a2e4a219
    • Yotam Gigi's avatar
      mlxsw: spectrum: router: Don't ignore IPMR notifications · 664375e9
      Yotam Gigi authored
      Make the Spectrum router logic not ignore the RTNL_FAMILY_IPMR FIB
      notifications.
      
      Past commits added the IPMR VIF and MFC add/del notifications via the
      fib_notifier chain. In addition, a code for handling these notifications in
      the Spectrum router logic was added. Make the Spectrum router logic not
      ignore these notifications and forward the requests to the Spectrum
      multicast router offloading logic.
      Signed-off-by: default avatarYotam Gigi <yotamg@mellanox.com>
      Reviewed-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>
      664375e9
    • Yotam Gigi's avatar
      mlxsw: spectrum: Notify multicast router on RIF MTU changes · fd890fe9
      Yotam Gigi authored
      Due to the fact that multicast routes hold the minimum MTU of all the
      egress RIFs and trap packets that don't meet it, notify the mulitcast
      router code on RIF MTU changes.
      Signed-off-by: default avatarYotam Gigi <yotamg@mellanox.com>
      Reviewed-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>
      fd890fe9
    • Yotam Gigi's avatar
      mlxsw: spectrum_router: Add multicast routes notification handling functionality · d42b0965
      Yotam Gigi authored
      Add functionality for calling the multicast routing offloading logic upon
      MFC and VIF add and delete notifications. In addition, call the multicast
      routing upon RIF addition and deletion events.
      
      As the multicast routing offload logic may sleep, the actual calls are done
      in a deferred work. To ensure the MFC object is not freed in that interval,
      a reference is held to it. In case of a failure, the abort mechanism is
      used, which ejects all the routes from the hardware and triggers the
      traffic to flow through the kernel.
      
      Note: At that stage, the FIB notifications are still ignored, and will be
      enabled in a further patch.
      Signed-off-by: default avatarYotam Gigi <yotamg@mellanox.com>
      Reviewed-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>
      d42b0965
    • Yotam Gigi's avatar
      mlxsw: spectrum: router: Squash the default route table to main · 7e50d435
      Yotam Gigi authored
      Currently, the mlxsw Spectrum driver offloads only either the RT_TABLE_MAIN
      FIB table or the VRF tables, so the RT_TABLE_LOCAL table is squashed to the
      RT_TABLE_MAIN table to allow local routes to be offloaded too.
      
      By default, multicast MFC routes which are not assigned to any user
      requested table are put in the RT_TABLE_DEFAULT table.
      
      Due to the fact that offloading multicast MFC routes support in Spectrum
      router logic is going to be introduced soon, squash the default table to
      MAIN too.
      Signed-off-by: default avatarYotam Gigi <yotamg@mellanox.com>
      Reviewed-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>
      7e50d435
    • Yotam Gigi's avatar
      mlxsw: spectrum: Add the multicast routing hardware logic · 0e14c777
      Yotam Gigi authored
      Implement the multicast routing hardware API introduced in previous patch
      for the specific spectrum hardware.
      
      The spectrum hardware multicast routes are written using the RMFT2 register
      and point to an ACL flexible action set. The actions used for multicast
      routes are:
       - Counter action, which allows counting bytes and packets on multicast
         routes.
       - Multicast route action, which provide RPF check and do the actual packet
         duplication to a list of RIFs.
       - Trap action, in the case the route action specified by the called is
         trap.
      Signed-off-by: default avatarYotam Gigi <yotamg@mellanox.com>
      Reviewed-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>
      0e14c777
    • Yotam Gigi's avatar
      mlxsw: spectrum: Add the multicast routing offloading logic · c011ec1b
      Yotam Gigi authored
      Add the multicast router offloading logic, which is in charge of handling
      the VIF and MFC notifications and translating it to the hardware logic API.
      
      The offloading logic has to overcome several obstacles in order to safely
      comply with the kernel multicast router user API:
       - It must keep track of the mapping between VIFs to netdevices. The user
         can add an MFC cache entry pointing to a VIF, delete the VIF and add
         re-add it with a different netdevice. The offloading logic has to handle
         this in order to be compatible with the kernel logic.
       - It must keep track of the mapping between netdevices to spectrum RIFs,
         as the current hardware implementation assume having a RIF for every
         port in a multicast router.
       - It must handle routes pointing to pimreg device to be trapped to the
         kernel, as the packet should be delivered to userspace.
       - It must handle routes pointing tunnel VIFs. The current implementation
         does not support multicast forwarding to tunnels, thus routes that point
         to a tunnel should be trapped to the kernel.
       - It must be aware of proxy multicast routes, which include both (*,*)
         routes and duplicate routes. Currently proxy routes are not offloaded
         and trigger the abort mechanism: removal of all routes from hardware and
         triggering the traffic to go through the kernel.
      
      The multicast routing offloading logic also updates the counters of the
      offloaded MFC routes in a periodic work.
      Signed-off-by: default avatarYotam Gigi <yotamg@mellanox.com>
      Reviewed-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>
      c011ec1b
    • Yotam Gigi's avatar
      net: mroute: Check if rule is a default rule · 478e4c2f
      Yotam Gigi authored
      When the ipmr starts, it adds one default FIB rule that matches all packets
      and sends them to the DEFAULT (multicast) FIB table. A more complex rule
      can be added by user to specify that for a specific interface, a packet
      should be look up at either an arbitrary table or according to the l3mdev
      of the interface.
      
      For drivers willing to offload the ipmr logic into a hardware but don't
      want to offload all the FIB rules functionality, provide a function that
      can indicate whether the FIB rule is the default multicast rule, thus only
      one routing table is needed.
      
      This way, a driver can register to the FIB notification chain, get
      notifications about FIB rules added and trigger some kind of an internal
      abort mechanism when a non default rule is added by the user.
      Signed-off-by: default avatarYotam Gigi <yotamg@mellanox.com>
      Reviewed-by: default avatarIdo Schimmel <idosch@mellanox.com>
      Signed-off-by: default avatarJiri Pirko <jiri@mellanox.com>
      Reviewed-by: default avatarNikolay Aleksandrov <nikolay@cumulusnetworks.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      478e4c2f
    • Yotam Gigi's avatar
      net: ipmr: Add MFC offload indication · c7c0bbea
      Yotam Gigi authored
      Allow drivers, registered to the fib notification chain indicate whether a
      multicast MFC route is offloaded or not, similarly to unicast routes. The
      indication of whether a route is offloaded is done using the mfc_flags
      field on an mfc_cache struct, and the information is sent to the userspace
      via the RTNetlink interface only.
      
      Currently, MFC routes are either offloaded or not, thus there is no need to
      add per-VIF offload indication.
      Signed-off-by: default avatarYotam Gigi <yotamg@mellanox.com>
      Reviewed-by: default avatarIdo Schimmel <idosch@mellanox.com>
      Signed-off-by: default avatarJiri Pirko <jiri@mellanox.com>
      Reviewed-by: default avatarNikolay Aleksandrov <nikolay@cumulusnetworks.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c7c0bbea