Re: [PATCH v4 14/19] IB/core: Add IB_DEVICE_OPA_MAD_SUPPORT device cap flag

2015-02-06 Thread Hal Rosenstock
On 2/4/2015 6:29 PM, ira.we...@intel.com wrote:
 From: Ira Weiny ira.we...@intel.com
 
 OPA MADs share a common header with IBTA MADs but with a different base 
 version
 and an extended length.  These jumbo MADs increase the performance of
 management traffic.
 
 Sharing a common header with IBTA MADs allows us to share most of the MAD
 processing code when dealing with OPA MADs in addition to supporting some IBTA
 MADs on OPA devices.
 
 Add a device capability flag to indicate OPA MAD support on the device.
 
 Signed-off-by: Ira Weiny ira.we...@intel.com
 
 ---
  include/rdma/ib_verbs.h | 5 +
  1 file changed, 5 insertions(+)
 
 diff --git a/include/rdma/ib_verbs.h b/include/rdma/ib_verbs.h
 index 3ab4033..2614233 100644
 --- a/include/rdma/ib_verbs.h
 +++ b/include/rdma/ib_verbs.h
 @@ -128,6 +128,10 @@ enum ib_device_cap_flags {
   IB_DEVICE_ON_DEMAND_PAGING  = (131),
  };
  
 +enum ib_device_cap_flags2 {
 + IB_DEVICE_OPA_MAD_SUPPORT   = 1
 +};
 +
  enum ib_signature_prot_cap {
   IB_PROT_T10DIF_TYPE_1 = 1,
   IB_PROT_T10DIF_TYPE_2 = 1  1,
 @@ -210,6 +214,7 @@ struct ib_device_attr {
   int sig_prot_cap;
   int sig_guard_cap;
   struct ib_odp_caps  odp_caps;
 + u64 device_cap_flags2;
   u32 max_mad_size;
  };
  

Why is OPA support determined via a device capability flag ? What are
the tradeoffs for doing it this way versus the other choices that have
been used in the past for other RDMA technologies like RoCE, iWARP,
usNIC, … ?

-- Hal
--
To unsubscribe from this list: send the line unsubscribe linux-rdma in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: rdma_connect() and IBV_QPT_UC

2015-02-06 Thread Christopher Mitchell
Sean,

Thanks for the quick response. I've made the suggested changes, but
I'm afraid I am having the same problems. In fact, I see that a
previous thread (
http://www.spinics.net/lists/linux-rdma/msg07573.html ) follows
another user with the same problem. In fact, I finally found a message
(from you, actually!
http://www.spinics.net/lists/linux-rdma/msg07601.html ) saying that as
of 2011, librdmacm can't handle UC. Is this still the case?

Thanks,
Christopher

On Wed, Feb 4, 2015 at 9:19 PM, Hefty, Sean sean.he...@intel.com wrote:
 I have a fairly complex system that I've built over the last few years
 as part of my PhD that uses reliable connections for message-passing
 and RDMA. After reading a recent paper, I decided to compare the
 performance of message-passing over unreliable connections for the
 sake of completeness, but unfortunately, I've repeatedly run into
 obstacles trying to switch to using the UC mode. I even wrote a tiny
 client and server that simply opens a connection, sends a message, and
 sends a response, and when I switch from RC to UC, the rdma_accept()
 at the server always fails with EINVAL when trying to accept the
 client's rdma_connect(). I'm afraid documentation, source code, and
 experimentation have left me stymied. I have tried using RDMA_PS_IB
 and RDMA_PS_UDP instead of RDMA_PS_TCP in rdma_create_id() to no
 avail, I've experimented with qp_attr fields, and my MWE shows the
 same problems as the larger system. Any assistance woudl be greatly
 appreciated, and I'd be happy to provide more details about my setup
 of the event channel, queue pair, buffers, and so on if necessary.

 I believe you can get UC support by using the calls rdma_getaddrinfo and 
 rdma_create_ep, which allows you to specify the qp_type as IBV_QPT_UC.  For 
 the port space, you will need RDMA_PS_IB.  The TCP and UDP port spaces map to 
 QP types RC and UD, respectively.
--
To unsubscribe from this list: send the line unsubscribe linux-rdma in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[GIT PULL] please pull infiniband.git

2015-02-06 Thread Roland Dreier
Hi Linus,

Please pull from

git://git.kernel.org/pub/scm/linux/kernel/git/roland/infiniband.git 
tags/rdma-for-linus


One more last-second RDMA change for 3.19:
 - Yann realized that the previous revert of new userspace ABI did not
   go far enough, and we're still exposing a change that we don't want.
   Revert even closer to 3.18 interface to make sure we get things right
   in the long run.

Sorry for sending this at the very end of the release cycle, but we
didn't realize the scope of the required fix until just now.


Yann Droneaud (1):
  Revert IB/core: Add support for extended query device caps

 drivers/infiniband/core/uverbs.h |   1 -
 drivers/infiniband/core/uverbs_cmd.c | 137 +++
 drivers/infiniband/hw/mlx5/main.c|   2 -
 include/rdma/ib_verbs.h  |   5 +-
 include/uapi/rdma/ib_user_verbs.h|  27 ---
 5 files changed, 42 insertions(+), 130 deletions(-)
--
To unsubscribe from this list: send the line unsubscribe linux-rdma in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 2/2] iser-target: Remove duplicate function names

2015-02-06 Thread Nicholas A. Bellinger
On Fri, 2015-02-06 at 01:09 +0100, Rasmus Villemoes wrote:
 The macro isert_dbg already ensures that __func__ is part of the
 output, so there's no reason to duplicate the function name in the
 format string itself.
 
 Signed-off-by: Rasmus Villemoes li...@rasmusvillemoes.dk
 ---
  drivers/infiniband/ulp/isert/ib_isert.c | 7 +++
  1 file changed, 3 insertions(+), 4 deletions(-)
 
 diff --git a/drivers/infiniband/ulp/isert/ib_isert.c 
 b/drivers/infiniband/ulp/isert/ib_isert.c
 index dafb3c531f96..20097de9ac45 100644
 --- a/drivers/infiniband/ulp/isert/ib_isert.c
 +++ b/drivers/infiniband/ulp/isert/ib_isert.c
 @@ -949,7 +949,7 @@ isert_post_recv(struct isert_conn *isert_conn, u32 count)
   isert_err(ib_post_recv() failed with ret: %d\n, ret);
   isert_conn-post_recv_buf_count -= count;
   } else {
 - isert_dbg(isert_post_recv(): Posted %d RX buffers\n, count);
 + isert_dbg(Posted %d RX buffers\n, count);
   isert_conn-conn_rx_desc_head = rx_head;
   }
   return ret;
 @@ -1709,8 +1709,7 @@ isert_put_cmd(struct isert_cmd *isert_cmd, bool 
 comp_err)
* associated cmd-se_cmd needs to be released.
*/
   if (cmd-se_cmd.se_tfo != NULL) {
 - isert_dbg(Calling transport_generic_free_cmd from
 -   isert_put_cmd for 0x%02x\n,
 + isert_dbg(Calling transport_generic_free_cmd for 
 0x%02x\n,
cmd-iscsi_opcode);
   transport_generic_free_cmd(cmd-se_cmd, 0);
   break;
 @@ -3136,7 +3135,7 @@ accept_wait:
   spin_lock_bh(np-np_thread_lock);
   if (np-np_thread_state = ISCSI_NP_THREAD_RESET) {
   spin_unlock_bh(np-np_thread_lock);
 - isert_dbg(np_thread_state %d for isert_accept_np\n,
 + isert_dbg(np_thread_state %d\n,
np-np_thread_state);
   /**
* No point in stalling here when np_thread

Applied to target-pending/for-next.

Thanks Rasmus!

--nab

--
To unsubscribe from this list: send the line unsubscribe linux-rdma in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v4 00/19] IB/mad: Add support for Intel Omni-Path Architecture (OPA) MAD processing.

2015-02-06 Thread Hal Rosenstock
On 2/4/2015 6:29 PM, ira.we...@intel.com wrote:
 From: Ira Weiny ira.we...@intel.com
 
 The following patch series modifies the kernel MAD processing (ib_mad/ib_umad)
 and related interfaces to send and receive Intel Omni-Path Architecture MADs 
 on
 devices which support them.
 
 In addition to supporting some IBTA management classes, OPA devices use MADs
 with lengths up to 2K.  These jumbo MADs increase the performance of
 management traffic.
 
 To distinguish IBTA MADs from OPA MADs a new Base Version is introduced.  

With your recent changes, I don't think that statement above is strictly
true any longer. While OPA does use a different base version for it's
jumbo MADs, aren't OPA MADs distinguished from IBTA MADs by the new OPA
MAD device capability bit ?

 The
 new format shares the same common header with IBTA MADs which allows us to
 share most of the MAD processing code when dealing with the new Base Version.
 
 
 The patch series is broken into 3 main areas.
 
 1) Add the ability for devices to indicate MAD size.
modify the MAD code to use this MAD size
 
 2) Enhance the interface to the device agents to support larger and variable
length MADs.
 
 3) Add capability bit to indicate support for OPA MADs
 
 4) Add support for creating and processing OPA MADs
 
 
 Changes for V4:
 
   Rebased to latest Rolands for-next branch (3.19-rc4)
   Fixed compile issue in ehca driver found with 0-day build.
 
 
 Ira Weiny (19):
   IB/mad: Rename is_data_mad to is_rmpp_data_mad
   IB/core: Cache device attributes for use by upper level drivers
   IB/mad: Change validate_mad signature to take ib_mad_hdr rather than
 ib_mad
   IB/mad: Change ib_response_mad signature to take ib_mad_hdr rather
 than ib_mad
   IB/mad: Change cast in rcv_has_same_class
   IB/core: Add max_mad_size to ib_device_attr
   IB/mad: Convert ib_mad_private allocations from kmem_cache to kmalloc
   IB/mad: Add helper function for smi_handle_dr_smp_send
   IB/mad: Add helper function for smi_handle_dr_smp_recv
   IB/mad: Add helper function for smi_check_forward_dr_smp
   IB/mad: Add helper function for SMI processing
   IB/mad: Add MAD size parameters to process_mad
   IB/mad: Add base version parameter to ib_create_send_mad
   IB/core: Add IB_DEVICE_OPA_MAD_SUPPORT device cap flag
   IB/mad: Create jumbo_mad data structures
   IB/mad: Add Intel Omni-Path Architecture defines
   IB/mad: Implement support for Intel Omni-Path Architecture base
 version MADs in ib_create_send_mad
   IB/mad: Implement Intel Omni-Path Architecture SMP processing
   IB/mad: Implement Intel Omni-Path Architecture MAD processing
 
  drivers/infiniband/core/agent.c  |  26 +-
  drivers/infiniband/core/agent.h  |   3 +-
  drivers/infiniband/core/cm.c |   6 +-
  drivers/infiniband/core/device.c |   2 +
  drivers/infiniband/core/mad.c| 519 
 ++-
  drivers/infiniband/core/mad_priv.h   |   7 +-
  drivers/infiniband/core/mad_rmpp.c   | 144 
  drivers/infiniband/core/opa_smi.h|  78 
  drivers/infiniband/core/sa_query.c   |   3 +-
  drivers/infiniband/core/smi.c| 231 
  drivers/infiniband/core/smi.h|   6 +
  drivers/infiniband/core/sysfs.c  |   5 +-
  drivers/infiniband/core/user_mad.c   |  38 +-
  drivers/infiniband/hw/amso1100/c2_provider.c |   5 +-
  drivers/infiniband/hw/amso1100/c2_rnic.c |   1 +
  drivers/infiniband/hw/cxgb3/iwch_provider.c  |   6 +-
  drivers/infiniband/hw/cxgb4/provider.c   |   8 +-
  drivers/infiniband/hw/ehca/ehca_hca.c|   3 +
  drivers/infiniband/hw/ehca/ehca_iverbs.h |   4 +-
  drivers/infiniband/hw/ehca/ehca_sqp.c|   8 +-
  drivers/infiniband/hw/ipath/ipath_mad.c  |   8 +-
  drivers/infiniband/hw/ipath/ipath_verbs.c|   1 +
  drivers/infiniband/hw/ipath/ipath_verbs.h|   3 +-
  drivers/infiniband/hw/mlx4/mad.c |  12 +-
  drivers/infiniband/hw/mlx4/main.c|   1 +
  drivers/infiniband/hw/mlx4/mlx4_ib.h |   3 +-
  drivers/infiniband/hw/mlx5/mad.c |   8 +-
  drivers/infiniband/hw/mlx5/main.c|   1 +
  drivers/infiniband/hw/mlx5/mlx5_ib.h |   3 +-
  drivers/infiniband/hw/mthca/mthca_dev.h  |   4 +-
  drivers/infiniband/hw/mthca/mthca_mad.c  |  12 +-
  drivers/infiniband/hw/mthca/mthca_provider.c |   2 +
  drivers/infiniband/hw/nes/nes_verbs.c|   4 +-
  drivers/infiniband/hw/ocrdma/ocrdma_ah.c |   3 +-
  drivers/infiniband/hw/ocrdma/ocrdma_ah.h |   3 +-
  drivers/infiniband/hw/ocrdma/ocrdma_verbs.c  |   1 +
  drivers/infiniband/hw/qib/qib_iba7322.c  |   3 +-
  drivers/infiniband/hw/qib/qib_mad.c  |  11 +-
  drivers/infiniband/hw/qib/qib_verbs.c|   1 +
  drivers/infiniband/hw/qib/qib_verbs.h|   3 +-
  drivers/infiniband/hw/usnic/usnic_ib_verbs.c |   2 +
  

RE: rdma_connect() and IBV_QPT_UC

2015-02-06 Thread Hefty, Sean
 Thanks for the quick response. I've made the suggested changes, but
 I'm afraid I am having the same problems. In fact, I see that a
 previous thread (
 http://www.spinics.net/lists/linux-rdma/msg07573.html ) follows
 another user with the same problem. In fact, I finally found a message
 (from you, actually!
 http://www.spinics.net/lists/linux-rdma/msg07601.html ) saying that as
 of 2011, librdmacm can't handle UC. Is this still the case?

UC support has never been a priority, so it's not something that's tested.  I 
modified one of the example librdmacm programs to use UC, and it seemed to 
work.  At least it made a connection and transferred some data.  I did not 
verify that UC was actually being used.

A newer kernel may be needed, but I don't remember what patches are required or 
which version the changes went upstream.  Changes were never made specifically 
to support UC, but the changes to support XRC and native IB addressing should 
have made it possible.

Btw, is there any reason why you're wanting to run over UC?  It kind of 
combines the worst part of UD with the worst features of RC -- kind of the el 
Camino of protocols.

- Sean
N�r��yb�X��ǧv�^�)޺{.n�+{��ٚ�{ay�ʇڙ�,j��f���h���z��w���
���j:+v���w�j�mzZ+�ݢj��!�i

RE: [PATCH v1 1/5] IB/uverbs: ex_query_device: answer must not depend on request's comp_mask

2015-02-06 Thread Weiny, Ira
 
 On 05/02/2015 04:54, Weiny, Ira wrote:
 
  On Thu, Jan 29, 2015 at 09:50:38PM +0100, Yann Droneaud wrote:
 
  Anyway, I recognize that uverb way of abusing write() syscall is
  borderline (at best) regarding other Linux subsystems and Unix
  paradigm in general. But it's not enough to screw it more.
 
  Then we must return the correct output size explicitly in the struct.
 
  I was thinking this very same thing as I read through this thread.
 
  I too would like to avoid the use of comp_masks if at all possible.  The 
  query
 call seems to be a verb where the structure size is all you really need to 
 know
 the set of values returned.
 
  As Jason says, other calls may require the comp_mask where 0 is not
 sufficient to indicate missing.
 
 Would it be okay to return it in the ib_uverbs_cmd_hdr.out_words? That would
 further abuse the write() syscall by writing to the input buffer.

I don't think that is such a great idea.
 
 However, the only other alternative I see is to add it explicitly to every 
 uverb
 response struct.
 

I think this is the best solution.  There is a 32 bit reserved field in 
ib_uverbs_ex_query_device_resp.  Could we use all or part of that to be the 
size?

For other extended commands I'm not sure what to do.

Ira

--
To unsubscribe from this list: send the line unsubscribe linux-rdma in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


RE: [PATCHv2 infiniband-diags] ibtracert.c: Remove checking the port 0 state for base switch port 0

2015-02-06 Thread Weiny, Ira
 
 From: Dan Ben Yosef da...@mellanox.com
 
 The port 0 state check needed to be only for HCA/Routers and
 EnhancedPort0 switches.
 For BasePort0 switches, the PortState field, in PortInfo arrtibute, for port0 
 is
 undefined.
 
 Signed-off-by: Dan Ben Yosef da...@mellanox.com

Thanks applied,
Ira 

 ---
 Changes since v1:
 Changed is_route_inactive_port0 to is_port_inactive Moved description from
 above use of routine to above routine (is_port_inactive)
 
 diff --git a/src/ibtracert.c b/src/ibtracert.c index d32968b..9414618 100644
 --- a/src/ibtracert.c
 +++ b/src/ibtracert.c
 @@ -92,6 +92,7 @@ struct Switch {
   int mccap;
   int linearFDBtop;
   int fdb_base;
 + int enhsp0;
   int8_t fdb[64];
   char switchinfo[64];
  };
 @@ -114,6 +115,24 @@ struct Node {
  Node *nodesdist[MAXHOPS];
  uint64_t target_portguid;
 
 +/*
 + * is_port_inactive
 + * Checks whether or not the port state is other than active.
 + * The sw argument is only relevant when the port is on a
 + * switch; for HCAs and routers, this argument is ignored.
 + * Returns 1 when port is not active and 0 when active.
 + * Base switch port 0 is considered always active.
 + */
 +static int is_port_inactive(Node * node, Port * port, Switch * sw) {
 + int res = 0;
 + if (port-state != 4 
 + (node-type != IB_NODE_SWITCH ||
 +  (node-type == IB_NODE_SWITCH  sw-enhsp0)))
 + res = 1;
 + return res;
 +}
 +
  static int get_node(Node * node, Port * port, ib_portid_t * portid)  {
   void *pi = port-portinfo, *ni = node-nodeinfo, *nd = node-nodedesc;
 @@ -164,6 +183,7 @@ static int switch_lookup(Switch * sw, ib_portid_t *
 portid, int lid)
 
   mad_decode_field(si, IB_SW_LINEAR_FDB_CAP_F, sw-linearcap);
   mad_decode_field(si, IB_SW_LINEAR_FDB_TOP_F, sw-
 linearFDBtop);
 + mad_decode_field(si, IB_SW_ENHANCED_PORT0_F, sw-enhsp0);
 
   if (lid = sw-linearcap  lid  sw-linearFDBtop)
   return -1;
 @@ -248,7 +268,7 @@ static int find_route(ib_portid_t * from, ib_portid_t *
 to, int dump)
   Port *port, fromport, toport, nextport;
   Switch sw;
   int maxhops = MAXHOPS;
 - int portnum, outport;
 + int portnum, outport = 255, next_sw_outport = 255;
 
   memset(fromnode,0,sizeof(Node));
   memset(tonode,0,sizeof(Node));
 @@ -274,20 +294,25 @@ static int find_route(ib_portid_t * from, ib_portid_t *
 to, int dump)
   portnum = port-portnum;
 
   dump_endnode(dump, From, node, port);
 + if (node-type == IB_NODE_SWITCH) {
 + next_sw_outport = switch_lookup(sw, from, to-lid);
 + if (next_sw_outport  0 || next_sw_outport  node-numports)
 {
 + /* needed to print the port in badtbl */
 + outport = next_sw_outport;
 + goto badtbl;
 + }
 + }
 
   while (maxhops--) {
 - if (port-state != 4)
 + if (is_port_inactive(node, port, sw))
   goto badport;
 
   if (sameport(port, toport))
   break;  /* found */
 
 - outport = portnum;
   if (node-type == IB_NODE_SWITCH) {
   DEBUG(switch node);
 - if ((outport = switch_lookup(sw, from, to-lid))  0 ||
 - outport  node-numports)
 - goto badtbl;
 + outport = next_sw_outport;
 
   if (extend_dpath(from-drpath, outport)  0)
   goto badpath;
 @@ -307,6 +332,7 @@ static int find_route(ib_portid_t * from, ib_portid_t *
 to, int dump)
  (node-type == IB_NODE_ROUTER)) {
   int ca_src = 0;
 
 + outport = portnum;
   DEBUG(ca or router node);
   if (!sameport(port, fromport)) {
   IBWARN
 @@ -335,8 +361,19 @@ static int find_route(ib_portid_t * from, ib_portid_t *
 to, int dump)
   nextport.portnum =
   from-drpath.p[from-drpath.cnt + 1];
   }
 + /* only if the next node is a switch, get switch info */
 + if (nextnode.type == IB_NODE_SWITCH) {
 + next_sw_outport = switch_lookup(sw, from, to-lid);
 + if (next_sw_outport  0 ||
 + next_sw_outport  nextnode.numports) {
 + /* needed to print the port in badtbl */
 + outport = next_sw_outport;
 + goto badtbl;
 + }
 + }
 +
   port = nextport;
 - if (port-state != 4)
 + if (is_port_inactive(nextnode, port, sw))
   goto badoutport;
   node = nextnode;
   portnum = port-portnum;
--
To unsubscribe from this list: send the line 

RE: [PATCH infiniband-diags] Add new configure flag to enable/disable the rdma-ndd build

2015-02-06 Thread Weiny, Ira
 
 From: Dan Ben Yosef da...@mellanox.com
 
 Add new flag --enable-rdma-ndd (default=yes)
 
 Signed-off-by: Dan Ben Yosef da...@mellanox.com

Thanks applied,
Ira 

 ---
 diff --git a/Makefile.am b/Makefile.am
 index 4e08c2b..63c4b48 100644
 --- a/Makefile.am
 +++ b/Makefile.am
 @@ -15,9 +15,11 @@ sbin_PROGRAMS = src/ibaddr src/ibnetdiscover
 src/ibping src/ibportstate \
   src/perfquery src/sminfo src/smpdump src/smpquery \
   src/saquery src/vendstat src/iblinkinfo \
   src/ibqueryerrors src/ibcacheedit src/ibccquery \
 - src/ibccconfig \
 - src/dump_fts \
 - src/rdma-ndd
 + src/ibccconfig src/dump_fts
 +
 +if ENABLE_RDMA_NDD
 +sbin_PROGRAMS += src/rdma-ndd
 +endif
 
  if ENABLE_TEST_UTILS
  sbin_PROGRAMS += src/ibsendtrap src/mcm_rereg_test @@ -71,10 +73,13
 @@ man_MANS = doc/man/ibaddr.8 \
   doc/man/smpquery.8 \
   doc/man/vendstat.8 \
   doc/man/infiniband-diags.8 \
 - doc/man/rdma-ndd.8 \
   man/dump_lfts.8 \
   man/dump_mfts.8
 
 +if ENABLE_RDMA_NDD
 +man_MANS += doc/man/rdma-ndd.8
 +endif
 +
  # define this for the dist target
  compat_man_pages = man/ibdiscover.8 man/ibcheckerrors.8
 man/ibcheckerrs.8 \
   man/ibchecknet.8 man/ibchecknode.8 man/ibcheckport.8 \
 @@ -161,6 +166,8 @@ install-data-hook:
   $(top_srcdir)/config/install-sh -c -m 444
 $(top_srcdir)/etc/error_thresholds $(DESTDIR)/$(sysconfdir)/infiniband-diags
   $(top_srcdir)/config/install-sh -c -m 400 $(top_srcdir)/etc/ibdiag.conf
 $(DESTDIR)/$(sysconfdir)/infiniband-diags
 
 +if ENABLE_RDMA_NDD
  install-exec-hook:
   $(top_srcdir)/config/install-sh -m 755 -d
 $(DESTDIR)/$(sysconfdir)/init.d
   $(top_srcdir)/config/install-sh -m 755 $(top_srcdir)/etc/rdma-ndd.init
 $(DESTDIR)/$(sysconfdir)/init.d/rdma-ndd
 +endif
 diff --git a/configure.ac b/configure.ac index ed1b834..11f47f7 100644
 --- a/configure.ac
 +++ b/configure.ac
 @@ -180,6 +180,18 @@ fi
  AC_SUBST(ibnetdisc_api_version)
  dnl End libibnetdisc stuff
 
 +dnl with or with rdma-ndd
 +AC_MSG_CHECKING(for --enable-rdma-ndd)
 +AC_ARG_ENABLE(rdma-ndd,
 +[  --enable-rdma-ndd build rdma-ndd (default=yes)], [case
 +${enableval} in
 +  yes) rdmandd=yes ;;
 +  no)  rdmandd=no ;;
 +  *) AC_MSG_ERROR(bad value ${enableval} for --enable-rdma-ndd) ;;
 +esac],[rdmandd=yes])
 +AM_CONDITIONAL(ENABLE_RDMA_NDD, test x$rdmandd = xyes)
 +AC_MSG_RESULT(${rdmandd=no})
 +
  dnl configures for rdma-ndd startup script  default_rdma_service=openibd
 AC_ARG_WITH([rdma_service], @@ -198,9 +210,12 @@ default_start=null
  AC_SUBST(DEFAULT_START, $default_start)  AC_SUBST(DEFAULT_STOP,
 $default_stop)
 
 -AC_CHECK_HEADER(libudev.h, with_udev=yes, with_udev=no) -
 AC_CHECK_LIB(udev, udev_monitor_ref, [], AC_MSG_ERROR(libudev is
 required for rdma-ndd...))
 -AC_CHECK_FUNCS_ONCE(udev_get_sys_path)
 +if test x$rdmandd = xyes; then
 +AC_CHECK_HEADER(libudev.h, with_udev=yes, with_udev=no)
 +AC_CHECK_LIB(udev, udev_monitor_ref, [], AC_MSG_ERROR(libudev is
 required for rdma-ndd...))
 +AC_CONFIG_FILES([doc/man/rdma-ndd.8 etc/rdma-ndd.init])
 +AC_CHECK_FUNCS_ONCE(udev_get_sys_path)
 +fi
 
  dnl Generate doc/man/*.in files if possible  DOC_DATE=`date +%Y-%m-%d`
 @@ -275,8 +290,6 @@ AC_CONFIG_FILES([\
   doc/man/smpquery.8 \
   doc/man/vendstat.8 \
   doc/man/infiniband-diags.8 \
 - doc/man/rdma-ndd.8 \
 - etc/rdma-ndd.init \
   libibnetdisc/Makefile \
  ])
  AC_OUTPUT
--
To unsubscribe from this list: send the line unsubscribe linux-rdma in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


RE: [PATCH infiniband-diags] Align infiniband-diags MLNX device IDs with OpenSM

2015-02-06 Thread Weiny, Ira
 
 
 Same device IDs as in opensm/osm_subnet.c:is_mlnx_ext_port_info_supported
 
 Switch-IB is device ID 0xcb20 rather than 0xcb84
 
 Signed-off-by: Hal Rosenstock h...@mellanox.com

Thanks applied,
Ira

 ---
 diff --git a/libibnetdisc/src/ibnetdisc.c b/libibnetdisc/src/ibnetdisc.c index
 f3c6000..e346905 100644
 --- a/libibnetdisc/src/ibnetdisc.c
 +++ b/libibnetdisc/src/ibnetdisc.c
 @@ -203,7 +203,7 @@ static int is_mlnx_ext_port_info_supported(ibnd_port_t
 * port)  {
   uint16_t devid = (uint16_t) mad_get_field(port-node-info, 0,
 IB_NODE_DEVID_F);
 
 - if (devid == 0xc738 || devid == 0xcb84)
 + if ((devid = 0xc738  devid = 0xc73b) || devid == 0xcb20)
   return 1;
   if (devid = 0x1003  devid = 0x1016)
   return 1;
 diff --git a/src/ibdiag_common.c b/src/ibdiag_common.c index
 666edbc..e09623d 100644
 --- a/src/ibdiag_common.c
 +++ b/src/ibdiag_common.c
 @@ -530,7 +530,7 @@ int is_port_info_extended_supported(ib_portid_t *
 dest, int port,  int is_mlnx_ext_port_info_supported(uint32_t devid)  {
   if (ibd_ibnetdisc_flags  IBND_CONFIG_MLX_EPI) {
 - if (devid == 0xc738 || devid == 0xcb84)
 + if ((devid = 0xc738  devid = 0xc73b) || devid == 0xcb20)
   return 1;
   if (devid = 0x1003  devid = 0x1016)
   return 1;
 diff --git a/src/vendstat.c b/src/vendstat.c index 7fc4a11..11ee73e 100644
 --- a/src/vendstat.c
 +++ b/src/vendstat.c
 @@ -144,8 +144,8 @@ typedef struct {
 
  static uint16_t ext_fw_info_device[][2] = {
   {0x0245, 0x0245},   /* Switch-X */
 - {0xc738, 0xc738},   /* Switch-X */
 - {0xcb84, 0xcb84},   /* Switch-IB */
 + {0xc738, 0xc73b},   /* Switch-X */
 + {0xcb20, 0xcb20},   /* Switch-IB */
   {0x01b3, 0x01b3},   /* IS-4 */
   {0x1003, 0x1016},   /* Connect-X */
   {0x, 0x}};
--
To unsubscribe from this list: send the line unsubscribe linux-rdma in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH] MAINTAINERS: Update SRP initiator entry

2015-02-06 Thread Bart Van Assche
We have been asked to use our company e-mail address for open
source contributions. Hence this change from a personal e-mail
address into a company e-mail address.

Signed-off-by: Bart Van Assche bart.vanass...@sandisk.com
Cc: Bart Van Assche bvanass...@acm.org
---
 MAINTAINERS | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index aaa039d..b9baddd 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -8440,7 +8440,7 @@ S:Maintained
 F: drivers/scsi/sr*
 
 SCSI RDMA PROTOCOL (SRP) INITIATOR
-M: Bart Van Assche bvanass...@acm.org
+M: Bart Van Assche bart.vanass...@sandisk.com
 L: linux-rdma@vger.kernel.org
 S: Supported
 W: http://www.openfabrics.org
-- 
2.1.4

--
To unsubscribe from this list: send the line unsubscribe linux-rdma in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] Revert IB/core: Add support for extended query device caps

2015-02-06 Thread Yann Droneaud
Hi,

Le vendredi 06 février 2015 à 00:55 -0800, Roland Dreier a écrit :
 Thanks for noticing this at the last moment.
 

I should have noticed this earlier, but, as small is beautiful,
I was impressed by the patch from Haggai and thought it would better 
than an ugly revert ... Foolish I was.

 I will send this to Linus on Friday.

Thanks a lot. And sorry about this epic adventure in ABI land :/

Regards.

-- 
Yann Droneaud
OPTEYA



--
To unsubscribe from this list: send the line unsubscribe linux-rdma in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH RE-RESEND V2 for-next 4/5] IB/core: Make sure that the PSN does not overflow

2015-02-06 Thread Or Gerlitz
On Fri, Feb 6, 2015 at 12:27 AM, Weiny, Ira ira.we...@intel.com wrote:
 Subject: [PATCH RE-RESEND V2 for-next 4/5] IB/core: Make sure that the PSN
 does not overflow

 Is there a particular bug  which this fixes?

Not something that I am aware too (but we can take a look @ our
regression data-base - Majd, please do), more of maintenance fix.
--
To unsubscribe from this list: send the line unsubscribe linux-rdma in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html