1. 09 8月, 2019 1 次提交
  2. 07 8月, 2019 1 次提交
    • P
      mlxsw: spectrum_dcb: Configure DSCP map as the last rule is removed · d3e36788
      Petr Machata 提交于
      [ Upstream commit dedfde2fe1c4ccf27179fcb234e2112d065c39bb ]
      
      Spectrum systems use DSCP rewrite map to update DSCP field in egressing
      packets to correspond to priority that the packet has. Whether rewriting
      will take place is determined at the point when the packet ingresses the
      switch: if the port is in Trust L3 mode, packet priority is determined from
      the DSCP map at the port, and DSCP rewrite will happen. If the port is in
      Trust L2 mode, 802.1p is used for packet prioritization, and no DSCP
      rewrite will happen.
      
      The driver determines the port trust mode based on whether any DSCP
      prioritization rules are in effect at given port. If there are any, trust
      level is L3, otherwise it's L2. When the last DSCP rule is removed, the
      port is switched to trust L2. Under that scenario, if DSCP of a packet
      should be rewritten, it should be rewritten to 0.
      
      However, when switching to Trust L2, the driver neglects to also update the
      DSCP rewrite map. The last DSCP rule thus remains in effect, and packets
      egressing through this port, if they have the right priority, will have
      their DSCP set according to this rule.
      
      Fix by first configuring the rewrite map, and only then switching to trust
      L2 and bailing out.
      
      Fixes: b2b1dab6 ("mlxsw: spectrum: Support ieee_setapp, ieee_delapp")
      Signed-off-by: NPetr Machata <petrm@mellanox.com>
      Reported-by: NAlex Veber <alexve@mellanox.com>
      Tested-by: NAlex Veber <alexve@mellanox.com>
      Signed-off-by: NIdo Schimmel <idosch@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      d3e36788
  3. 14 7月, 2019 1 次提交
  4. 10 7月, 2019 1 次提交
  5. 22 6月, 2019 1 次提交
  6. 17 5月, 2019 4 次提交
    • I
      mlxsw: core: Do not use WQ_MEM_RECLAIM for mlxsw workqueue · e38c6748
      Ido Schimmel 提交于
      [ Upstream commit b442fed1b724af0de087912a5718ddde1b87acbb ]
      
      The workqueue is used to periodically update the networking stack about
      activity / statistics of various objects such as neighbours and TC
      actions.
      
      It should not be called as part of memory reclaim path, so remove the
      WQ_MEM_RECLAIM flag.
      
      Fixes: 3d5479e9 ("mlxsw: core: Remove deprecated create_workqueue")
      Signed-off-by: NIdo Schimmel <idosch@mellanox.com>
      Acked-by: NJiri Pirko <jiri@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NSasha Levin <alexander.levin@microsoft.com>
      e38c6748
    • I
      mlxsw: core: Do not use WQ_MEM_RECLAIM for mlxsw ordered workqueue · 835ae6cc
      Ido Schimmel 提交于
      [ Upstream commit 4af0699782e2cc7d0d89db9eb6f8844dd3df82dc ]
      
      The ordered workqueue is used to offload various objects such as routes
      and neighbours in the order they are notified.
      
      It should not be called as part of memory reclaim path, so remove the
      WQ_MEM_RECLAIM flag. This can also result in a warning [1], if a worker
      tries to flush a non-WQ_MEM_RECLAIM workqueue.
      
      [1]
      [97703.542861] workqueue: WQ_MEM_RECLAIM mlxsw_core_ordered:mlxsw_sp_router_fib6_event_work [mlxsw_spectrum] is flushing !WQ_MEM_RECLAIM events:rht_deferred_worker
      [97703.542884] WARNING: CPU: 1 PID: 32492 at kernel/workqueue.c:2605 check_flush_dependency+0xb5/0x130
      ...
      [97703.542988] Hardware name: Mellanox Technologies Ltd. MSN3700C/VMOD0008, BIOS 5.11 10/10/2018
      [97703.543049] Workqueue: mlxsw_core_ordered mlxsw_sp_router_fib6_event_work [mlxsw_spectrum]
      [97703.543061] RIP: 0010:check_flush_dependency+0xb5/0x130
      ...
      [97703.543071] RSP: 0018:ffffb3f08137bc00 EFLAGS: 00010086
      [97703.543076] RAX: 0000000000000000 RBX: ffff96e07740ae00 RCX: 0000000000000000
      [97703.543080] RDX: 0000000000000094 RSI: ffffffff82dc1934 RDI: 0000000000000046
      [97703.543084] RBP: ffffb3f08137bc20 R08: ffffffff82dc18a0 R09: 00000000000225c0
      [97703.543087] R10: 0000000000000000 R11: 0000000000007eec R12: ffffffff816e4ee0
      [97703.543091] R13: ffff96e06f6a5c00 R14: ffff96e077ba7700 R15: ffffffff812ab0c0
      [97703.543097] FS: 0000000000000000(0000) GS:ffff96e077a80000(0000) knlGS:0000000000000000
      [97703.543101] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [97703.543104] CR2: 00007f8cd135b280 CR3: 00000001e860e003 CR4: 00000000003606e0
      [97703.543109] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      [97703.543112] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      [97703.543115] Call Trace:
      [97703.543129] __flush_work+0xbd/0x1e0
      [97703.543137] ? __cancel_work_timer+0x136/0x1b0
      [97703.543145] ? pwq_dec_nr_in_flight+0x49/0xa0
      [97703.543154] __cancel_work_timer+0x136/0x1b0
      [97703.543175] ? mlxsw_reg_trans_bulk_wait+0x145/0x400 [mlxsw_core]
      [97703.543184] cancel_work_sync+0x10/0x20
      [97703.543191] rhashtable_free_and_destroy+0x23/0x140
      [97703.543198] rhashtable_destroy+0xd/0x10
      [97703.543254] mlxsw_sp_fib_destroy+0xb1/0xf0 [mlxsw_spectrum]
      [97703.543310] mlxsw_sp_vr_put+0xa8/0xc0 [mlxsw_spectrum]
      [97703.543364] mlxsw_sp_fib_node_put+0xbf/0x140 [mlxsw_spectrum]
      [97703.543418] ? mlxsw_sp_fib6_entry_destroy+0xe8/0x110 [mlxsw_spectrum]
      [97703.543475] mlxsw_sp_router_fib6_event_work+0x6cd/0x7f0 [mlxsw_spectrum]
      [97703.543484] process_one_work+0x1fd/0x400
      [97703.543493] worker_thread+0x34/0x410
      [97703.543500] kthread+0x121/0x140
      [97703.543507] ? process_one_work+0x400/0x400
      [97703.543512] ? kthread_park+0x90/0x90
      [97703.543523] ret_from_fork+0x35/0x40
      
      Fixes: a3832b31 ("mlxsw: core: Create an ordered workqueue for FIB offload")
      Signed-off-by: NIdo Schimmel <idosch@mellanox.com>
      Reported-by: NSemion Lisyansky <semionl@mellanox.com>
      Acked-by: NJiri Pirko <jiri@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NSasha Levin <alexander.levin@microsoft.com>
      835ae6cc
    • I
      mlxsw: core: Do not use WQ_MEM_RECLAIM for EMAD workqueue · 880a328e
      Ido Schimmel 提交于
      [ Upstream commit a8c133b06183c529c51cd0d54eb57d6b7078370c ]
      
      The EMAD workqueue is used to handle retransmission of EMAD packets that
      contain configuration data for the device's firmware.
      
      Given the workers need to allocate these packets and that the code is
      not called as part of memory reclaim path, remove the WQ_MEM_RECLAIM
      flag.
      
      Fixes: d965465b ("mlxsw: core: Fix possible deadlock")
      Signed-off-by: NIdo Schimmel <idosch@mellanox.com>
      Acked-by: NJiri Pirko <jiri@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NSasha Levin <alexander.levin@microsoft.com>
      880a328e
    • I
      mlxsw: spectrum_switchdev: Add MDB entries in prepare phase · a80f62f7
      Ido Schimmel 提交于
      [ Upstream commit d4d0e40977ac450f32f2db5e4d8e23c9d2578899 ]
      
      The driver cannot guarantee in the prepare phase that it will be able to
      write an MDB entry to the device. In case the driver returned success
      during the prepare phase, but then failed to add the entry in the commit
      phase, a WARNING [1] will be generated by the switchdev core.
      
      Fix this by doing the work in the prepare phase instead.
      
      [1]
      [  358.544486] swp12s0: Commit of object (id=2) failed.
      [  358.550061] WARNING: CPU: 0 PID: 30 at net/switchdev/switchdev.c:281 switchdev_port_obj_add_now+0x9b/0xe0
      [  358.560754] CPU: 0 PID: 30 Comm: kworker/0:1 Not tainted 5.0.0-custom-13382-gf2449babf221 #1350
      [  358.570472] Hardware name: Mellanox Technologies Ltd. MSN2100-CB2FO/SA001017, BIOS 5.6.5 06/07/2016
      [  358.580582] Workqueue: events switchdev_deferred_process_work
      [  358.587001] RIP: 0010:switchdev_port_obj_add_now+0x9b/0xe0
      ...
      [  358.614109] RSP: 0018:ffffa6b900d6fe18 EFLAGS: 00010286
      [  358.619943] RAX: 0000000000000000 RBX: ffff8b00797ff000 RCX: 0000000000000000
      [  358.627912] RDX: ffff8b00b7a1d4c0 RSI: ffff8b00b7a152e8 RDI: ffff8b00b7a152e8
      [  358.635881] RBP: ffff8b005c3f5bc0 R08: 000000000000022b R09: 0000000000000000
      [  358.643850] R10: 0000000000000000 R11: ffffa6b900d6fcc8 R12: 0000000000000000
      [  358.651819] R13: dead000000000100 R14: ffff8b00b65a23c0 R15: 0ffff8b00b7a2200
      [  358.659790] FS:  0000000000000000(0000) GS:ffff8b00b7a00000(0000) knlGS:0000000000000000
      [  358.668820] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [  358.675228] CR2: 00007f00aad90de0 CR3: 00000001ca80d000 CR4: 00000000001006f0
      [  358.683188] Call Trace:
      [  358.685918]  switchdev_port_obj_add_deferred+0x13/0x60
      [  358.691655]  switchdev_deferred_process+0x6b/0xf0
      [  358.696907]  switchdev_deferred_process_work+0xa/0x10
      [  358.702548]  process_one_work+0x1f5/0x3f0
      [  358.707022]  worker_thread+0x28/0x3c0
      [  358.711099]  ? process_one_work+0x3f0/0x3f0
      [  358.715768]  kthread+0x10d/0x130
      [  358.719369]  ? __kthread_create_on_node+0x180/0x180
      [  358.724815]  ret_from_fork+0x35/0x40
      
      Fixes: 3a49b4fd ("mlxsw: Adding layer 2 multicast support")
      Signed-off-by: NIdo Schimmel <idosch@mellanox.com>
      Reported-by: NAlex Kushnarov <alexanderk@mellanox.com>
      Tested-by: NAlex Kushnarov <alexanderk@mellanox.com>
      Acked-by: NJiri Pirko <jiri@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NSasha Levin <alexander.levin@microsoft.com>
      a80f62f7
  7. 02 5月, 2019 3 次提交
  8. 06 4月, 2019 1 次提交
    • F
      mlxsw: spectrum: Avoid -Wformat-truncation warnings · a64ffbaf
      Florian Fainelli 提交于
      [ Upstream commit ab2c4e2581ad32c28627235ff0ae8c5a5ea6899f ]
      
      Give precision identifiers to the two snprintf() formatting the priority
      and TC strings to avoid producing these two warnings:
      
      drivers/net/ethernet/mellanox/mlxsw/spectrum.c: In function
      'mlxsw_sp_port_get_prio_strings':
      drivers/net/ethernet/mellanox/mlxsw/spectrum.c:2132:37: warning: '%d'
      directive output may be truncated writing between 1 and 3 bytes into a
      region of size between 0 and 31 [-Wformat-truncation=]
         snprintf(*p, ETH_GSTRING_LEN, "%s_%d",
                                           ^~
      drivers/net/ethernet/mellanox/mlxsw/spectrum.c:2132:3: note: 'snprintf'
      output between 3 and 36 bytes into a destination of size 32
         snprintf(*p, ETH_GSTRING_LEN, "%s_%d",
         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
           mlxsw_sp_port_hw_prio_stats[i].str, prio);
           ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      drivers/net/ethernet/mellanox/mlxsw/spectrum.c: In function
      'mlxsw_sp_port_get_tc_strings':
      drivers/net/ethernet/mellanox/mlxsw/spectrum.c:2143:37: warning: '%d'
      directive output may be truncated writing between 1 and 11 bytes into a
      region of size between 0 and 31 [-Wformat-truncation=]
         snprintf(*p, ETH_GSTRING_LEN, "%s_%d",
                                           ^~
      drivers/net/ethernet/mellanox/mlxsw/spectrum.c:2143:3: note: 'snprintf'
      output between 3 and 44 bytes into a destination of size 32
         snprintf(*p, ETH_GSTRING_LEN, "%s_%d",
         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
           mlxsw_sp_port_hw_tc_stats[i].str, tc);
           ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      Signed-off-by: NFlorian Fainelli <f.fainelli@gmail.com>
      Reviewed-by: NIdo Schimmel <idosch@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      a64ffbaf
  9. 27 2月, 2019 3 次提交
  10. 23 2月, 2019 1 次提交
  11. 13 2月, 2019 2 次提交
    • I
      mlxsw: spectrum: Properly cleanup LAG uppers when removing port from LAG · b124f086
      Ido Schimmel 提交于
      [ Upstream commit be2d6f421f680e01d58f7cd452646e0d8586d49b ]
      
      When a LAG device or a VLAN device on top of it is enslaved to a bridge,
      the driver propagates the CHANGEUPPER event to the LAG's slaves.
      
      This causes each physical port to increase the reference count of the
      internal representation of the bridge port by calling
      mlxsw_sp_port_bridge_join().
      
      However, when a port is removed from a LAG, the corresponding leave()
      function is not called and the reference count is not decremented. This
      leads to ugly hacks such as mlxsw_sp_bridge_port_should_destroy() that
      try to understand if the bridge port should be destroyed even when its
      reference count is not 0.
      
      Instead, make sure that when a port is unlinked from a LAG it would see
      the same events as if the LAG (or its uppers) were unlinked from a
      bridge.
      
      The above is achieved by walking the LAG's uppers when a port is
      unlinked and calling mlxsw_sp_port_bridge_leave() for each upper that is
      enslaved to a bridge.
      Signed-off-by: NIdo Schimmel <idosch@mellanox.com>
      Reviewed-by: NPetr Machata <petrm@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      b124f086
    • N
      mlxsw: spectrum_acl: Limit priority value · 702286d3
      Nir Dotan 提交于
      [ Upstream commit d7263ab35be25505ab57ebecd93cbc5dba8be717 ]
      
      In Spectrum-2, higher priority value wins and priority valid values are in
      the range of {1,cap_kvd_size-1}. mlxsw_sp_acl_tcam_priority_get converts
      from lower-bound priorities alike tc flower to Spectrum-2 HW range. Up
      until now tc flower did not provide priority 0 or reached the maximal
      value, however multicast routing does provide priority 0.
      
      Therefore, Change mlxsw_sp_acl_tcam_priority_get to verify priority is in
      the correct range. Make sure priority is never set to zero and never
      exceeds the maximal allowed value.
      Signed-off-by: NNir Dotan <nird@mellanox.com>
      Reviewed-by: NJiri Pirko <jiri@mellanox.com>
      Signed-off-by: NIdo Schimmel <idosch@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      702286d3
  12. 31 1月, 2019 3 次提交
    • I
      mlxsw: pci: Ring CQ's doorbell before RDQ's · bdafc159
      Ido Schimmel 提交于
      When a packet should be trapped to the CPU the device consumes a WQE
      (work queue element) from an RDQ (receive descriptor queue) and copies
      the packet to the address specified in the WQE. The device then tries to
      post a CQE (completion queue element) that contains various metadata
      (e.g., ingress port) about the packet to a CQ (completion queue).
      
      In case the device managed to consume a WQE, but did not manage to post
      the corresponding CQE, it will get stuck. This unlikely situation can be
      triggered due to the scheme the driver is currently using to process
      CQEs.
      
      The driver will consume up to 512 CQEs at a time and after processing
      each corresponding WQE it will ring the RDQ's doorbell, letting the
      device know that a new WQE was posted for it to consume. Only after
      processing all the CQEs (up to 512), the driver will ring the CQ's
      doorbell, letting the device know that new ones can be posted.
      
      Fix this by having the driver ring the CQ's doorbell for every processed
      CQE, but before ringing the RDQ's doorbell. This guarantees that
      whenever we post a new WQE, there is a corresponding CQE available. Copy
      the currently processed CQE to prevent the device from overwriting it
      with a new CQE after ringing the doorbell.
      
      Note that the driver still arms the CQ only after processing all the
      pending CQEs, so that interrupts for this CQ will only be delivered
      after the driver finished its processing.
      
      Before commit 8404f6f2 ("mlxsw: pci: Allow to use CQEs of version 1
      and version 2") the issue was virtually impossible to trigger since the
      number of CQEs was twice the number of WQEs and the number of CQEs
      processed at a time was equal to the number of available WQEs.
      
      Fixes: 8404f6f2 ("mlxsw: pci: Allow to use CQEs of version 1 and version 2")
      Signed-off-by: NIdo Schimmel <idosch@mellanox.com>
      Reported-by: NSemion Lisyansky <semionl@mellanox.com>
      Tested-by: NSemion Lisyansky <semionl@mellanox.com>
      Acked-by: NJiri Pirko <jiri@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      bdafc159
    • N
      mlxsw: spectrum_fid: Update dummy FID index · c82f4684
      Nir Dotan 提交于
      [ Upstream commit a11dcd6497915ba79d95ef4fe2541aaac27f6201 ]
      
      When using a tc flower action of egress mirred redirect, the driver adds
      an implicit FID setting action. This implicit action sets a dummy FID to
      the packet and is used as part of a design for trapping unmatched flows
      in OVS.  While this implicit FID setting action is supposed to be a NOP
      when a redirect action is added, in Spectrum-2 the FID record is
      consulted as the dummy FID index is an 802.1D FID index and the packet
      is dropped instead of being redirected.
      
      Set the dummy FID index value to be within 802.1Q range. This satisfies
      both Spectrum-1 which ignores the FID and Spectrum-2 which identifies it
      as an 802.1Q FID and will then follow the redirect action.
      
      Fixes: c3ab4354 ("mlxsw: spectrum: Extend to support Spectrum-2 ASIC")
      Signed-off-by: NNir Dotan <nird@mellanox.com>
      Signed-off-by: NIdo Schimmel <idosch@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c82f4684
    • N
      mlxsw: pci: Increase PCI SW reset timeout · bc4e2300
      Nir Dotan 提交于
      [ Upstream commit d2f372ba0914e5722ac28e15f2ed2db61bcf0e44 ]
      
      Spectrum-2 PHY layer introduces a calibration period which is a part of the
      Spectrum-2 firmware boot process. Hence increase the SW timeout waiting for
      the firmware to come out of boot. This does not increase system boot time
      in cases where the firmware PHY calibration process is done quickly.
      
      Fixes: c3ab4354 ("mlxsw: spectrum: Extend to support Spectrum-2 ASIC")
      Signed-off-by: NNir Dotan <nird@mellanox.com>
      Acked-by: NJiri Pirko <jiri@mellanox.com>
      Signed-off-by: NIdo Schimmel <idosch@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      bc4e2300
  13. 26 1月, 2019 2 次提交
  14. 10 1月, 2019 1 次提交
    • S
      mlxsw: core: Increase timeout during firmware flash process · af93ac09
      Shalom Toledo 提交于
      [ Upstream commit cf0b70e71b32137ccf9c1f3dd9fb30cbf89b4322 ]
      
      During the firmware flash process, some of the EMADs get timed out, which
      causes the driver to send them again with a limit of 5 retries. There are
      some situations in which 5 retries is not enough and the EMAD access fails.
      If the failed EMAD was related to the flashing process, the driver fails
      the flashing.
      
      The reason for these timeouts during firmware flashing is cache misses in
      the CPU running the firmware. In case the CPU needs to fetch instructions
      from the flash when a firmware is flashed, it needs to wait for the
      flashing to complete. Since flashing takes time, it is possible for pending
      EMADs to timeout.
      
      Fix by increasing EMADs' timeout while flashing firmware.
      
      Fixes: ce6ef68f ("mlxsw: spectrum: Implement the ethtool flash_device callback")
      Signed-off-by: NShalom Toledo <shalomt@mellanox.com>
      Signed-off-by: NIdo Schimmel <idosch@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      af93ac09
  15. 21 12月, 2018 1 次提交
    • I
      mlxsw: spectrum_switchdev: Fix VLAN device deletion via ioctl · 8175f9d3
      Ido Schimmel 提交于
      [ Upstream commit 993107fe ]
      
      When deleting a VLAN device using an ioctl the netdev is unregistered
      before the VLAN filter is updated via ndo_vlan_rx_kill_vid(). It can
      lead to a use-after-free in mlxsw in case the VLAN device is deleted
      while being enslaved to a bridge.
      
      The reason for the above is that when mlxsw receives the CHANGEUPPER
      event, it wrongly assumes that the VLAN device is no longer its upper
      and thus destroys the internal representation of the bridge port despite
      the reference count being non-zero.
      
      Fix this by checking if the VLAN device is our upper using its real
      device. In net-next I'm going to remove this trick and instead make
      mlxsw completely agnostic to the order of the events.
      
      Fixes: c57529e1 ("mlxsw: spectrum: Replace vPorts with Port-VLAN")
      Signed-off-by: NIdo Schimmel <idosch@mellanox.com>
      Reviewed-by: NPetr Machata <petrm@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      8175f9d3
  16. 23 11月, 2018 1 次提交
  17. 04 11月, 2018 2 次提交
  18. 18 10月, 2018 1 次提交
  19. 05 10月, 2018 2 次提交
  20. 20 9月, 2018 1 次提交
  21. 05 9月, 2018 1 次提交
    • P
      mlxsw: spectrum_buffers: Set up a dedicated pool for BUM traffic · 3a3539cd
      Petr Machata 提交于
      MC-aware mode was recently enabled by mlxsw on Spectrum switches in
      commit 7b819530 ("mlxsw: spectrum: Configure MC-aware mode on mlxsw
      ports"). Unfortunately, testing has shown that the fix is incomplete and
      in the presented form actually makes the problem even worse, because any
      amount of MC traffic causes UC disruption.
      
      The reason for this is that currently, mlxsw configures the MC-specific
      TCs (8..15) to map to pool 0. It also configures a maximum buffer size
      of 0, but for MC traffic that maximum is disregarded and not part of the
      quota. Therefore MC traffic is always admitted to the egress buffer.
      
      Fix the configuration by directing the MC TCs into pool 15, which is
      dedicated to MC traffic and recognized as such by the silicon.
      
      Fixes: 7b819530 ("mlxsw: spectrum: Configure MC-aware mode on mlxsw ports")
      Signed-off-by: NPetr Machata <petrm@mellanox.com>
      Acked-by: NJiri Pirko <jiri@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      3a3539cd
  22. 26 8月, 2018 1 次提交
    • I
      mlxsw: spectrum_switchdev: Do not leak RIFs when removing bridge · 602b74ed
      Ido Schimmel 提交于
      When a bridge device is removed, the VLANs are flushed from each
      configured port. This causes the ports to decrement the reference count
      on the associated FIDs (filtering identifier). If the reference count of
      a FID is 1 and it has a RIF (router interface), then this RIF is
      destroyed.
      
      However, if no port is member in the VLAN for which a RIF exists, then
      the RIF will continue to exist after the removal of the bridge. To
      reproduce:
      
      # ip link add name br0 type bridge vlan_filtering 1
      # ip link set dev swp1 master br0
      # ip link add link br0 name br0.10 type vlan id 10
      # ip address add 192.0.2.0/24 dev br0.10
      # ip link del dev br0
      
      The RIF associated with br0.10 continues to exist.
      
      Fix this by iterating over all the bridge device uppers when it is
      destroyed and take care of destroying their RIFs.
      
      Fixes: 99f44bb3 ("mlxsw: spectrum: Enable L3 interfaces on top of bridge devices")
      Signed-off-by: NIdo Schimmel <idosch@mellanox.com>
      Reviewed-by: NPetr Machata <petrm@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      602b74ed
  23. 22 8月, 2018 1 次提交
  24. 11 8月, 2018 2 次提交
  25. 10 8月, 2018 2 次提交