1. 04 11月, 2017 3 次提交
  2. 03 11月, 2017 1 次提交
  3. 27 10月, 2017 1 次提交
  4. 23 10月, 2017 3 次提交
    • I
      mlxsw: spectrum: Increase number of linear entries · f11fbaf8
      Ido Schimmel 提交于
      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: NIdo Schimmel <idosch@mellanox.com>
      Signed-off-by: NJiri Pirko <jiri@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f11fbaf8
    • I
      mlxsw: spectrum: Add ability to query KVDL allocation size · d672aec4
      Ido Schimmel 提交于
      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: NIdo Schimmel <idosch@mellanox.com>
      Signed-off-by: NJiri Pirko <jiri@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d672aec4
    • I
      mlxsw: spectrum: Better represent KVDL partitions · a875a2ee
      Ido Schimmel 提交于
      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: NIdo Schimmel <idosch@mellanox.com>
      Signed-off-by: NJiri Pirko <jiri@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a875a2ee
  5. 20 10月, 2017 1 次提交
  6. 17 10月, 2017 3 次提交
  7. 09 10月, 2017 1 次提交
  8. 28 9月, 2017 2 次提交
    • Y
      mlxsw: spectrum: Add the multicast routing hardware logic · 0e14c777
      Yotam Gigi 提交于
      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: NYotam Gigi <yotamg@mellanox.com>
      Reviewed-by: NIdo Schimmel <idosch@mellanox.com>
      Signed-off-by: NJiri Pirko <jiri@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      0e14c777
    • Y
      mlxsw: spectrum: Add the multicast routing offloading logic · c011ec1b
      Yotam Gigi 提交于
      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: NYotam Gigi <yotamg@mellanox.com>
      Reviewed-by: NIdo Schimmel <idosch@mellanox.com>
      Signed-off-by: NJiri Pirko <jiri@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c011ec1b
  9. 27 9月, 2017 1 次提交
  10. 21 9月, 2017 3 次提交
  11. 20 9月, 2017 1 次提交
  12. 04 9月, 2017 1 次提交
  13. 24 8月, 2017 3 次提交
  14. 08 8月, 2017 1 次提交
  15. 19 7月, 2017 1 次提交
  16. 09 6月, 2017 1 次提交
  17. 07 6月, 2017 1 次提交
  18. 05 6月, 2017 1 次提交
  19. 27 5月, 2017 6 次提交
    • I
      mlxsw: spectrum_router: Implement common RIF core · e4f3c1c1
      Ido Schimmel 提交于
      The mlxsw driver currently implements three types of RIFs. VLAN and FID
      RIFs for L3 interfaces on top of VLAN-aware and VLAN-unaware bridges
      (respectively) and Subport RIFs for all other L3 interfaces.
      
      All the RIF types follow a common configuration procedure, which only
      differs in the type-specific bits. The patch exploits this fact and
      consolidates the common code paths, thereby simplifying the code and
      making it more extensible.
      
      This work also prepares the driver for use with future ASICs, where the
      range of the Subport RIFs will be extended and their configuration
      modified accordingly. By merely implementing a new RIF operations and
      selecting it during initialization, the same driver could be re-used.
      Signed-off-by: NIdo Schimmel <idosch@mellanox.com>
      Signed-off-by: NJiri Pirko <jiri@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e4f3c1c1
    • I
      mlxsw: spectrum: Implement common FID core · a1107487
      Ido Schimmel 提交于
      The device supports three types of FIDs. 802.1Q and 802.1D FIDs for
      VLAN-aware and VLAN-unaware bridges (respectively) and rFIDs to
      transport packets to the router block.
      
      The different users (e.g., bridge, router, ACLs) of the FIDs
      infrastructure need not know about the internal FIDs implementation and
      can therefore interact with it using a restricted set of exported
      functions.
      
      By encapsulating the entire FID logic and hiding it from the rest of the
      driver we get a code base that it much simpler and easier to work with
      and extend.
      
      For example, in the current Spectrum ASIC only 802.1D FIDs can be
      assigned a VNI, but future ASICs will also support 802.1Q FIDs. With
      this patch in place, support for future ASICs can be easily added by
      implementing a new FID operations according to their capabilities.
      Signed-off-by: NIdo Schimmel <idosch@mellanox.com>
      Signed-off-by: NJiri Pirko <jiri@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a1107487
    • I
      mlxsw: spectrum: Replace vPorts with Port-VLAN · c57529e1
      Ido Schimmel 提交于
      As explained in the cover letter, since the introduction of the bridge
      offload in the mlxsw driver, information related to the offloaded bridge
      and bridge ports was stored in the individual port struct,
      mlxsw_sp_port.
      
      This lead to a bloated struct storing both physical properties of the
      port (e.g., autoneg status) as well as logical properties of an upper
      bridge port (e.g., learning, mrouter indication). While this might work
      well for simple devices, it proved to be hard to extend when stacked
      devices were taken into account and more advanced use-cases (e.g., IGMP
      snooping) considered.
      
      This patch removes the excess information from the above struct and
      instead stores it in more appropriate structs that represent the bridge
      port, the bridge itself and a VLAN configured on the bridge port.
      
      The membership of a port in a bridge is denoted using the Port-VLAN
      struct, which points to the bridge port and also member in the bridge
      VLAN group of the VLAN it represents. This allows us to completely
      remove the vPort abstraction and consolidate many of the code paths
      relating to VLAN-aware and unaware bridges.
      
      Note that the FID / vFID code is currently duplicated, but this will
      soon go away when the common FID core will be introduced.
      Signed-off-by: NIdo Schimmel <idosch@mellanox.com>
      Signed-off-by: NJiri Pirko <jiri@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c57529e1
    • I
      mlxsw: spectrum: Change signature of FID leave function · ce95e154
      Ido Schimmel 提交于
      When a vPort is destroyed, it leaves the FID it's currently mapped to
      (if any) and drops the reference. The FID's leave function expects to
      get the vPort as its argument, but this will have to change when the
      vPort model is retired.
      
      Change the function signature to expect a Port-VLAN struct instead and
      patch the call sites accordingly.
      
      The code introduced in this patch will be removed later in the patchset,
      but this intermediary step is required in order to ease the code review.
      Signed-off-by: NIdo Schimmel <idosch@mellanox.com>
      Signed-off-by: NJiri Pirko <jiri@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ce95e154
    • I
      mlxsw: spectrum: Introduce Port-VLAN structure · 31a08a52
      Ido Schimmel 提交于
      This is the first step in the transition from the vPort model to a
      unified Port-VLAN structure. The new structure is defined and created /
      destroyed upon invocation of the 8021q ndos, but it's not actually used
      throughout the code.
      
      Subsequent patches will initialize it correctly and also create /
      destroy it upon switchdev's VLAN object.
      Signed-off-by: NIdo Schimmel <idosch@mellanox.com>
      Signed-off-by: NJiri Pirko <jiri@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      31a08a52
    • I
      mlxsw: spectrum: Set port's mode according to FID mappings · 4aafc368
      Ido Schimmel 提交于
      We currently transition the port to "Virtual mode" upon the creation of
      its first VLAN upper, as we need to classify incoming packets to a FID
      using {Port, VID} and not only the VID.
      
      However, it's more appropriate to transition the port to this mode when
      the {Port, VID} are actually mapped to a FID. Either during the
      enslavement of the VLAN upper to a VLAN-unaware bridge or the
      configuration of a router port.
      
      Do this change now in preparation for the introduction of the FID core,
      where this operation will be encapsulated.
      
      To prevent regressions, this patch also explicitly configures an OVS
      slave to "Virtual mode". Otherwise, a packet that didn't hit an ACL rule
      could be classified to an existing FID based on a global VID-to-FID
      mapping, thus not incurring a FID mis-classification, which would
      otherwise trap the packet to the CPU to be processed by the OVS daemon.
      Signed-off-by: NIdo Schimmel <idosch@mellanox.com>
      Signed-off-by: NJiri Pirko <jiri@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4aafc368
  20. 18 5月, 2017 5 次提交