1. 13 6月, 2015 10 次提交
    • I
      IB/mad: Add final OPA MAD processing · 8e4349d1
      Ira Weiny 提交于
      For devices which support OPA MADs
      
         1) Use previously defined SMP support functions.
      
         2) Pass correct base version to ib_create_send_mad when processing OPA MADs.
      
         3) Process out_mad_key_index returned by agents for a response.  This is
            necessary because OPA SMP packets must carry a valid pkey.
      
         4) Carry the correct segment size (OPA vs IBTA) of RMPP messages within
            ib_mad_recv_wc.
      
         5) Handle variable length OPA MADs by:
      
              * Adjusting the 'fake' WC for locally routed SMP's to represent the
                proper incoming byte_len
              * out_mad_size is used from the local HCA agents
                      1) when sending agent responses on the wire
                      2) when passing responses through the local_completions
      		   function
      
      	NOTE: wc.byte_len includes the GRH length and therefore is different
      	      from the in_mad_size specified to the local HCA agents.
      	      out_mad_size should _not_ include the GRH length as it is added
      Signed-off-by: NIra Weiny <ira.weiny@intel.com>
      Signed-off-by: NDoug Ledford <dledford@redhat.com>
      8e4349d1
    • I
      IB/mad: Add partial Intel OPA MAD support · 548ead17
      Ira Weiny 提交于
      This patch is the first of 3 which adds processing of OPA MADs
      
      1) Add Intel Omni-Path Architecture defines
      2) Increase max management version to accommodate OPA
      3) update ib_create_send_mad
      	If the device supports OPA MADs and the MAD being sent is the OPA base
      	version alter the MAD size and sg lengths as appropriate
      Signed-off-by: NIra Weiny <ira.weiny@intel.com>
      Signed-off-by: NDoug Ledford <dledford@redhat.com>
      548ead17
    • I
      IB/mad: Add support for additional MAD info to/from drivers · 4cd7c947
      Ira Weiny 提交于
      In order to support alternate sized MADs (and variable sized MADs on OPA
      devices) add in/out MAD size parameters to the process_mad core call.
      
      In addition, add an out_mad_pkey_index to communicate the pkey index the driver
      wishes the MAD stack to use when sending OPA MAD responses.
      
      The out MAD size and the out MAD PKey index are required by the MAD
      stack to generate responses on OPA devices.
      
      Furthermore, the in and out MAD parameters are made generic by specifying them
      as ib_mad_hdr rather than ib_mad.
      
      Drivers are modified as needed and are protected by BUG_ON flags if the MAD
      sizes passed to them is incorrect.
      Signed-off-by: NIra Weiny <ira.weiny@intel.com>
      Signed-off-by: NDoug Ledford <dledford@redhat.com>
      4cd7c947
    • I
      IB/mad: Convert allocations from kmem_cache to kzalloc · c9082e51
      Ira Weiny 提交于
      This patch implements allocating alternate receive MAD buffers within the MAD
      stack.  Support for OPA to send/recv variable sized MADs is implemented later.
      
          1) Convert MAD allocations from kmem_cache to kzalloc
      
             kzalloc is more flexible to support devices with different sized MADs
             and research and testing showed that the current use of kmem_cache does
             not provide performance benefits over kzalloc.
      
          2) Change struct ib_mad_private to use a flex array for the mad data
          3) Allocate ib_mad_private based on the size specified by devices in
             rdma_max_mad_size.
          4) Carry the allocated size in ib_mad_private to be used when processing
             ib_mad_private objects.
          5) Alter DMA mappings based on the mad_size of ib_mad_private.
          6) Replace the use of sizeof and static defines as appropriate
          7) Add appropriate casts for the MAD data when calling processing
             functions.
      Signed-off-by: NIra Weiny <ira.weiny@intel.com>
      Signed-off-by: NDoug Ledford <dledford@redhat.com>
      c9082e51
    • I
      IB/core: Add ability for drivers to report an alternate MAD size. · 337877a4
      Ira Weiny 提交于
      Add max MAD size to the device immutable data set and have all drivers that
      support MADs report the current IB MAD size (IB_MGMT_MAD_SIZE) to the core.
      
      Verify MAD size data in both the MAD core and when reading the immutable data.
      
      OPA drivers will report alternate MAD sizes in subsequent patches.
      Signed-off-by: NIra Weiny <ira.weiny@intel.com>
      Signed-off-by: NDoug Ledford <dledford@redhat.com>
      337877a4
    • I
      IB/mad: Support alternate Base Versions when creating MADs · da2dfaa3
      Ira Weiny 提交于
      In preparation to support the new OPA MAD Base version, add a base version
      parameter to ib_create_send_mad and set it to IB_MGMT_BASE_VERSION for current
      users.
      
      Definition of the new base version and it's processing will occur in later
      patches.
      Signed-off-by: NIra Weiny <ira.weiny@intel.com>
      Signed-off-by: NDoug Ledford <dledford@redhat.com>
      da2dfaa3
    • I
      IB/mad: Split IB SMI handling from MAD Recv handler · e11ae8aa
      Ira Weiny 提交于
      Make a helper function to process Directed Route SMPs to be called by the IB
      MAD Recv Handler, ib_mad_recv_done_handler.
      
      This cleans up the MAD receive handler code a bit and allows for us to better
      share the SMP processing code between IB and OPA SMPs.
      
      IB and OPA SMPs share the same processing algorithm but have different header
      formats and permissive LID detection.  Therefore this and subsequent patches
      split the common processing code from the IB specific code in anticipation of
      sharing those algorithms with the OPA code.
      Signed-off-by: NIra Weiny <ira.weiny@intel.com>
      Signed-off-by: NDoug Ledford <dledford@redhat.com>
      e11ae8aa
    • I
      IB/mad cleanup: Generalize processing of MAD data · 83a1d228
      Ira Weiny 提交于
      ib_find_send_mad only needs access to the MAD header not the full IB MAD.
      Change the local variable to ib_mad_hdr and change the corresponding cast.
      
      This allows for clean usage of this function with both IB and OPA MADs because
      OPA MADs carry the same header as IB MADs.
      Signed-off-by: NIra Weiny <ira.weiny@intel.com>
      Signed-off-by: NDoug Ledford <dledford@redhat.com>
      83a1d228
    • I
      IB/mad cleanup: Clean up function params -- find_mad_agent · d94bd266
      Ira Weiny 提交于
      find_mad_agent only needs read only access to the MAD header.  Update the
      ib_mad pointer to be const ib_mad_hdr.  Adjust call tree.
      Signed-off-by: NIra Weiny <ira.weiny@intel.com>
      Signed-off-by: NDoug Ledford <dledford@redhat.com>
      d94bd266
    • M
      IB/core: Change ib_create_cq to use struct ib_cq_init_attr · 8e37210b
      Matan Barak 提交于
      Currently, ib_create_cq uses cqe and comp_vecotr instead
      of the extendible ib_cq_init_attr struct.
      
      Earlier patches already changed the vendors to work with
      ib_cq_init_attr. This patch changes the consumers too.
      Signed-off-by: NMatan Barak <matanb@mellanox.com>
      Signed-off-by: NOr Gerlitz <ogerlitz@mellanox.com>
      Signed-off-by: NDoug Ledford <dledford@redhat.com>
      8e37210b
  2. 21 5月, 2015 4 次提交
  3. 19 5月, 2015 4 次提交
  4. 11 8月, 2014 4 次提交
  5. 02 4月, 2014 1 次提交
  6. 01 8月, 2013 1 次提交
    • J
      IB/core: Create QP1 using the pkey index which contains the default pkey · ef5ed416
      Jack Morgenstein 提交于
      Currently, QP1 is created using pkey index 0. This patch simply looks
      for the index containing the default pkey, rather than hard-coding
      pkey index 0.
      
      This change will have no effect in native mode, since QP0 and QP1 are
      created before the SM configures the port, so pkey table will still be
      the default table defined by the IB Spec, in C10-123: "If non-volatile
      storage is not used to hold P_Key Table contents, then if a PM
      (Partition Manager) is not present, and prior to PM initialization of
      the P_Key Table, the P_Key Table must act as if it contains a single
      valid entry, at P_Key_ix = 0, containing the default partition
      key. All other entries in the P_Key Table must be invalid."
      
      Thus, in the native mode case, the driver will find the default pkey
      at index 0 (so it will be no different than the hard-coding).
      
      However, in SR-IOV mode, for VFs, the pkey table may be
      paravirtualized, so that the VF's pkey index zero may not necessarily
      be mapped to the real pkey index 0. For VFs, therefore, it is
      important to find the virtual index which maps to the real default
      pkey.
      
      This commit does the following for QP1 creation:
      
      1. Find the pkey index containing the default pkey, and use that index
         if found.  ib_find_pkey() returns the index of the
         limited-membership default pkey (0x7FFF) if the full-member default
         pkey is not in the table.
      
      2. If neither form of the default pkey is found, use pkey index 0
         (previous behavior).
      Signed-off-by: NJack Morgenstein <jackm@dev.mellanox.co.il>
      Signed-off-by: NOr Gerlitz <ogerlitz@mellanox.com>
      Reviewed-by: NSean Hefty <sean.hefty@intel.com>
      Signed-off-by: NRoland Dreier <roland@purestorage.com>
      ef5ed416
  7. 22 8月, 2012 2 次提交
    • T
      workqueue: deprecate __cancel_delayed_work() · 136b5721
      Tejun Heo 提交于
      Now that cancel_delayed_work() can be safely called from IRQ handlers,
      there's no reason to use __cancel_delayed_work().  Use
      cancel_delayed_work() instead of __cancel_delayed_work() and mark the
      latter deprecated.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Acked-by: NJens Axboe <axboe@kernel.dk>
      Cc: Jiri Kosina <jkosina@suse.cz>
      Cc: Roland Dreier <roland@kernel.org>
      Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
      136b5721
    • T
      workqueue: use mod_delayed_work() instead of __cancel + queue · e7c2f967
      Tejun Heo 提交于
      Now that mod_delayed_work() is safe to call from IRQ handlers,
      __cancel_delayed_work() followed by queue_delayed_work() can be
      replaced with mod_delayed_work().
      
      Most conversions are straight-forward except for the following.
      
      * net/core/link_watch.c: linkwatch_schedule_work() was doing a quite
        elaborate dancing around its delayed_work.  Collapse it such that
        linkwatch_work is queued for immediate execution if LW_URGENT and
        existing timer is kept otherwise.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Tomi Valkeinen <tomi.valkeinen@ti.com> 
      e7c2f967
  8. 25 4月, 2012 2 次提交
  9. 26 2月, 2012 1 次提交
  10. 01 11月, 2011 1 次提交
  11. 07 10月, 2011 1 次提交
  12. 24 5月, 2011 1 次提交
  13. 14 10月, 2010 1 次提交
  14. 24 5月, 2010 1 次提交
  15. 16 5月, 2010 1 次提交
  16. 30 3月, 2010 1 次提交
    • T
      include cleanup: Update gfp.h and slab.h includes to prepare for breaking... · 5a0e3ad6
      Tejun Heo 提交于
      include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h
      
      percpu.h is included by sched.h and module.h and thus ends up being
      included when building most .c files.  percpu.h includes slab.h which
      in turn includes gfp.h making everything defined by the two files
      universally available and complicating inclusion dependencies.
      
      percpu.h -> slab.h dependency is about to be removed.  Prepare for
      this change by updating users of gfp and slab facilities include those
      headers directly instead of assuming availability.  As this conversion
      needs to touch large number of source files, the following script is
      used as the basis of conversion.
      
        http://userweb.kernel.org/~tj/misc/slabh-sweep.py
      
      The script does the followings.
      
      * Scan files for gfp and slab usages and update includes such that
        only the necessary includes are there.  ie. if only gfp is used,
        gfp.h, if slab is used, slab.h.
      
      * When the script inserts a new include, it looks at the include
        blocks and try to put the new include such that its order conforms
        to its surrounding.  It's put in the include block which contains
        core kernel includes, in the same order that the rest are ordered -
        alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
        doesn't seem to be any matching order.
      
      * If the script can't find a place to put a new include (mostly
        because the file doesn't have fitting include block), it prints out
        an error message indicating which .h file needs to be added to the
        file.
      
      The conversion was done in the following steps.
      
      1. The initial automatic conversion of all .c files updated slightly
         over 4000 files, deleting around 700 includes and adding ~480 gfp.h
         and ~3000 slab.h inclusions.  The script emitted errors for ~400
         files.
      
      2. Each error was manually checked.  Some didn't need the inclusion,
         some needed manual addition while adding it to implementation .h or
         embedding .c file was more appropriate for others.  This step added
         inclusions to around 150 files.
      
      3. The script was run again and the output was compared to the edits
         from #2 to make sure no file was left behind.
      
      4. Several build tests were done and a couple of problems were fixed.
         e.g. lib/decompress_*.c used malloc/free() wrappers around slab
         APIs requiring slab.h to be added manually.
      
      5. The script was run on all .h files but without automatically
         editing them as sprinkling gfp.h and slab.h inclusions around .h
         files could easily lead to inclusion dependency hell.  Most gfp.h
         inclusion directives were ignored as stuff from gfp.h was usually
         wildly available and often used in preprocessor macros.  Each
         slab.h inclusion directive was examined and added manually as
         necessary.
      
      6. percpu.h was updated not to include slab.h.
      
      7. Build test were done on the following configurations and failures
         were fixed.  CONFIG_GCOV_KERNEL was turned off for all tests (as my
         distributed build env didn't work with gcov compiles) and a few
         more options had to be turned off depending on archs to make things
         build (like ipr on powerpc/64 which failed due to missing writeq).
      
         * x86 and x86_64 UP and SMP allmodconfig and a custom test config.
         * powerpc and powerpc64 SMP allmodconfig
         * sparc and sparc64 SMP allmodconfig
         * ia64 SMP allmodconfig
         * s390 SMP allmodconfig
         * alpha SMP allmodconfig
         * um on x86_64 SMP allmodconfig
      
      8. percpu.h modifications were reverted so that it could be applied as
         a separate patch and serve as bisection point.
      
      Given the fact that I had only a couple of failures from tests on step
      6, I'm fairly confident about the coverage of this conversion patch.
      If there is a breakage, it's likely to be something in one of the arch
      headers which should be easily discoverable easily on most builds of
      the specific arch.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Guess-its-ok-by: NChristoph Lameter <cl@linux-foundation.org>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
      5a0e3ad6
  17. 12 3月, 2010 1 次提交
  18. 07 3月, 2010 1 次提交
  19. 07 9月, 2009 2 次提交
    • H
      IB/mad: Allow tuning of QP0 and QP1 sizes · b76aabc3
      Hal Rosenstock 提交于
      MADs are UD and can be dropped if there are no receives posted, so
      allow receive queue size to be set with a module parameter in case the
      queue needs to be lengthened.  Send side tuning is done for symmetry
      with receive.
      Signed-off-by: NHal Rosenstock <hal.rosenstock@gmail.com>
      Signed-off-by: NRoland Dreier <rolandd@cisco.com>
      b76aabc3
    • R
      IB/mad: Fix possible lock-lock-timer deadlock · 6b2eef8f
      Roland Dreier 提交于
      Lockdep reported a possible deadlock with cm_id_priv->lock,
      mad_agent_priv->lock and mad_agent_priv->timed_work.timer; this
      happens because the mad module does
      
      	cancel_delayed_work(&mad_agent_priv->timed_work);
      
      while holding mad_agent_priv->lock.  cancel_delayed_work() internally
      does del_timer_sync(&mad_agent_priv->timed_work.timer).
      
      This can turn into a deadlock because mad_agent_priv->lock is taken
      inside cm_id_priv->lock, so we can get the following set of contexts
      that deadlock each other:
      
       A: holding cm_id_priv->lock, waiting for mad_agent_priv->lock
       B: holding mad_agent_priv->lock, waiting for del_timer_sync()
       C: interrupt during mad_agent_priv->timed_work.timer that takes
          cm_id_priv->lock
      
      Fix this by using the new __cancel_delayed_work() interface (which
      internally does del_timer() instead of del_timer_sync()) in all the
      places where we are holding a lock.
      
      Addresses: http://bugzilla.kernel.org/show_bug.cgi?id=13757Reported-by: NBart Van Assche <bart.vanassche@gmail.com>
      Signed-off-by: NRoland Dreier <rolandd@cisco.com>
      6b2eef8f