1. 28 9月, 2017 1 次提交
  2. 31 8月, 2017 2 次提交
  3. 29 8月, 2017 1 次提交
  4. 25 8月, 2017 1 次提交
  5. 24 8月, 2017 1 次提交
  6. 23 8月, 2017 1 次提交
  7. 09 8月, 2017 2 次提交
  8. 07 8月, 2017 2 次提交
    • E
      net/mlx5: Delay events till ib registration ends · 97834eba
      Erez Shitrit 提交于
      When mlx5_ib registers itself to mlx5_core as an interface, it will
      call mlx5_add_device which will call mlx5_ib interface add callback,
      in case the latter successfully returns, only then mlx5_core will add
      it to the interface list and async events will be forwarded to mlx5_ib.
      Between mlx5_ib interface add callback and mlx5_core adding the mlx5_ib
      interface to its devices list, arriving mlx5_core events can be missed
      by the new mlx5_ib registering interface.
      
      In other words:
      thread 1: mlx5_ib: mlx5_register_interface(dev)
      thread 1: mlx5_core: mlx5_add_device(dev)
      thread 1: mlx5_core: ctx = dev->add => (mlx5_ib)->mlx5_ib_add
      thread 2: mlx5_core_event: **new event arrives, forward to dev_list
      thread 1: mlx5_core: add_ctx_to_dev_list(ctx)
      /* previous event was missed by the new interface.*/
      It is ok to miss events before dev->add (mlx5_ib)->mlx5_ib_add_device
      but not after.
      
      We fix this race by accumulating the events that come between the
      ib_register_device (inside mlx5_add_device->(dev->add)) till the adding
      to the list completes and fire them to the new registering interface
      after that.
      
      Fixes: f1ee87fe ("net/mlx5: Organize device list API in one place")
      Signed-off-by: NErez Shitrit <erezsh@mellanox.com>
      Signed-off-by: NSaeed Mahameed <saeedm@mellanox.com>
      97834eba
    • S
      net/mlx5: Separate between E-Switch and MPFS · eeb66cdb
      Saeed Mahameed 提交于
      Multi-Physical Function Switch (MPFs) is required for when multi-PF
      configuration is enabled to allow passing user configured unicast MAC
      addresses to the requesting PF.
      
      Before this patch eswitch.c used to manage the HW MPFS l2 table,
      E-Switch always (regardless of sriov) enabled vport(0) (NIC PF) vport's
      contexts update on unicast mac address list changes, to populate the PF's
      MPFS L2 table accordingly.
      
      In downstream patch we would like to allow compiling the driver without
      E-Switch functionalities, for that we move MPFS l2 table logic out
      of eswitch.c into its own file, and provide Kconfig flag (MLX5_MPFS) to
      allow compiling out MPFS for those who don't want Multi-PF support.
      
      NIC PF netdevice will now directly update MPFS l2 table via the new MPFS
      API. VF netdevice has no access to MPFS L2 table, so E-Switch will remain
      responsible of updating its MPFS l2 table on behalf of its VFs.
      
      Due to this change we also don't require enabling vport(0) (PF vport)
      unicast mac changes events anymore, for when SRIOV is not enabled.
      Which means E-Switch is now activated only on SRIOV activation, and not
      required otherwise.
      Signed-off-by: NSaeed Mahameed <saeedm@mellanox.com>
      Cc: Jes Sorensen <jsorensen@fb.com>
      Cc: kernel-team@fb.com
      eeb66cdb
  9. 24 7月, 2017 2 次提交
  10. 27 6月, 2017 4 次提交
    • I
      net/mlx5: FPGA, Add SBU infrastructure · a9956d35
      Ilan Tayari 提交于
      Add interface to initialize and interact with Innova FPGA SBU
      connections.
      A client driver may use these functions to set up a high-speed DMA
      connection with its SBU hardware logic, and send/receive messages
      over this connection.
      
      A later patch in this patchset will make use of these functions for
      Innova IPSec offload in mlx5 Ethernet driver.
      
      Add commands to retrieve Innova FPGA SBU capabilities, and to
      read/write Innova FPGA configuration space registers and memory,
      over internal I2C.
      
      At high level, the FPGA configuration space is divided such:
       0x00000000 - 0x007fffff is reserved for the SBU
       0x00800000 - 0xffffffff is reserved for the Shell
      0x400000000 - ...        is DDR memory
      
      A later patchset will add support for accessing FPGA CrSpace and memory
      over a high-speed connection. This is the reason for the ACCESS_TYPE
      enumeration, which currently only supports I2C.
      Signed-off-by: NIlan Tayari <ilant@mellanox.com>
      Signed-off-by: NSaeed Mahameed <saeedm@mellanox.com>
      a9956d35
    • I
      net/mlx5: Add support for multiple RoCE enable · a6f7d2af
      Ilan Tayari 提交于
      Previously, only mlx5_ib enabled RoCE on the port, but FPGA needs it as
      well.
      Add support for counting number of enables, so that FPGA and IB can work
      in parallel and independently.
      Program the HW to enable RoCE on the first enable call, and program to
      disable RoCE on the last disable call.
      Signed-off-by: NIlan Tayari <ilant@mellanox.com>
      Reviewed-by: NBoris Pismenny <borisp@mellanox.com>
      Signed-off-by: NSaeed Mahameed <saeedm@mellanox.com>
      a6f7d2af
    • I
      net/mlx5: Add reserved-gids support · 52ec462e
      Ilan Tayari 提交于
      Reserved GIDs are entries in the GID table in use by the mlx5_core
      and its submodules (e.g. FPGA, SRIOV, E-Swtich, netdev).
      The entries are reserved at the high indexes of the GID table.
      
      A mlx5 submodule may reserve a certain amount of GIDs for its own use
      during the load sequence by calling mlx5_core_reserve_gids, and must
      also take care to un-reserve these GIDs when it closes.
      Reservation is only allowed during the load sequence and before any
      interfaces (e.g. mlx5_ib or mlx5_en) are up.
      
      After reservation, a submodule may call mlx5_core_reserved_gid_alloc/
      free to allocate entries from the reserved GIDs pool.
      
      Reserve a GID table entry for every supported FPGA QP.
      
      A later patch in the patchset will remove them from being reported to
      IB core.
      Another such patch will make use of these for FPGA QPs in Innova NIC.
      
      Added lib/mlx5.h to serve as a library for mlx5 submodlues, and to
      expose only public mlx5 API, more mlx5 library files will be added in
      future submissions.
      Signed-off-by: NIlan Tayari <ilant@mellanox.com>
      Signed-off-by: NSaeed Mahameed <saeedm@mellanox.com>
      52ec462e
    • M
      net/mlx5: Cancel delayed recovery work when unloading the driver · 2a0165a0
      Mohamad Haj Yahia 提交于
      Draining the health workqueue will ignore future health works including
      the one that report hardware failure and thus we can't enter error state
      Instead cancel the recovery flow and make sure only recovery flow won't
      be scheduled.
      
      Fixes: 5e44fca5 ('net/mlx5: Only cancel recovery work when cleaning up device')
      Signed-off-by: NMohamad Haj Yahia <mohamad@mellanox.com>
      Signed-off-by: NMoshe Shemesh <moshe@mellanox.com>
      Signed-off-by: NSaeed Mahameed <saeedm@mellanox.com>
      2a0165a0
  11. 22 6月, 2017 1 次提交
  12. 16 6月, 2017 1 次提交
  13. 23 5月, 2017 1 次提交
    • M
      net/mlx5: Avoid using pending command interface slots · 73dd3a48
      Mohamad Haj Yahia 提交于
      Currently when firmware command gets stuck or it takes long time to
      complete, the driver command will get timeout and the command slot is
      freed and can be used for new commands, and if the firmware receive new
      command on the old busy slot its behavior is unexpected and this could
      be harmful.
      To fix this when the driver command gets timeout we return failure,
      but we don't free the command slot and we wait for the firmware to
      explicitly respond to that command.
      Once all the entries are busy we will stop processing new firmware
      commands.
      
      Fixes: 9cba4ebc ('net/mlx5: Fix potential deadlock in command mode change')
      Signed-off-by: NMohamad Haj Yahia <mohamad@mellanox.com>
      Cc: kernel-team@fb.com
      Signed-off-by: NSaeed Mahameed <saeedm@mellanox.com>
      73dd3a48
  14. 14 5月, 2017 3 次提交
  15. 09 5月, 2017 1 次提交
    • M
      treewide: use kv[mz]alloc* rather than opencoded variants · 752ade68
      Michal Hocko 提交于
      There are many code paths opencoding kvmalloc.  Let's use the helper
      instead.  The main difference to kvmalloc is that those users are
      usually not considering all the aspects of the memory allocator.  E.g.
      allocation requests <= 32kB (with 4kB pages) are basically never failing
      and invoke OOM killer to satisfy the allocation.  This sounds too
      disruptive for something that has a reasonable fallback - the vmalloc.
      On the other hand those requests might fallback to vmalloc even when the
      memory allocator would succeed after several more reclaim/compaction
      attempts previously.  There is no guarantee something like that happens
      though.
      
      This patch converts many of those places to kv[mz]alloc* helpers because
      they are more conservative.
      
      Link: http://lkml.kernel.org/r/20170306103327.2766-2-mhocko@kernel.orgSigned-off-by: NMichal Hocko <mhocko@suse.com>
      Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> # Xen bits
      Acked-by: NKees Cook <keescook@chromium.org>
      Acked-by: NVlastimil Babka <vbabka@suse.cz>
      Acked-by: Andreas Dilger <andreas.dilger@intel.com> # Lustre
      Acked-by: Christian Borntraeger <borntraeger@de.ibm.com> # KVM/s390
      Acked-by: Dan Williams <dan.j.williams@intel.com> # nvdim
      Acked-by: David Sterba <dsterba@suse.com> # btrfs
      Acked-by: Ilya Dryomov <idryomov@gmail.com> # Ceph
      Acked-by: Tariq Toukan <tariqt@mellanox.com> # mlx4
      Acked-by: Leon Romanovsky <leonro@mellanox.com> # mlx5
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: Herbert Xu <herbert@gondor.apana.org.au>
      Cc: Anton Vorontsov <anton@enomsg.org>
      Cc: Colin Cross <ccross@android.com>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
      Cc: Ben Skeggs <bskeggs@redhat.com>
      Cc: Kent Overstreet <kent.overstreet@gmail.com>
      Cc: Santosh Raspatur <santosh@chelsio.com>
      Cc: Hariprasad S <hariprasad@chelsio.com>
      Cc: Yishai Hadas <yishaih@mellanox.com>
      Cc: Oleg Drokin <oleg.drokin@intel.com>
      Cc: "Yan, Zheng" <zyan@redhat.com>
      Cc: Alexander Viro <viro@zeniv.linux.org.uk>
      Cc: Alexei Starovoitov <ast@kernel.org>
      Cc: Eric Dumazet <eric.dumazet@gmail.com>
      Cc: David Miller <davem@davemloft.net>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      752ade68
  16. 05 5月, 2017 1 次提交
  17. 30 4月, 2017 1 次提交
    • H
      net/mlx5e: Update neighbour 'used' state using HW flow rules counters · f6dfb4c3
      Hadar Hen Zion 提交于
      When IP tunnel encapsulation rules are offloaded, the kernel can't see
      the traffic of the offloaded flow. The neighbour for the IP tunnel
      destination of the offloaded flow can mistakenly become STALE and
      deleted by the kernel since its 'used' value wasn't changed.
      
      To make sure that a neighbour which is used by the HW won't become
      STALE, we proactively update the neighbour 'used' value every
      DELAY_PROBE_TIME period, when packets were matched and counted by the HW
      for one of the tunnel encap flows related to this neighbour.
      
      The periodic task that updates the used neighbours is scheduled when a
      tunnel encap rule is successfully offloaded into HW and keeps re-scheduling
      itself as long as the representor's neighbours list isn't empty.
      
      Add, remove, lookup and status change operations done over the
      representor's neighbours list or the neighbour hash entry encaps list
      are all serialized by RTNL lock.
      Signed-off-by: NHadar Hen Zion <hadarh@mellanox.com>
      Reviewed-by: NOr Gerlitz <ogerlitz@mellanox.com>
      Signed-off-by: NSaeed Mahameed <saeedm@mellanox.com>
      f6dfb4c3
  18. 25 3月, 2017 1 次提交
  19. 15 2月, 2017 2 次提交
  20. 14 2月, 2017 1 次提交
  21. 20 1月, 2017 5 次提交
  22. 10 1月, 2017 4 次提交
  23. 08 1月, 2017 1 次提交
    • E
      net/mlx5: Introduce blue flame register allocator · a6d51b68
      Eli Cohen 提交于
      Here is an implementation of an allocator that allocates blue flame
      registers. A blue flame register is used for generating send doorbells.
      A blue flame register can be used to generate either a regular doorbell
      or a blue flame doorbell where the data to be sent is written to the
      device's I/O memory hence saving the need to read the data from memory.
      For blue flame kind of doorbells to succeed, the blue flame register
      need to be mapped as write combining. The user can specify what kind of
      send doorbells she wishes to use. If she requested write combining
      mapping but that failed, the allocator will fall back to non write
      combining mapping and will indicate that to the user.
      Subsequent patches in this series will make use of this allocator.
      Signed-off-by: NEli Cohen <eli@mellanox.com>
      Reviewed-by: NMatan Barak <matanb@mellanox.com>
      Signed-off-by: NLeon Romanovsky <leon@kernel.org>
      Signed-off-by: NSaeed Mahameed <saeedm@mellanox.com>
      a6d51b68