[ofa-general] Re: __always_inline macro usage

[Jack Morgenstein]

On Monday 22 October 2007 23:42, Roland Dreier wrote:
 Something is fishy with your compilation process.  __always_inline
 should never be visible to gcc; it is a macro defined in linux/compiler.h.
 

Might this be a gcc installation problem?

I have the following file (foobar.c):

==
static __always_inline int foo(int i) {return (i+1); }
int main(void) { return foo(5); }
==

If I just do:  gcc foobar.c,
I get the following output:
foobar.c:1: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ 
before ‘int’

If I modify the file to:
==
static __attribute__((always_inline)) int foo(int i) {return (i+1); }
int main(void) { return foo(5); }
==

and do gcc foobar.c,
the compilation succeeds.

I'm using gcc (GCC) 4.1.0 (SUSE Linux), on SLES 10.

-- Jack
___
general mailing list
general@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

Re: [ofa-general] Re: __always_inline macro usage

[Gleb Natapov]

On Tue, Oct 23, 2007 at 09:22:09AM +0200, Jack Morgenstein wrote:
 On Monday 22 October 2007 23:42, Roland Dreier wrote:
  Something is fishy with your compilation process.  __always_inline
  should never be visible to gcc; it is a macro defined in linux/compiler.h.
  
 
 Might this be a gcc installation problem?
 
 I have the following file (foobar.c):
 
 ==
 static __always_inline int foo(int i) {return (i+1); }
 int main(void) { return foo(5); }
 ==
And where is #include linux/compiler.h here?

 
 If I just do:  gcc foobar.c,
 I get the following output:
   foobar.c:1: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ 
 before ‘int’
 
 If I modify the file to:
 ==
 static __attribute__((always_inline)) int foo(int i) {return (i+1); }
 int main(void) { return foo(5); }
 ==
 
 and do gcc foobar.c,
 the compilation succeeds.
 
 I'm using gcc (GCC) 4.1.0 (SUSE Linux), on SLES 10.
 
 -- Jack
 ___
 general mailing list
 general@lists.openfabrics.org
 http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general
 
 To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

--
Gleb.
___
general mailing list
general@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

[ofa-general] ibutils.src.rpm do not pass compile on PPC64 -SLES 10 SP1

[Moshe Kazir]

The attached patch enable compile of ibutils with no error on SLES 10
SP1 PPC64 JS21
 
Idid not test it on other environments.
 
When I tried to rpmbuild the  new created ibutils...src.rpm 
 
I face a new problem ...
 
make[1]: Leaving directory `/usr/src/packages/BUILD/ibutils-1.2'
+ install -d
/var/tmp/ibutils-1.2-0.4.ofed20070930-root-root/etc/profile.d
+ cat
+ cat
+ touch ibutils-files
+ install -d
/var/tmp/ibutils-1.2-0.4.ofed20070930-root-root/etc/ld.so.conf.d
+ echo /usr/lib64
+ case /usr in
+ /usr/lib/rpm/brp-lib64-linux
[EMAIL PROTECTED]: if you find problems with this script, drop me a note
  RPATH   /usr/lib/gcc/powerpc64-suse-linux/4.1.2/64:/usr/lib
/var/tmp/ibutils-1.2-0.4.ofed20070930-root-root/usr/lib64/libibdm.so:
rpath to 32bit lib
error: Bad exit status from /var/tmp/rpm-tmp.12275 (%install)


 

I'm starting to dig it now.

 
Patch explanation:
 
In the configure files you'll find the line $CC -print-search-dirs
.
 
On a non PPC64 that's the right way to find the gcc  g++ library path.
 
But it is not good for PPC64 !
 
The defualt for PPC64 is ELF 32 bit, therefore if one 
When you search libraries for ELF 64 objects the right command is - 
 
$CC $CFLAGS $CPPFLAGS $LDFLAGS -print-search-dirs .
 
Also the patch include spell mistake that caused link errors - somewere
CFLAGS=save_cfalgs is fixed tobee CFLAGS=save_cflags
 
 

Moshe

 
 

Can someone help me to fix this problem in the right way, 

I.e. changing the autoconf input files and not the configure /
aclocal.m4 files

 

Moshe



Moshe Katzir   |  +972-9971-8639 (o)   |   +972-52-860-6042  (m)

 

Voltaire - The Grid Backbone

 

 www.voltaire.com http://www.voltaire.com/ 

mailto:[EMAIL PROTECTED] 

  

 


ibutils_sles10_sp1_ppc64.patch
Description: ibutils_sles10_sp1_ppc64.patch
___
general mailing list
general@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

Re: [ofa-general] Re: __always_inline macro usage

[Jack Morgenstein]

On Tuesday 23 October 2007 09:23, Gleb Natapov wrote:
 And where is #include linux/compiler.h here?
 
Point taken.  However, I checked on Red Hat Enterprise Linux 4 (update 5)
distributions.  the macro __always_inline is not present there (see below).
They use inline or __inline__ or __inline instead.

How do we avoid backports for gcc??

/* Never include this file directly.  Include linux/compiler.h instead.  */

/* These definitions are for GCC v3.x.  */
#include linux/compiler-gcc.h

#if __GNUC_MINOR__ = 1   __GNUC_MINOR__  4
# define inline __inline__ __attribute__((always_inline))
# define __inline__ __inline__ __attribute__((always_inline))
# define __inline   __inline__ __attribute__((always_inline))
#endif

#if __GNUC_MINOR__  0
# define __deprecated   __attribute__((deprecated))
#endif

#if __GNUC_MINOR__ = 3
# define __attribute_used__ __attribute__((__used__))
#else
# define __attribute_used__ __attribute__((__unused__))
#endif

#define __attribute_pure__  __attribute__((pure))
#define __attribute_const__ __attribute__((__const__))

#if __GNUC_MINOR__ = 1
#define  noinline __attribute__((noinline))
#endif
#if __GNUC_MINOR__ = 4
#define __must_check __attribute__((warn_unused_result))
#endif

#if __GNUC_MINOR__ = 5
#define __compiler_offsetof(a,b) __builtin_offsetof(a,b)
#endif
~


___
general mailing list
general@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

Re: [ofa-general] Re: __always_inline macro usage

[Jack Morgenstein]

On Tuesday 23 October 2007 10:28, Jack Morgenstein wrote:
 On Tuesday 23 October 2007 09:23, Gleb Natapov wrote:
  And where is #include linux/compiler.h here?
  
 Point taken.  However, I checked on Red Hat Enterprise Linux 4 (update 5)
 distributions.  the macro __always_inline is not present there (see below).
 They use inline or __inline__ or __inline instead.
 
Correction.

In Kernel space, the __always_inline macro is present (in file 
/lib/modules/kernel/source/linux/compiler.h.

However, in user space, the file used is: /usr/include/linux/compiler.h:
#ifndef __LINUX_COMPILER_H
#define __LINUX_COMPILER_H

#define likely(x)   __builtin_expect((x),1)
#define unlikely(x) __builtin_expect((x),0)

#endif /* __LINUX_COMPILER_H */

The __always_inline macro is not defined for userspace in RHEL4.

Any ideas (other than just including a macro ourselves:
 #ifndef __always_inline
 #define __always_inline inline
 #endif
)?

- Jack
___
general mailing list
general@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

Re: [ofa-general] Re: __always_inline macro usage

[Gleb Natapov]

On Tue, Oct 23, 2007 at 10:43:16AM +0200, Jack Morgenstein wrote:
 On Tuesday 23 October 2007 10:28, Jack Morgenstein wrote:
  On Tuesday 23 October 2007 09:23, Gleb Natapov wrote:
   And where is #include linux/compiler.h here?
   
  Point taken.  However, I checked on Red Hat Enterprise Linux 4 (update 5)
  distributions.  the macro __always_inline is not present there (see 
  below).
  They use inline or __inline__ or __inline instead.
  
 Correction.
 
 In Kernel space, the __always_inline macro is present (in file 
 /lib/modules/kernel/source/linux/compiler.h.
 
 However, in user space, the file used is: /usr/include/linux/compiler.h:
 #ifndef __LINUX_COMPILER_H
 #define __LINUX_COMPILER_H
 
 #define likely(x)   __builtin_expect((x),1)
 #define unlikely(x) __builtin_expect((x),0)
 
 #endif /* __LINUX_COMPILER_H */
 
 The __always_inline macro is not defined for userspace in RHEL4.
I am not sure those macros (and header) are meant to be used by userspace.

 
 Any ideas (other than just including a macro ourselves:
  #ifndef __always_inline
  #define __always_inline inline
  #endif
 )?
 
 - Jack

--
Gleb.
___
general mailing list
general@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

Re: [ofa-general] Re: __always_inline macro usage

[Jack Morgenstein]

On Tuesday 23 October 2007 10:40, Gleb Natapov wrote:
  The __always_inline macro is not defined for userspace in RHEL4.
 I am not sure those macros (and header) are meant to be used by userspace.
 
The macro is currently being used in libmlx4 (src/qp.c).  That's what started
the thread.

- Jack
___
general mailing list
general@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

[ofa-general] Re: [PATCH V2] osm: QoS - adding CPI:CapabilityMask2 and turning on QOS_SUPPORTED bit

[Yevgeny Kliteynik]

Sasha Khapyorsky wrote:

On 00:13 Thu 18 Oct , Sasha Khapyorsky wrote:

diff --git a/opensm/include/iba/ib_types.h b/opensm/include/iba/ib_types.h
index 0969755..3685007 100644
--- a/opensm/include/iba/ib_types.h
+++ b/opensm/include/iba/ib_types.h
@@ -3247,8 +3247,7 @@ typedef struct _ib_class_port_info {
uint8_t base_ver;
uint8_t class_ver;
ib_net16_t cap_mask;
-   uint8_t reserved[3];
-   uint8_t resp_time_val;
+   ib_net32_t cap_mask2_resp_time;


This will break ibutils. We are in OFED already, so I think the patch
for ibutils should be committed/pushed at same time.


Patch for ibutils is ready and waiting for the opensm patch to be applied.

-- Yevgeny


Sasha



___
general mailing list
general@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

[ofa-general] [PATCH v3] osm: QoS - adding CPI:CapabilityMask2 and turning on QOS_SUPPORTED bit

[Yevgeny Kliteynik]

Adding ClassPortInfo:CapabilityMask2 field and turning
on OSM QoS capability bit (OSM_CAP2_IS_QOS_SUPPORTED).

Signed-off-by: Yevgeny Kliteynik [EMAIL PROTECTED]
---
 infiniband-diags/src/saquery.c |6 +-
 opensm/include/iba/ib_types.h  |  137 +++-
 opensm/include/opensm/osm_base.h   |   12 +++
 opensm/opensm/osm_sa_class_port_info.c |5 +-
 opensm/osmtest/osmtest.c   |   13 +++-
 5 files changed, 163 insertions(+), 10 deletions(-)

diff --git a/infiniband-diags/src/saquery.c b/infiniband-diags/src/saquery.c
index a9a8da4..e17ec5a 100644
--- a/infiniband-diags/src/saquery.c
+++ b/infiniband-diags/src/saquery.c
@@ -262,7 +262,8 @@ print_class_port_info(ib_class_port_info_t *class_port_info)
   \t\tBase version.%d\n
   \t\tClass version%d\n
   \t\tCapability mask..0x%04X\n
-  \t\tResponse time value..0x%08X\n
+  \t\tCapability mask 20x%08X\n
+  \t\tResponse time value..0x%02X\n
   \t\tRedirect GID.0x%s\n
   \t\tRedirect TC/SL/FL0x%08X\n
   \t\tRedirect LID.0x%04X\n
@@ -279,7 +280,8 @@ print_class_port_info(ib_class_port_info_t *class_port_info)
   class_port_info-base_ver,
   class_port_info-class_ver,
   cl_ntoh16(class_port_info-cap_mask),
-  class_port_info-resp_time_val,
+  ib_class_cap_mask2(class_port_info),
+  ib_class_resp_time_val(class_port_info),
   sprint_gid((class_port_info-redir_gid), gid_str, GID_STR_LEN),
   cl_ntoh32(class_port_info-redir_tc_sl_fl),
   cl_ntoh16(class_port_info-redir_lid),
diff --git a/opensm/include/iba/ib_types.h b/opensm/include/iba/ib_types.h
index ce4bfb3..d904d9c 100644
--- a/opensm/include/iba/ib_types.h
+++ b/opensm/include/iba/ib_types.h
@@ -3249,8 +3249,7 @@ typedef struct _ib_class_port_info {
uint8_t base_ver;
uint8_t class_ver;
ib_net16_t cap_mask;
-   uint8_t reserved[3];
-   uint8_t resp_time_val;
+   ib_net32_t cap_mask2_resp_time;
ib_gid_t redir_gid;
ib_net32_t redir_tc_sl_fl;
ib_net16_t redir_lid;
@@ -3277,8 +3276,9 @@ typedef struct _ib_class_port_info {
 *  cap_mask
 *  Supported capabilities of this management class.
 *
-*  resp_time_value
-*  Maximum expected response time.
+*  cap_mask2_resp_time
+*  Maximum expected response time and additional
+*  supported capabilities of this management class.
 *
 *  redr_gid
 *  GID to use for redirection, or zero
@@ -3324,6 +3324,135 @@ typedef struct _ib_class_port_info {
 *
 */

+/f* IBA Base: Types/ib_class_set_resp_time_val
+* NAME
+*  ib_class_set_resp_time_val
+*
+* DESCRIPTION
+*  Set maximum expected response time.
+*
+* SYNOPSIS
+*/
+static inline void OSM_API
+ib_class_set_resp_time_val(IN ib_class_port_info_t * const p_cpi,
+  IN const uint8_t val)
+{
+   p_cpi-cap_mask2_resp_time =
+   (p_cpi-cap_mask2_resp_time  CL_HTON32(~IB_CLASS_RESP_TIME_MASK)) |
+   cl_hton32(val  IB_CLASS_RESP_TIME_MASK);
+}
+
+/*
+* PARAMETERS
+*  p_cpi
+*  [in] Pointer to the class port info object.
+*
+*  val
+*  [in] Response time value to set.
+*
+* RETURN VALUES
+*  None
+*
+* NOTES
+*
+* SEE ALSO
+*  ib_class_port_info_t
+*/
+
+/f* IBA Base: Types/ib_class_resp_time_val
+* NAME
+*  ib_class_resp_time_val
+*
+* DESCRIPTION
+*  Get response time value.
+*
+* SYNOPSIS
+*/
+static inline uint8_t OSM_API
+ib_class_resp_time_val(IN ib_class_port_info_t * const p_cpi)
+{
+   return (uint8_t)(cl_ntoh32(p_cpi-cap_mask2_resp_time) 
+IB_CLASS_RESP_TIME_MASK);
+}
+
+/*
+* PARAMETERS
+*  p_cpi
+*  [in] Pointer to the class port info object.
+*
+* RETURN VALUES
+*  Response time value.
+*
+* NOTES
+*
+* SEE ALSO
+*  ib_class_port_info_t
+*/
+
+/f* IBA Base: Types/ib_class_set_cap_mask2
+* NAME
+*  ib_class_set_cap_mask2
+*
+* DESCRIPTION
+*  Set ClassPortInfo:CapabilityMask2.
+*
+* SYNOPSIS
+*/
+static inline void OSM_API
+ib_class_set_cap_mask2(IN ib_class_port_info_t * const p_cpi,
+  IN const uint32_t cap_mask2)
+{
+   p_cpi-cap_mask2_resp_time = (p_cpi-cap_mask2_resp_time 
+   CL_HTON32(IB_CLASS_RESP_TIME_MASK)) |
+   cl_hton32(cap_mask2  5);
+}
+
+/*
+* PARAMETERS
+*  p_cpi
+*  [in] Pointer to the class port info object.
+*
+*  cap_mask2
+*  [in] CapabilityMask2 value to set.
+*
+* RETURN VALUES
+*  None
+*
+* NOTES
+*
+* SEE ALSO
+*  ib_class_port_info_t
+*/
+
+/f* IBA Base: Types/ib_class_cap_mask2
+* NAME
+*  ib_class_cap_mask2
+*
+* 

[ofa-general] OFED version macro

[Isaac Huang]

Hi,

I'm looking for something similar to LINUX_VERSION_CODE so that my
code can build against both OFED 1.1 and 1.2.x, since there's been
some API changes. But grepping through the headers didn't reveal
anything close to it. In particular, ib_create_cq prototype has
changed to take an extra parameter, how can I detect this at
preprocessing time?

Also, is interoperability between OFED 1.1 and 1.2.x supported?

Thanks,
Isaac
___
general mailing list
general@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

[ofa-general] ofa_1_3_kernel 20071023-0200 daily build status

[Vladimir Sokolovsky (Mellanox)]

This email was generated automatically, please do not reply


git_url: git://git.openfabrics.org/ofed_1_3/linux-2.6.git
git_branch: ofed_kernel

Common build parameters:   --with-ipoib-mod --with-sdp-mod --with-srp-mod 
--with-user_mad-mod --with-user_access-mod --with-mthca-mod --with-mlx4-mod 
--with-core-mod --with-addr_trans-mod  --with-rds-mod --with-cxgb3-mod 
--with-nes-mod

Passed:
Passed on i686 with 2.6.15-23-server
Passed on i686 with linux-2.6.21.1
Passed on i686 with linux-2.6.22
Passed on i686 with linux-2.6.18
Passed on i686 with linux-2.6.17
Passed on i686 with linux-2.6.19
Passed on i686 with linux-2.6.16
Passed on i686 with linux-2.6.13
Passed on i686 with linux-2.6.12
Passed on i686 with linux-2.6.15
Passed on i686 with linux-2.6.14
Passed on x86_64 with linux-2.6.20
Passed on x86_64 with linux-2.6.18
Passed on x86_64 with linux-2.6.16
Passed on x86_64 with linux-2.6.19
Passed on ia64 with linux-2.6.18
Passed on x86_64 with linux-2.6.17
Passed on powerpc with linux-2.6.15
Passed on ppc64 with linux-2.6.16
Passed on ppc64 with linux-2.6.17
Passed on ia64 with linux-2.6.19
Passed on ia64 with linux-2.6.15
Passed on ia64 with linux-2.6.12
Passed on powerpc with linux-2.6.13
Passed on x86_64 with linux-2.6.22
Passed on powerpc with linux-2.6.14
Passed on ia64 with linux-2.6.16
Passed on ia64 with linux-2.6.17
Passed on ia64 with linux-2.6.13
Passed on ppc64 with linux-2.6.12
Passed on x86_64 with linux-2.6.12
Passed on x86_64 with linux-2.6.16.43-0.3-smp
Passed on powerpc with linux-2.6.12
Passed on ppc64 with linux-2.6.19
Passed on ppc64 with linux-2.6.18
Passed on ia64 with linux-2.6.14
Passed on ppc64 with linux-2.6.14
Passed on x86_64 with linux-2.6.13
Passed on ia64 with linux-2.6.23
Passed on ppc64 with linux-2.6.13
Passed on x86_64 with linux-2.6.21.1
Passed on ppc64 with linux-2.6.15
Passed on x86_64 with linux-2.6.15
Passed on x86_64 with linux-2.6.14
Passed on ia64 with linux-2.6.21.1
Passed on ia64 with linux-2.6.22
Passed on x86_64 with linux-2.6.9-42.ELsmp
Passed on x86_64 with linux-2.6.9-22.ELsmp
Passed on ia64 with linux-2.6.16.21-0.8-default
Passed on x86_64 with linux-2.6.16.21-0.8-smp
Passed on x86_64 with linux-2.6.9-55.ELsmp
Passed on x86_64 with linux-2.6.18-1.2798.fc6
Passed on x86_64 with linux-2.6.9-34.ELsmp
Passed on x86_64 with linux-2.6.18-8.el5
Passed on ppc64 with linux-2.6.18-8.el5

Failed:
___
general mailing list
general@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

Re: [ofa-general] Re: __always_inline macro usage

[Gleb Natapov]

On Tue, Oct 23, 2007 at 10:58:26AM +0200, Jack Morgenstein wrote:
 On Tuesday 23 October 2007 10:40, Gleb Natapov wrote:
   The __always_inline macro is not defined for userspace in RHEL4.
  I am not sure those macros (and header) are meant to be used by userspace.
  
 The macro is currently being used in libmlx4 (src/qp.c).  That's what started
 the thread.
 
I see. The question is back to Roland then :)

--
Gleb.
___
general mailing list
general@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

[ofa-general] [PATCH] libibverbs/examples: add command line parameter for SL

[Dotan Barak]

Added command line parameter to support changing the SL of the QP/AH.
(This is being used mainly in order to check the QoS feature)

Signed-off-by: Dotan Barak [EMAIL PROTECTED]

---

diff --git a/examples/rc_pingpong.c b/examples/rc_pingpong.c
index 258eb8f..4a90498 100644
--- a/examples/rc_pingpong.c
+++ b/examples/rc_pingpong.c
@@ -76,7 +76,8 @@ struct pingpong_dest {
 };
 
 static int pp_connect_ctx(struct pingpong_context *ctx, int port, int my_psn,
- enum ibv_mtu mtu, struct pingpong_dest *dest)
+ enum ibv_mtu mtu, int sl,
+ struct pingpong_dest *dest)
 {
struct ibv_qp_attr attr = {
.qp_state   = IBV_QPS_RTR,
@@ -88,7 +89,7 @@ static int pp_connect_ctx(struct pingpong_context *ctx, int 
port, int my_psn,
.ah_attr= {
.is_global  = 0,
.dlid   = dest-lid,
-   .sl = 0,
+   .sl = sl,
.src_path_bits  = 0,
.port_num   = port
}
@@ -192,7 +193,8 @@ out:
 }
 
 static struct pingpong_dest *pp_server_exch_dest(struct pingpong_context *ctx,
-int ib_port, enum ibv_mtu mtu, 
int port,
+int ib_port, enum ibv_mtu mtu,
+int port, int sl,
 const struct pingpong_dest 
*my_dest)
 {
struct addrinfo *res, *t;
@@ -259,7 +261,7 @@ static struct pingpong_dest *pp_server_exch_dest(struct 
pingpong_context *ctx,
 
sscanf(msg, %x:%x:%x, rem_dest-lid, rem_dest-qpn, rem_dest-psn);
 
-   if (pp_connect_ctx(ctx, ib_port, my_dest-psn, mtu, rem_dest)) {
+   if (pp_connect_ctx(ctx, ib_port, my_dest-psn, mtu, sl, rem_dest)) {
fprintf(stderr, Couldn't connect to remote QP\n);
free(rem_dest);
rem_dest = NULL;
@@ -473,6 +475,7 @@ static void usage(const char *argv0)
printf(  -m, --mtu=size   path MTU (default 1024)\n);
printf(  -r, --rx-depth=dep   number of receives to post at a time 
(default 500)\n);
printf(  -n, --iters=itersnumber of exchanges (default 1000)\n);
+   printf(  -l, --sl=sl  service level value\n);
printf(  -e, --events   sleep on CQ events (default poll)\n);
 }
 
@@ -496,6 +499,7 @@ int main(int argc, char *argv[])
int  routs;
int  rcnt, scnt;
int  num_cq_events = 0;
+   int  sl = 0;
 
srand48(getpid() * time(NULL));
 
@@ -510,11 +514,12 @@ int main(int argc, char *argv[])
{ .name = mtu,  .has_arg = 1, .val = 'm' },
{ .name = rx-depth, .has_arg = 1, .val = 'r' },
{ .name = iters,.has_arg = 1, .val = 'n' },
+   { .name = sl,   .has_arg = 1, .val = 'l' },
{ .name = events,   .has_arg = 0, .val = 'e' },
{ 0 }
};
 
-   c = getopt_long(argc, argv, p:d:i:s:m:r:n:e, long_options, 
NULL);
+   c = getopt_long(argc, argv, p:d:i:s:m:r:n:l:e, long_options, 
NULL);
if (c == -1)
break;
 
@@ -558,6 +563,10 @@ int main(int argc, char *argv[])
iters = strtol(optarg, NULL, 0);
break;
 
+   case 'l':
+   sl = strtol(optarg, NULL, 0);
+   break;
+
case 'e':
++use_event;
break;
@@ -631,7 +640,7 @@ int main(int argc, char *argv[])
if (servername)
rem_dest = pp_client_exch_dest(servername, port, my_dest);
else
-   rem_dest = pp_server_exch_dest(ctx, ib_port, mtu, port, 
my_dest);
+   rem_dest = pp_server_exch_dest(ctx, ib_port, mtu, port, sl, 
my_dest);
 
if (!rem_dest)
return 1;
@@ -640,7 +649,7 @@ int main(int argc, char *argv[])
   rem_dest-lid, rem_dest-qpn, rem_dest-psn);
 
if (servername)
-   if (pp_connect_ctx(ctx, ib_port, my_dest.psn, mtu, rem_dest))
+   if (pp_connect_ctx(ctx, ib_port, my_dest.psn, mtu, sl, 
rem_dest))
return 1;
 
ctx-pending = PINGPONG_RECV_WRID;
diff --git a/examples/srq_pingpong.c b/examples/srq_pingpong.c
index 490ad0a..1ff4668 100644
--- a/examples/srq_pingpong.c
+++ b/examples/srq_pingpong.c
@@ -80,7 +80,7 @@ struct pingpong_dest {
 };
 
 static int pp_connect_ctx(struct pingpong_context *ctx, int port, enum ibv_mtu 
mtu,
- const struct pingpong_dest *my_dest,
+ 

[ofa-general] Jetzt bestellen und ein blaues Wunder erleben

[Mitch Pack]

Sie leben nur einmal - warum dann nicht was neues ausprobieren?

Original - 100% wirksam 
Ciiiaalis 10 Pack. 26,99 Euro
Viiigra 10 Pack. 20,99 Euro

- Kein langes Warten - Auslieferung innerhalb von 2-3 Tagen
- Kein peinlicher Arztbesuch erforderlich
- Diskrete Verpackung und Zahlung
- Kostenlose, arztliche Telefon-Beratung
- Bequem und diskret online bestellen.
- Visa verifizierter Onlineshop
- keine versteckte Kosten

Mit unseren Produkten vergessen Sie Ihre Enttauschungen, anhaltende 
Versagensangste und wiederholte peinliche Situationen

Jetzt bestellen - und vier Pillen umsonst erhalten

http://digjisj.factonly.cn/?448859891598
(bitte warten Sie einen Moment bis die Seite vollstandig geladen wird)___
general mailing list
general@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

[ofa-general] [PATCH] infiniband-diags/scripts: Eliminate some duplicated messages

[Hal Rosenstock]

infiniband-diags/scripts: Eliminate some duplicated messages

Signed-off-by: Hal Rosenstock [EMAIL PROTECTED]

diff --git a/infiniband-diags/scripts/ibcheckerrors.in 
b/infiniband-diags/scripts/ibcheckerrors.in
index ebf44ec..cac2475 100644
--- a/infiniband-diags/scripts/ibcheckerrors.in
+++ b/infiniband-diags/scripts/ibcheckerrors.in
@@ -131,7 +131,7 @@ function check_node(lid)
}
 }
 
-/^ib/  {print $0}
+/^ib/  {print $0; next}
 /ibpanic:/ {print $0}
 /ibwarn:/  {print $0}
 /iberror:/ {print $0}
diff --git a/infiniband-diags/scripts/ibcheckerrs.in 
b/infiniband-diags/scripts/ibcheckerrs.in
index 1a2d228..305379a 100644
--- a/infiniband-diags/scripts/ibcheckerrs.in
+++ b/infiniband-diags/scripts/ibcheckerrs.in
@@ -188,7 +188,7 @@ BEGIN {
 
 /AllPortSelect/ {next}
 
-/^ib/  {print $0}
+/^ib/  {print $0; next}
 /ibpanic:/ {print $0}
 /ibwarn:/  {print $0}
 /iberror:/ {print $0}
diff --git a/infiniband-diags/scripts/ibchecknet.in 
b/infiniband-diags/scripts/ibchecknet.in
index a47ab8e..b6e0945 100644
--- a/infiniband-diags/scripts/ibchecknet.in
+++ b/infiniband-diags/scripts/ibchecknet.in
@@ -132,7 +132,7 @@ function check_node(lid)
}
 }
 
-/^ib/  {print $0}
+/^ib/  {print $0; next}
 /ibpanic:/ {print $0}
 /ibwarn:/  {print $0}
 /iberror:/ {print $0}
diff --git a/infiniband-diags/scripts/ibcheckport.in 
b/infiniband-diags/scripts/ibcheckport.in
index 94cfc6c..fa5e81e 100644
--- a/infiniband-diags/scripts/ibcheckport.in
+++ b/infiniband-diags/scripts/ibcheckport.in
@@ -116,7 +116,7 @@ function blue(s)
 
 #/^LocalPort/  { if ($2 != '$portnum') {err = err #error: port  $2  does 
not match query ('$portnum')\n; exit -1}}
 
-/^ib/  {print $0}
+/^ib/  {print $0; next}
 /ibpanic:/ {print $0}
 /ibwarn:/  {print $0}
 /iberror:/ {print $0}
diff --git a/infiniband-diags/scripts/ibcheckportstate.in 
b/infiniband-diags/scripts/ibcheckportstate.in
index 2931f06..47e72dc 100644
--- a/infiniband-diags/scripts/ibcheckportstate.in
+++ b/infiniband-diags/scripts/ibcheckportstate.in
@@ -108,7 +108,7 @@ function blue(s)
 
 /^LinkState/{ if ($2 != Active) warn = warn #warn: Logical link state is  
$2   lid '$lid' port '$portnum'\n}
 
-/^ib/  {print $0}
+/^ib/  {print $0; next}
 /ibpanic:/ {print $0}
 /ibwarn:/  {print $0}
 /iberror:/ {print $0}
diff --git a/infiniband-diags/scripts/ibcheckportwidth.in 
b/infiniband-diags/scripts/ibcheckportwidth.in
index 84f1ef7..32c5c5e 100644
--- a/infiniband-diags/scripts/ibcheckportwidth.in
+++ b/infiniband-diags/scripts/ibcheckportwidth.in
@@ -106,7 +106,7 @@ function blue(s)
 /^LinkWidthSupported/{ if ($2 != 1X) { next } }
 /^LinkWidthActive/{ if ($2 == 1X) warn = warn #warn: Link configured as 1X  
lid '$lid' port '$portnum'\n}
 
-/^ib/  {print $0}
+/^ib/  {print $0; next}
 /ibpanic:/ {print $0}
 /ibwarn:/  {print $0}
 /iberror:/ {print $0}
diff --git a/infiniband-diags/scripts/ibcheckstate.in 
b/infiniband-diags/scripts/ibcheckstate.in
index 6ce0854..63551d5 100644
--- a/infiniband-diags/scripts/ibcheckstate.in
+++ b/infiniband-diags/scripts/ibcheckstate.in
@@ -122,7 +122,7 @@ function check_node(lid)
}
 }
 
-/^ib/  {print $0}
+/^ib/  {print $0; next}
 /ibpanic:/ {print $0}
 /ibwarn:/  {print $0}
 /iberror:/ {print $0}
diff --git a/infiniband-diags/scripts/ibcheckwidth.in 
b/infiniband-diags/scripts/ibcheckwidth.in
index f8f6a8b..6b723c5 100644
--- a/infiniband-diags/scripts/ibcheckwidth.in
+++ b/infiniband-diags/scripts/ibcheckwidth.in
@@ -122,7 +122,7 @@ function check_node(lid)
}
 }
 
-/^ib/  {print $0}
+/^ib/  {print $0; next}
 /ibpanic:/ {print $0}
 /ibwarn:/  {print $0}
 /iberror:/ {print $0}
diff --git a/infiniband-diags/scripts/ibclearcounters.in 
b/infiniband-diags/scripts/ibclearcounters.in
index 1818c42..0413d86 100644
--- a/infiniband-diags/scripts/ibclearcounters.in
+++ b/infiniband-diags/scripts/ibclearcounters.in
@@ -102,7 +102,7 @@ function clear_port_counters(lid, port)
}
}
 
-/^ib/  {print $0}
+/^ib/  {print $0; next}
 /ibpanic:/ {print $0}
 /ibwarn:/  {print $0}
 /iberror:/ {print $0}
diff --git a/infiniband-diags/scripts/ibclearerrors.in 
b/infiniband-diags/scripts/ibclearerrors.in
index c63283a..930efa6 100644
--- a/infiniband-diags/scripts/ibclearerrors.in
+++ b/infiniband-diags/scripts/ibclearerrors.in
@@ -95,7 +95,7 @@ function clear_errors(lid, port)
}
}
 
-/^ib/  {print $0}
+/^ib/  {print $0; next}
 /ibpanic:/ {print $0}
 /ibwarn:/  {print $0}
 /iberror:/ {print $0}
diff --git a/infiniband-diags/scripts/ibdatacounters.in 
b/infiniband-diags/scripts/ibdatacounters.in
index 902a865..7f0df1c 100644
--- a/infiniband-diags/scripts/ibdatacounters.in
+++ b/infiniband-diags/scripts/ibdatacounters.in
@@ -130,7 +130,7 @@ function check_node(lid)
}
 }
 
-/^ib/  {print $0}

[ofa-general] Re: [ewg] OFED October 22 meeting summary on OFED 1.3 alpha status and beta tasks

[Vladimir Sokolovsky]

Hoang-Nam Nguyen wrote:

Hi,

3. Tasks that should completed for the beta:
   4. Fix compilation problems on PPC with 32 bits - Vlad
(Mellanox) -
 Nam please open a bug on this issue

Stefan has created #746 Installation of 32-bit libibverbs failed.
@Vlad, since we'll have rpm spec for user space with beta, would it
better to tackle this with rpm specs? For libibverbs is it
libibverbs.spec.in we need to look at?
Thanks
Nam



Hi Nam,
Please recheck this issue with the latest OFED-1.3 build.
If this issue still exist then it is probably install.pl issue.

Please update me,
Thanks,

Vladimir
___
general mailing list
general@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

[ofa-general] Re: [ewg] OFED October 22 meeting summary on OFED 1.3 alpha status and beta tasks

[Hoang-Nam Nguyen]

Hi,
 3. Tasks that should completed for the beta:
4. Fix compilation problems on PPC with 32 bits - Vlad
 (Mellanox) -
  Nam please open a bug on this issue
Stefan has created #746 Installation of 32-bit libibverbs failed.
@Vlad, since we'll have rpm spec for user space with beta, would it
better to tackle this with rpm specs? For libibverbs is it
libibverbs.spec.in we need to look at?
Thanks
Nam

___
general mailing list
general@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

Re: [ofa-general] Re: __always_inline macro usage

[Roland Dreier]

  The macro is currently being used in libmlx4 (src/qp.c).  That's what started
  the thread.

Oh, I misunderstood completely.  __always_inline is a kernel-only
thing.  I'll fix up libmlx4.

 - R.
___
general mailing list
general@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

Re: [ofa-general] OFED October 22 meeting summary on OFED 1.3 alphastatus and beta tasks

[Erez Zilber]

Tziporet Koren wrote:


OFED October 8 meeting summary on OFED 1.3 alpha status and beta tasks:

Meeting summary:

1. Alpha release status:
* Cisco - tested only RHEL 4  5 on x86_64 systems
* Qlogic - in general looks good
* Intel - test Intel MPI on 16 nodes cluster on RHEL 5.1
* Voltaire - partial regression SLES10 SP1 Redhat 5; few on RHEL 4 up5
* Mellanox - regression tests pass on all HCAs. Tested SLES10, RHEL 4 up
4  up5 , RHEL 5
* IBM - test mainly SLES10 SP1 on PPC; solve issues in ehca with their
new HCA;
see issues with 32 bits library

2. MPI status:
* MVAPICH - We wish to integrate the 1.0 code by the end of this week.
In this way it will be ready for the OFED beta release next week - need
DK approval
* Open MPI - Open MPI v1.2.4 is sufficient for OFED 1.3. It contains a
critical fix for ConnectX hardware that will greatly improve the
point-to-point latency for small messages.
Open MPI v1.3 is far enough away that we're not ready for anything newer
to go into OFED 1.3.
* VMAPICH 2 - ready for the release.

3. Tasks that should completed for the beta:
1. Integrate all SDP features - Jim (Mellanox) - will be
completed this week
2. Complete RDS work - Vlad (Mellanox) - on work
3. Apply patches that fix warning of backport patches - Vlad
(Mellanox)
4. Fix compilation problems on PPC with 32 bits - Vlad
(Mellanox) -
 Nam please open a bug on this issue
5. Add qperf test from Qlogic - Johann (Qlogic) - on work
6. Rebase kernel code on 2.6.24 rc1 (depending it's
availability)
   Will require changes in the bonding module too.
7. Support RHEL 5 up1 - Woody  Vlad - done
8. SPEC files should be part of each user space package - each
owner should take the spec file
9. Multiple uDAPL libs (1.0  2.0)
 10. iSER - update the open iscsi package 



Done


 11. nes - need to update some backport patches (Gleb)

* Beta target date will be decided in next week meeting based on the
progress of the above


4. OFED meetings:
* Starting next week we will move to weekly meetings to have a better
tracking for the release progress
* Jeff S. will send the meeting schedule and details

5. NFS-RDMA:
* NFS-RDMA will be part of Linux kernel 2.6.24
* Thus it will be in OFED 1.3 kernel, but we need backport patches to
support the distros
* Bill Boas will speak to OGC (Tom Tucker and Steve Wise) to see if this
can be done for the beta, at least for the latest OSes (e.g. RHEL5,
SLES10 SP1)

6. Developers' summit:
* All people requested to review the agenda Johann will publish and make
sure all subjects we wish to discuss are covered.

___
general mailing list
general@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general

To unsubscribe, please visit 
http://openib.org/mailman/listinfo/openib-general



___
general mailing list
general@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

[ofa-general] [PATCH] IB/ipoib: IPOIB CM rx use higher order fragments

[Eli Cohen]

IPOIB CM rx use higher order fragments

In order to reduce the overhead of iterating the fragments of an
SKB in the receive flow, we use fragments of higher order and thus
reduce the number of iterations. This patch seams to improve receive
throughput of small UDP messages.

Signed-off-by: Eli Cohen [EMAIL PROTECTED]
---

I used the following command line to see improvemet:
netperf -H 12.4.3.175 -t UDP_STREAM -- -m 128

 drivers/infiniband/ulp/ipoib/ipoib.h|5 -
 drivers/infiniband/ulp/ipoib/ipoib_cm.c |   18 +-
 2 files changed, 13 insertions(+), 10 deletions(-)

diff --git a/drivers/infiniband/ulp/ipoib/ipoib.h 
b/drivers/infiniband/ulp/ipoib/ipoib.h
index 0a00ea0..6cf14ff 100644
--- a/drivers/infiniband/ulp/ipoib/ipoib.h
+++ b/drivers/infiniband/ulp/ipoib/ipoib.h
@@ -57,6 +57,8 @@
 
 enum {
IPOIB_PACKET_SIZE = 2048,
+   IPOIB_FRAG_ORDER  = 2,
+   IPOIB_FRAG_SIZE   = PAGE_SIZE  IPOIB_FRAG_ORDER,
IPOIB_BUF_SIZE= IPOIB_PACKET_SIZE + IB_GRH_BYTES,
 
IPOIB_ENCAP_LEN   = 4,
@@ -64,7 +66,8 @@ enum {
IPOIB_CM_MTU  = 0x1 - 0x10, /* padding to align header 
to 16 */
IPOIB_CM_BUF_SIZE = IPOIB_CM_MTU  + IPOIB_ENCAP_LEN,
IPOIB_CM_HEAD_SIZE= IPOIB_CM_BUF_SIZE % PAGE_SIZE,
-   IPOIB_CM_RX_SG= ALIGN(IPOIB_CM_BUF_SIZE, PAGE_SIZE) / 
PAGE_SIZE,
+   IPOIB_CM_RX_SG= 1 + ALIGN(IPOIB_CM_BUF_SIZE - 
IPOIB_CM_HEAD_SIZE,
+   IPOIB_FRAG_SIZE) / 
IPOIB_FRAG_SIZE,
IPOIB_RX_RING_SIZE= 128,
IPOIB_TX_RING_SIZE= 64,
IPOIB_MAX_QUEUE_SIZE  = 8192,
diff --git a/drivers/infiniband/ulp/ipoib/ipoib_cm.c 
b/drivers/infiniband/ulp/ipoib/ipoib_cm.c
index 8761077..5fee3c6 100644
--- a/drivers/infiniband/ulp/ipoib/ipoib_cm.c
+++ b/drivers/infiniband/ulp/ipoib/ipoib_cm.c
@@ -78,7 +78,7 @@ static void ipoib_cm_dma_unmap_rx(struct ipoib_dev_priv 
*priv, int frags,
ib_dma_unmap_single(priv-ca, mapping[0], IPOIB_CM_HEAD_SIZE, 
DMA_FROM_DEVICE);
 
for (i = 0; i  frags; ++i)
-   ib_dma_unmap_single(priv-ca, mapping[i + 1], PAGE_SIZE, 
DMA_FROM_DEVICE);
+   ib_dma_unmap_single(priv-ca, mapping[i + 1], IPOIB_FRAG_SIZE, 
DMA_FROM_DEVICE);
 }
 
 static int ipoib_cm_post_receive(struct net_device *dev, int id)
@@ -129,14 +129,14 @@ static struct sk_buff *ipoib_cm_alloc_rx_skb(struct 
net_device *dev, int id, int
}
 
for (i = 0; i  frags; i++) {
-   struct page *page = alloc_page(GFP_ATOMIC);
+   struct page *page = alloc_pages(GFP_ATOMIC | __GFP_COMP, 
IPOIB_FRAG_ORDER);
 
if (!page)
goto partial_error;
-   skb_fill_page_desc(skb, i, page, 0, PAGE_SIZE);
+   skb_fill_page_desc(skb, i, page, 0, IPOIB_FRAG_SIZE);
 
mapping[i + 1] = ib_dma_map_page(priv-ca, 
skb_shinfo(skb)-frags[i].page,
-0, PAGE_SIZE, DMA_FROM_DEVICE);
+0, IPOIB_FRAG_SIZE, 
DMA_FROM_DEVICE);
if (unlikely(ib_dma_mapping_error(priv-ca, mapping[i + 1])))
goto partial_error;
}
@@ -384,10 +384,10 @@ static void skb_put_frags(struct sk_buff *skb, unsigned 
int hdr_space,
 
if (length == 0) {
/* don't need this page */
-   skb_fill_page_desc(toskb, i, frag-page, 0, PAGE_SIZE);
+   skb_fill_page_desc(toskb, i, frag-page, 0, 
IPOIB_FRAG_SIZE);
--skb_shinfo(skb)-nr_frags;
} else {
-   size = min(length, (unsigned) PAGE_SIZE);
+   size = min(length, (unsigned) IPOIB_FRAG_SIZE);
 
frag-size = size;
skb-data_len += size;
@@ -447,8 +447,8 @@ void ipoib_cm_handle_rx_wc(struct net_device *dev, struct 
ib_wc *wc)
}
}
 
-   frags = PAGE_ALIGN(wc-byte_len - min(wc-byte_len,
- (unsigned)IPOIB_CM_HEAD_SIZE)) / 
PAGE_SIZE;
+   frags = ALIGN(wc-byte_len - min(wc-byte_len,
+(unsigned)IPOIB_CM_HEAD_SIZE), IPOIB_FRAG_SIZE) / 
IPOIB_FRAG_SIZE;
 
newskb = ipoib_cm_alloc_rx_skb(dev, wr_id, frags, mapping);
if (unlikely(!newskb)) {
@@ -1302,7 +1302,7 @@ int ipoib_cm_dev_init(struct net_device *dev)
 
priv-cm.rx_sge[0].length = IPOIB_CM_HEAD_SIZE;
for (i = 1; i  IPOIB_CM_RX_SG; ++i)
-   priv-cm.rx_sge[i].length = PAGE_SIZE;
+   priv-cm.rx_sge[i].length = IPOIB_FRAG_SIZE;
priv-cm.rx_wr.next = NULL;
priv-cm.rx_wr.sg_list = priv-cm.rx_sge;
priv-cm.rx_wr.num_sge = IPOIB_CM_RX_SG;
-- 
1.5.3.4


___
general mailing list

[ofa-general] [GIT PULL] please pull infiniband.git

[Roland Dreier]

Linus, please pull from

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

This tree is also available from kernel.org mirrors at:

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

this will get some more fixes/changes for 2.6.24.  I have one more
IPoIB feature (support for CM without SRQs) I hope to send later
today, but we'll see...

Anton Blanchard (1):
  IPoIB: Use round_jiffies() for ah_reap_task

Jack Morgenstein (2):
  IB/mlx4: Sanity check userspace send queue sizes
  mlx4_core: Increase command timeout for INIT_HCA to 10 seconds

Joachim Fenkes (5):
  IB/ehca: Supply QP token for SRQ base QPs
  IB/ehca: Fix masking error in {,re}reg_phys_mr()
  IB/ehca: Fix ehca_encode_hwpage_size() and alloc_fmr()
  IB/ehca: Change meaning of hca_cap_mr_pgsize
  IB/ehca: Enable large page MRs by default

Michael S. Tsirkin (1):
  IPoIB/cm: Use common CQ for CM send completions

Roland Dreier (4):
  mlx4_core: Kill mlx4_write64_raw()
  IB/mthca: Avoid alignment traps when writing doorbells
  IPoIB: Rewrite if (!likely(...)) as if (unlikely(!(...)))
  IB/uverbs: Fix checking of userspace object ownership

Sean Hefty (2):
  RDMA/cma: Add locking around QP accesses
  RDMA/cma: Fix deadlock destroying listen requests

 drivers/infiniband/core/cma.c|  160 +
 drivers/infiniband/core/uverbs_cmd.c |8 +-
 drivers/infiniband/hw/ehca/ehca_classes.h|1 -
 drivers/infiniband/hw/ehca/ehca_hca.c|1 +
 drivers/infiniband/hw/ehca/ehca_main.c   |   20 +++-
 drivers/infiniband/hw/ehca/ehca_mrmw.c   |   57 -
 drivers/infiniband/hw/ehca/ehca_qp.c |4 +-
 drivers/infiniband/hw/mlx4/qp.c  |   16 +++-
 drivers/infiniband/hw/mthca/mthca_cq.c   |   53 +++--
 drivers/infiniband/hw/mthca/mthca_doorbell.h |   13 ++-
 drivers/infiniband/hw/mthca/mthca_eq.c   |   21 +---
 drivers/infiniband/hw/mthca/mthca_qp.c   |   45 +++-
 drivers/infiniband/hw/mthca/mthca_srq.c  |   11 +--
 drivers/infiniband/ulp/ipoib/ipoib.h |   15 ++-
 drivers/infiniband/ulp/ipoib/ipoib_cm.c  |  114 ---
 drivers/infiniband/ulp/ipoib/ipoib_ib.c  |   52 +
 drivers/infiniband/ulp/ipoib/ipoib_main.c|4 +-
 drivers/net/mlx4/fw.c|2 +-
 include/linux/mlx4/doorbell.h|   11 --
 19 files changed, 284 insertions(+), 324 deletions(-)


diff --git a/drivers/infiniband/core/cma.c b/drivers/infiniband/core/cma.c
index 93644f8..ee946cc 100644
--- a/drivers/infiniband/core/cma.c
+++ b/drivers/infiniband/core/cma.c
@@ -114,13 +114,16 @@ struct rdma_id_private {
 
struct rdma_bind_list   *bind_list;
struct hlist_node   node;
-   struct list_headlist;
-   struct list_headlisten_list;
+   struct list_headlist; /* listen_any_list or cma_device.list */
+   struct list_headlisten_list; /* per device listens */
struct cma_device   *cma_dev;
struct list_headmc_list;
 
+   int internal_id;
enum cma_state  state;
spinlock_t  lock;
+   struct mutexqp_mutex;
+
struct completion   comp;
atomic_trefcount;
wait_queue_head_t   wait_remove;
@@ -389,6 +392,7 @@ struct rdma_cm_id *rdma_create_id(rdma_cm_event_handler 
event_handler,
id_priv-id.event_handler = event_handler;
id_priv-id.ps = ps;
spin_lock_init(id_priv-lock);
+   mutex_init(id_priv-qp_mutex);
init_completion(id_priv-comp);
atomic_set(id_priv-refcount, 1);
init_waitqueue_head(id_priv-wait_remove);
@@ -474,61 +478,86 @@ EXPORT_SYMBOL(rdma_create_qp);
 
 void rdma_destroy_qp(struct rdma_cm_id *id)
 {
-   ib_destroy_qp(id-qp);
+   struct rdma_id_private *id_priv;
+
+   id_priv = container_of(id, struct rdma_id_private, id);
+   mutex_lock(id_priv-qp_mutex);
+   ib_destroy_qp(id_priv-id.qp);
+   id_priv-id.qp = NULL;
+   mutex_unlock(id_priv-qp_mutex);
 }
 EXPORT_SYMBOL(rdma_destroy_qp);
 
-static int cma_modify_qp_rtr(struct rdma_cm_id *id)
+static int cma_modify_qp_rtr(struct rdma_id_private *id_priv)
 {
struct ib_qp_attr qp_attr;
int qp_attr_mask, ret;
 
-   if (!id-qp)
-   return 0;
+   mutex_lock(id_priv-qp_mutex);
+   if (!id_priv-id.qp) {
+   ret = 0;
+   goto out;
+   }
 
/* Need to update QP attributes from default values. */
qp_attr.qp_state = IB_QPS_INIT;
-   ret = rdma_init_qp_attr(id, qp_attr, qp_attr_mask);
+   ret = rdma_init_qp_attr(id_priv-id, qp_attr, qp_attr_mask);
if (ret)
-   return ret;
+   goto out;
 
-   ret = ib_modify_qp(id-qp, qp_attr, qp_attr_mask);
+   

[ofa-general] Re: [PATCH] IB/ipoib: IPOIB CM rx use higher order fragments

[Roland Dreier]

  In order to reduce the overhead of iterating the fragments of an
  SKB in the receive flow, we use fragments of higher order and thus
  reduce the number of iterations. This patch seams to improve receive
  throughput of small UDP messages.

I don't think we want to do this -- it may be good for benchmarks but
it will hurt reliability, since systems often have highly fragmented
memory so higher-order atomic allocations will fail.

 - R.
___
general mailing list
general@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

Re: [ofa-general] Re: __always_inline macro usage

[Roland Dreier]

Actually just replacing __always_inline with inline seems to work OK
for me.  I think I'll do that for libmlx.
___
general mailing list
general@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

[ofa-general] [RFP] support for iWARP requirement - active connect side MUST send first FPDU

[Arlin Davis]

There has been much discussion on a private thread regarding bug #735 - 
dapltest performance tests don't adhere to iWARP standard that needs 
to move to the general list.


iWARP, has a requirement that the active side of the connection MUST be 
the first to send the first FPDU (SEND or RDMA operation). This presents 
a problem with applications written for uDAPL and OFA verbs given that 
there is no such restriction. So, short of requiring every OFA 
application/ULP to adhere to this restriction, we need the iWARP vendors 
to come up with a standard method to remove the restriction.


Can someone come up with a solution, possibly in iWARP CM, that will 
work and insure interoperability between iWARP devices?



-arlin







___
general mailing list
general@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

Re: [ofa-general] [RFP] support for iWARP requirement - active connect side MUST send first FPDU

[Sean Hefty]

There has been much discussion on a private thread regarding bug #735 - 
dapltest performance tests don't adhere to iWARP standard that needs 
to move to the general list.


This bug would be better titled iWarp cannot support uDAPL API. :)

Seriously, the iWarp and uDAPL specs conflict.  One needs to change.

Can someone come up with a solution, possibly in iWARP CM, that will 
work and insure interoperability between iWARP devices?


I thought the restriction was there to support switching between 
streaming and rdma mode.  If a connection only uses rdma mode, is the 
restriction really needed at all?


- Sean
___
general mailing list
general@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

Re: [ofa-general] [RFP] support for iWARP requirement - active connect side MUST send first FPDU

[Roland Dreier]

  iWARP, has a requirement that the active side of the connection MUST
  be the first to send the first FPDU (SEND or RDMA operation). This
  presents a problem with applications written for uDAPL and OFA verbs
  given that there is no such restriction. So, short of requiring every
  OFA application/ULP to adhere to this restriction, we need the iWARP
  vendors to come up with a standard method to remove the restriction.

I actually don't see a problem with just documenting that verbs
consumers that want to work on top of iWARP must follow the documented
iWARP rules.

 - R.
___
general mailing list
general@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

[ofa-general] OpenFabrics Developer's Summit: tentative agenda

[Johann George]

Below is a tentative agenda for the upcoming OpenFabrics Developer's
Summit.  While most sessions are confirmed, at least a couple of
speakers are attempting to resolve conflicts so they may attend.  We
have attempted to accommodate everyone but if you are speaking and see
a conflict with the proposed time of your session, let me know.  An
updated agenda will be made available in the future.

You can register by clicking on this link:

http://www.acteva.com/booking.cfm?bevaid=143964

The Developer's Summit is being held November during 15-16, 2007 at
the Boomtown Hotel near Reno.  Dinner will be provided on Thursday as
well as breakfast and lunch on Friday.  Registration is $195 with a
student rate of $95.  Rooms are available at the Boomtown hotel
starting at $59/night.

Comments, suggestions and feedback on the agenda are also welcome.

Johann



Thursday, November 15, 2007
---
13:00  20m  OFED: Feedback from Alexa
Ekechi Nwokah, Alexa
13:20  20m  OFED: Feedback from RedHat
Doug Ledford, RedHat
13:40  20m  OFED: Feedback from SuSE
Moiz Kohari, Novell
14:00  20m  The Journey of a Patch: from Submission to Distros
Roland Drier, Cisco
14:20  30m  OFED 1.3 Update and Procedure Review
Tziporet Koren, Mellanox

14:50  20m  Break

15:10  20m  OpenFabrics Logo Program: Experience So Far
Arkady Kanevsky, Network Appliance
15:30  30m  Update on MVAPICH and MVAPICH2
DK Panda, Ohio State University
16:00  20m  Update on OpenMPI
Jeff Sqyures, Cisco
16:20  20m  uDAPL 2.0
Arkady Kanevsky, Network Appliance
16:40  20m  SA Caching
Sean Hefty, Intel

17:00  60m  Dinner

18:00  20m  Update on NFSoRDMA
James Lentini, Network Appliance
18:20  20m  Lustre
Eric Barton, Sun Microsystems
18:40  20m  Bonding
Or Gerlitz, Voltaire
19:00  20m  iWARP update
Bill Boas, System Fabric Works
19:20  40m  iWARP discussion on issues
Bill Boas, System Fabric Works; Gopal Hegde, Cisco; Glenn
Grundstrom, NetEffect; Bruck Girmay, Chelsio



Friday, November 16, 2007
-
07:15  45m  Breakfast

08:00  30m  WinOF: Update and Futures
Gilad Shainer, Mellanox
08:30  30m  CCS Ve2 Preview
Eric Lantz, Microsoft
09:00  30m  OFED 1.4 Planned Features
Tziporet Koren, Mellanox
09:30  20m  OFED Management Tools
Ira Weiny, Lawrence Livermore National Laboratories

09:50  20m  Break

10:10  20m  RDS with Zero Copy
Rick Frank, Oracle
10:30  20m  QoS Support
 Sean Hefty, Intel; Dror Goldenberg, Mellanox
10:50  20m  InfiniBand Routing Update
Jason Gunthorpe, Obsidian Research
11:10  20m  IPoIB Stateless Offloads
   Liran Liss, Mellanox
11:30  20m  Using XRC
Dror Goldenberg, Mellanox and Dr. Panda, Ohio State
University
11:50  20m  Fibre Channel over InfiniBand
Dror Goldenberg, Mellanox

12:10  60m  Lunch

___
general mailing list
general@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

Re: [ofa-general] [RFP] support for iWARP requirement - active connect side MUST send first FPDU

[Steve Wise]

Sean Hefty wrote:
There has been much discussion on a private thread regarding bug #735 
- dapltest performance tests don't adhere to iWARP standard that 
needs to move to the general list.


This bug would be better titled iWarp cannot support uDAPL API. :)

Seriously, the iWarp and uDAPL specs conflict.  One needs to change.

Can someone come up with a solution, possibly in iWARP CM, that will 
work and insure interoperability between iWARP devices?


I thought the restriction was there to support switching between 
streaming and rdma mode.  If a connection only uses rdma mode, is the 
restriction really needed at all?




Yes because all iWARP connections start out as TCP streaming mode 
connections, and the MPA startup messages are sent in streaming mode. 
Then the connection is  transitioned into FPDU (Framed PDU) mode using 
the MPA protocol.


___
general mailing list
general@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

[ofa-general] Re: [PATCH v3] osm: QoS - adding CPI:CapabilityMask2 and turning on QOS_SUPPORTED bit

[Sasha Khapyorsky]

On 11:03 Tue 23 Oct , Yevgeny Kliteynik wrote:
 Adding ClassPortInfo:CapabilityMask2 field and turning
 on OSM QoS capability bit (OSM_CAP2_IS_QOS_SUPPORTED).
 
 Signed-off-by: Yevgeny Kliteynik [EMAIL PROTECTED]

Applied. Thanks.

Sasha
___
general mailing list
general@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

[ofa-general] Re: [PATCH] infiniband-diags/scripts: Eliminate some duplicated messages

[Sasha Khapyorsky]

On 06:05 Tue 23 Oct , Hal Rosenstock wrote:
 infiniband-diags/scripts: Eliminate some duplicated messages
 
 Signed-off-by: Hal Rosenstock [EMAIL PROTECTED]

Applied. Thanks.

Sasha
___
general mailing list
general@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

Re: [ofa-general] [RFP] support for iWARP requirement - active connect side MUST send first FPDU

[Steve Wise]

Roland Dreier wrote:

  iWARP, has a requirement that the active side of the connection MUST
  be the first to send the first FPDU (SEND or RDMA operation). This
  presents a problem with applications written for uDAPL and OFA verbs
  given that there is no such restriction. So, short of requiring every
  OFA application/ULP to adhere to this restriction, we need the iWARP
  vendors to come up with a standard method to remove the restriction.

I actually don't see a problem with just documenting that verbs
consumers that want to work on top of iWARP must follow the documented
iWARP rules.



That is what I've been trying to push.  Both MVAPICH2 and OMPI have been 
open to adjusting their transports to adhere to this requirement.


I wouldn't mind implementing something to enforce this in the IWCM or 
the iWARP drivers IF there was a clean way to do it.  So far there 
hasn't been a clean way proposed.

___
general mailing list
general@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

[ofa-general] [PATCH][TRIVIAL] infiniband-diags/sminfo: Fix activity count display

[Hal Rosenstock]

infiniband-diags/sminfo: Fix activity count display

Signed-off-by: Hal Rosenstock [EMAIL PROTECTED]

diff --git a/infiniband-diags/src/sminfo.c b/infiniband-diags/src/sminfo.c
index 0cd63f9..87f09ac 100644
--- a/infiniband-diags/src/sminfo.c
+++ b/infiniband-diags/src/sminfo.c
@@ -42,7 +42,7 @@
 #include inttypes.h
 #include getopt.h
 
-#define __BUILD_VERSION_TAG__ 1.2.1
+#define __BUILD_VERSION_TAG__ 1.2.2
 #include infiniband/common.h
 #include infiniband/umad.h
 #include infiniband/mad.h
@@ -89,7 +89,8 @@ main(int argc, char **argv)
ib_portid_t portid = {0};
int timeout = 0;/* use default */
uint8_t *p;
-   int act = 0, prio = 0, state = SMINFO_STANDBY;
+   uint act = 0;
+   int prio = 0, state = SMINFO_STANDBY;
uint64_t guid = 0, key = 0;
extern int ibdebug;
int dest_type = IB_DEST_LID;
@@ -199,7 +200,7 @@ main(int argc, char **argv)
mad_decode_field(sminfo, IB_SMINFO_PRIO_F, prio);
mad_decode_field(sminfo, IB_SMINFO_STATE_F, state);
 
-   printf(sminfo: sm lid %d sm guid 0x% PRIx64 , activity count %d 
priority %d state %d %s\n,
+   printf(sminfo: sm lid %d sm guid 0x% PRIx64 , activity count %u 
priority %d state %d %s\n,
portid.lid, guid, act, prio, state, STATESTR(state));
 
exit(0);

___
general mailing list
general@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

[ofa-general] Re: [PATCH V4] infiniband/core: Enable loopback of DR SMP responses from userspace

[Hal Rosenstock]

Steve,

On Fri, 2007-10-19 at 12:41 -0500, [EMAIL PROTECTED] wrote:
 
   This patch [v4] replaces the [v3] patch; it's identicial other than
   the patch description has been updated to put back in the detailed
   patch description absent from the [v3] patch.
 
   The local loopback of an outgoing DR SMP response is limited to those
   that originate at the driver specific SMA implementation during the
   driver specific process_mad() function.  This patch enables a
   returning DR SMP originating in userspace (or elsewhere) to be
   delivered to the local managment stack.  In this specific  case
   the driver process_mad() function does not consume or process
   the MAD, so a reponse mad has not be created and the original
   MAD must manually be copied to the MAD buffer that is to be handed
   off to the local agent.
 
   For consistent bahavior on top of iPath hardware, a subsequent patch
   to be submitted by Ralph Campbell to update process_mad() return values
   is required.

Guess you didn't like my naming consistency change (which could be done
separately).

Acked-by: Hal Rosenstock [EMAIL PROTECTED]

but we ought to wait to hear from Sasha to be sure

-- Hal

   Thanks, Steve
 
 Signed-off-by: Steve Welch [EMAIL PROTECTED]
 ---
  drivers/infiniband/core/mad.c |6 +++---
  drivers/infiniband/core/smi.h |   18 +-
  2 files changed, 20 insertions(+), 4 deletions(-)
 
 diff --git a/drivers/infiniband/core/mad.c b/drivers/infiniband/core/mad.c
 index 6f42877..98148d6 100644
 --- a/drivers/infiniband/core/mad.c
 +++ b/drivers/infiniband/core/mad.c
 @@ -701,7 +701,8 @@ static int handle_outgoing_dr_smp(struct 
 ib_mad_agent_private *mad_agent_priv,
   }
  
   /* Check to post send on QP or process locally */
 - if (smi_check_local_smp(smp, device) == IB_SMI_DISCARD)
 + if (smi_check_local_smp(smp, device) == IB_SMI_DISCARD 
 + smi_check_local_returning_smp(smp, device) == IB_SMI_DISCARD)
   goto out;
  
   local = kmalloc(sizeof *local, GFP_ATOMIC);
 @@ -752,8 +753,7 @@ static int handle_outgoing_dr_smp(struct 
 ib_mad_agent_private *mad_agent_priv,
   port_priv = ib_get_mad_port(mad_agent_priv-agent.device,
   mad_agent_priv-agent.port_num);
   if (port_priv) {
 - mad_priv-mad.mad.mad_hdr.tid =
 - ((struct ib_mad *)smp)-mad_hdr.tid;
 + memcpy(mad_priv-mad.mad, smp, sizeof(struct ib_mad));
   recv_mad_agent = find_mad_agent(port_priv,
   mad_priv-mad.mad);
   }
 diff --git a/drivers/infiniband/core/smi.h b/drivers/infiniband/core/smi.h
 index 1cfc298..aff96ba 100644
 --- a/drivers/infiniband/core/smi.h
 +++ b/drivers/infiniband/core/smi.h
 @@ -59,7 +59,8 @@ extern enum smi_action smi_handle_dr_smp_send(struct ib_smp 
 *smp,
 u8 node_type, int port_num);
  
  /*
 - * Return 1 if the SMP should be handled by the local SMA/SM via process_mad
 + * Return IB_SMI_HANDLE if the SMP should be handled by the local SMA/SM
 + * via process_mad
   */
  static inline enum smi_action smi_check_local_smp(struct ib_smp *smp,
 struct ib_device *device)
 @@ -71,4 +72,19 @@ static inline enum smi_action smi_check_local_smp(struct 
 ib_smp *smp,
   (smp-hop_ptr == smp-hop_cnt + 1)) ?
   IB_SMI_HANDLE : IB_SMI_DISCARD);
  }
 +
 +/*
 + * Return IB_SMI_HANDLE if the SMP should be handled by the local SMA/SM
 + * via process_mad
 + */
 +static inline enum smi_action smi_check_local_returning_smp(struct ib_smp 
 *smp,
 +struct ib_device *device)
 +{
 + /* C14-13:3 -- We're at the end of the DR segment of path */
 + /* C14-13:4 -- Hop Pointer == 0 - give to SM */
 + return ((device-process_mad 
 + ib_get_smp_direction(smp) 
 + !smp-hop_ptr) ? IB_SMI_HANDLE : IB_SMI_DISCARD);
 +}
 +
  #endif   /* __SMI_H_ */
___
general mailing list
general@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

Re: [ofa-general] [PATCH] IB/ipath - Enable loopback of DR SMP responses from userspace

[Hal Rosenstock]

On Fri, 2007-10-19 at 13:33 -0700, Ralph Campbell wrote:
 This patch is in response to reviewing a patch to the core MAD processing
 which fixes loopback of directed route packets to/from user level
 MAD agents. This change enables the core code to work for ib_ipath.
 
 Signed-off-by: Ralph Campbell [EMAIL PROTECTED]

Acked-by: Hal Rosenstock [EMAIL PROTECTED]

 diff --git a/drivers/infiniband/hw/ipath/ipath_mad.c 
 b/drivers/infiniband/hw/ipath/ipath_mad.c
 index 3d1432d..1978c34 100644
 --- a/drivers/infiniband/hw/ipath/ipath_mad.c
 +++ b/drivers/infiniband/hw/ipath/ipath_mad.c
 @@ -1434,7 +1434,7 @@ static int process_subn(struct ib_device *ibdev, int 
 mad_flags,
* before checking for other consumers.
* Just tell the caller to process it normally.
*/
 - ret = IB_MAD_RESULT_FAILURE;
 + ret = IB_MAD_RESULT_SUCCESS;
   goto bail;
   default:
   smp-status |= IB_SMP_UNSUP_METHOD;
 @@ -1516,7 +1516,7 @@ static int process_perf(struct ib_device *ibdev, u8 
 port_num,
* before checking for other consumers.
* Just tell the caller to process it normally.
*/
 - ret = IB_MAD_RESULT_FAILURE;
 + ret = IB_MAD_RESULT_SUCCESS;
   goto bail;
   default:
   pmp-status |= IB_SMP_UNSUP_METHOD;
 
 
 ___
 general mailing list
 general@lists.openfabrics.org
 http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general
 
 To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
___
general mailing list
general@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

Re: [ofa-general] Re: [PATCH V4] infiniband/core: Enable loopback of DR SMP responses from userspace

[Sasha Khapyorsky]

On 14:11 Tue 23 Oct , Hal Rosenstock wrote:
 
 but we ought to wait to hear from Sasha to be sure

I didn't see any issues with this patch. All works as expected.

Sasha
___
general mailing list
general@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

[ofa-general] Re: [PATCH][TRIVIAL] infiniband-diags/sminfo: Fix activity count display

[Sasha Khapyorsky]

On 14:08 Tue 23 Oct , Hal Rosenstock wrote:
 infiniband-diags/sminfo: Fix activity count display
 
 Signed-off-by: Hal Rosenstock [EMAIL PROTECTED]

Appied. Thanks.

Sasha
___
general mailing list
general@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

[ofa-general] Outstanding MAD/SMI related patches

[Hal Rosenstock]

Hi Roland,

AFAIK there are three outstanding patches now related to MAD and SMI
which have all been acked and I believe are ready to go ahead:

1. [PATCH] IB/core - remove redundant NULL pointer check in
ib_mad_recv_done_handler(): Ralph Campbell 10/17
2. [PATCH V4] infiniband/core: Enable loopback of DR SMP responses  from
userspace: Steve Welch 10/19
3. [PATCH] IB/ipath - Enable loopback of DR SMP responses from
userspace: Ralph Campbell 10/19

Just wanted to be clear on their status as these have floated around for
a while now. Thanks.

-- Hal
___
general mailing list
general@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

[ofa-general] experience extended dick Nancy

[Esperanza Doran]

monumental erectile organ for Edwina
http://mewhing.com

___
general mailing list
general@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

[Fwd: [ofa-general] [PATCH] IB/core - remove redundant NULL pointer check in ib_mad_recv_done_handler()]

[Hal Rosenstock]

Hi Roland,

This is patch 1. Hope my mailer doesn't munge it.

Acked-by: Hal Rosenstock [EMAIL PROTECTED]

-- Hal

 Forwarded Message 
From: Ralph Campbell [EMAIL PROTECTED]
To: openib general@lists.openfabrics.org
Subject: [ofa-general] [PATCH] IB/core - remove redundant NULL pointer
check in ib_mad_recv_done_handler()
Date: Wed, 17 Oct 2007 18:06:42 -0700

In ib_mad_recv_done_handler(), the response pointer is checked for
NULL after allocating it.  It is then checked again in the local
process_mad() path but there is no possibility of it changing
in between.

Signed-off-by: Ralph Campbell [EMAIL PROTECTED]

diff --git a/drivers/infiniband/core/mad.c b/drivers/infiniband/core/mad.c
index 6f42877..f82900d 100644
--- a/drivers/infiniband/core/mad.c
+++ b/drivers/infiniband/core/mad.c
@@ -1931,15 +1931,6 @@ local:
if (port_priv-device-process_mad) {
int ret;
 
-   if (!response) {
-   printk(KERN_ERR PFX No memory for response MAD\n);
-   /*
-* Is it better to assume that
-* it wouldn't be processed ?
-*/
-   goto out;
-   }
-
ret = port_priv-device-process_mad(port_priv-device, 0,
 port_priv-port_num,
 wc, recv-grh,


___
general mailing list
general@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
___
general mailing list
general@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

[ofa-general] [Fwd: [PATCH V4] infiniband/core: Enable loopback of DR SMP responses from userspace]

[Hal Rosenstock]

Hi again Roland,

This is patch 2.

Acked-by: Hal Rosenstock [EMAIL PROTECTED]

-- Hal

 Forwarded Message 
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED], [EMAIL PROTECTED],
[EMAIL PROTECTED], [EMAIL PROTECTED], general@lists.openfabrics.org
Subject: [PATCH V4] infiniband/core: Enable loopback of DR SMP responses
from userspace
Date: Fri, 19 Oct 2007 12:41:28 -0500

  This patch [v4] replaces the [v3] patch; it's identicial other than
  the patch description has been updated to put back in the detailed
  patch description absent from the [v3] patch.

  The local loopback of an outgoing DR SMP response is limited to those
  that originate at the driver specific SMA implementation during the
  driver specific process_mad() function.  This patch enables a
  returning DR SMP originating in userspace (or elsewhere) to be
  delivered to the local managment stack.  In this specific  case
  the driver process_mad() function does not consume or process
  the MAD, so a reponse mad has not be created and the original
  MAD must manually be copied to the MAD buffer that is to be handed
  off to the local agent.

  For consistent bahavior on top of iPath hardware, a subsequent patch
  to be submitted by Ralph Campbell to update process_mad() return values
  is required.

  Thanks, Steve

Signed-off-by: Steve Welch [EMAIL PROTECTED]
---
 drivers/infiniband/core/mad.c |6 +++---
 drivers/infiniband/core/smi.h |   18 +-
 2 files changed, 20 insertions(+), 4 deletions(-)

diff --git a/drivers/infiniband/core/mad.c b/drivers/infiniband/core/mad.c
index 6f42877..98148d6 100644
--- a/drivers/infiniband/core/mad.c
+++ b/drivers/infiniband/core/mad.c
@@ -701,7 +701,8 @@ static int handle_outgoing_dr_smp(struct 
ib_mad_agent_private *mad_agent_priv,
}
 
/* Check to post send on QP or process locally */
-   if (smi_check_local_smp(smp, device) == IB_SMI_DISCARD)
+   if (smi_check_local_smp(smp, device) == IB_SMI_DISCARD 
+   smi_check_local_returning_smp(smp, device) == IB_SMI_DISCARD)
goto out;
 
local = kmalloc(sizeof *local, GFP_ATOMIC);
@@ -752,8 +753,7 @@ static int handle_outgoing_dr_smp(struct 
ib_mad_agent_private *mad_agent_priv,
port_priv = ib_get_mad_port(mad_agent_priv-agent.device,
mad_agent_priv-agent.port_num);
if (port_priv) {
-   mad_priv-mad.mad.mad_hdr.tid =
-   ((struct ib_mad *)smp)-mad_hdr.tid;
+   memcpy(mad_priv-mad.mad, smp, sizeof(struct ib_mad));
recv_mad_agent = find_mad_agent(port_priv,
mad_priv-mad.mad);
}
diff --git a/drivers/infiniband/core/smi.h b/drivers/infiniband/core/smi.h
index 1cfc298..aff96ba 100644
--- a/drivers/infiniband/core/smi.h
+++ b/drivers/infiniband/core/smi.h
@@ -59,7 +59,8 @@ extern enum smi_action smi_handle_dr_smp_send(struct ib_smp 
*smp,
  u8 node_type, int port_num);
 
 /*
- * Return 1 if the SMP should be handled by the local SMA/SM via process_mad
+ * Return IB_SMI_HANDLE if the SMP should be handled by the local SMA/SM
+ * via process_mad
  */
 static inline enum smi_action smi_check_local_smp(struct ib_smp *smp,
  struct ib_device *device)
@@ -71,4 +72,19 @@ static inline enum smi_action smi_check_local_smp(struct 
ib_smp *smp,
(smp-hop_ptr == smp-hop_cnt + 1)) ?
IB_SMI_HANDLE : IB_SMI_DISCARD);
 }
+
+/*
+ * Return IB_SMI_HANDLE if the SMP should be handled by the local SMA/SM
+ * via process_mad
+ */
+static inline enum smi_action smi_check_local_returning_smp(struct ib_smp *smp,
+  struct ib_device *device)
+{
+   /* C14-13:3 -- We're at the end of the DR segment of path */
+   /* C14-13:4 -- Hop Pointer == 0 - give to SM */
+   return ((device-process_mad 
+   ib_get_smp_direction(smp) 
+   !smp-hop_ptr) ? IB_SMI_HANDLE : IB_SMI_DISCARD);
+}
+
 #endif /* __SMI_H_ */
___
general mailing list
general@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

Re: [ofa-general] OpenFabrics Developer's Summit: tentative agenda

[Johann George]

Jeff,

 Is there any intent for HP MPI or Intel MPI to speak?  I would be  
 interested to hear what they have to say (e.g., feedback on the OFED  
 stack vs. other network stacks and other status update kinds of  
 things).

We considered it but given the time constraints, thought we should
wait until Sonoma.  Priority was given to OpenMPI and MVAPICH since
they are being shipped as part of OFED.  Still, as you point out,
getting feedback on their view of OFED vs. other networking stacks
could be valuable.

Johann
___
general mailing list
general@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

RE: [ofa-general] [RFP] support for iWARP requirement - active connect side MUST send first FPDU

[Glenn Grundstrom]

  That is what I've been trying to push.  Both MVAPICH2 and 
 OMPI have been 
  open to adjusting their transports to adhere to this requirement.
  
  I wouldn't mind implementing something to enforce this in 
 the IWCM or 
  the iWARP drivers IF there was a clean way to do it.  So far there 
  hasn't been a clean way proposed.
 
 Why can't either uDAPL or iW CM always do a send from the active to 
 passive side that gets stripped off?  From the active side, the first 
 send is always posted before any user sends, and if necessary, a user 
 send can be queued by software to avoid a QP/CQ overrun.  The 
 completion 
 can simply be eaten by software.  On the passive side, you have a 
 similar process for receiving the data.

This is similar to an option in the NetEffect driver.  A zero byte
RDMA write is sent from the active side and accounted for on the
passive side.  This can be turned on and off by compile and module
options for compatibility.

I second Sean's question - why can't uDAPL or the iw_cm do this?

 
 (Yes this adds wire protocol, which requires both sides to 
 support it.)
 
 - Sean
 
___
general mailing list
general@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

RE: [ofa-general] [RFP] support for iWARP requirement - activeconnect side MUST send first FPDU

[Kanevsky, Arkady]

This is still a protocol and should be defined by IETF not OFA.
But if we get agreement from all iWARP vendors this will be a good step.
If we can not get agreement on it on reflector lets do
it at SC'07 OFA dev. conference.

Arkady Kanevsky   email: [EMAIL PROTECTED]
Network Appliance Inc.   phone: 781-768-5395
1601 Trapelo Rd. - Suite 16.Fax: 781-895-1195
Waltham, MA 02451   central phone: 781-768-5300
 

 -Original Message-
 From: Glenn Grundstrom [mailto:[EMAIL PROTECTED] 
 Sent: Tuesday, October 23, 2007 9:02 PM
 To: Sean Hefty; Steve Wise
 Cc: Roland Dreier; [EMAIL PROTECTED]; 
 OpenFabrics General
 Subject: RE: [ofa-general] [RFP] support for iWARP 
 requirement - activeconnect side MUST send first FPDU
 
   That is what I've been trying to push.  Both MVAPICH2 and
  OMPI have been
   open to adjusting their transports to adhere to this requirement.
   
   I wouldn't mind implementing something to enforce this in
  the IWCM or
   the iWARP drivers IF there was a clean way to do it.  So 
 far there 
   hasn't been a clean way proposed.
  
  Why can't either uDAPL or iW CM always do a send from the active to 
  passive side that gets stripped off?  From the active side, 
 the first 
  send is always posted before any user sends, and if 
 necessary, a user 
  send can be queued by software to avoid a QP/CQ overrun.  The 
  completion can simply be eaten by software.  On the passive 
 side, you 
  have a similar process for receiving the data.
 
 This is similar to an option in the NetEffect driver.  A zero 
 byte RDMA write is sent from the active side and accounted 
 for on the passive side.  This can be turned on and off by 
 compile and module options for compatibility.
 
 I second Sean's question - why can't uDAPL or the iw_cm do this?
 
  
  (Yes this adds wire protocol, which requires both sides to support 
  it.)
  
  - Sean
  
 ___
 general mailing list
 general@lists.openfabrics.org
 http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general
 
 To unsubscribe, please visit 
 http://openib.org/mailman/listinfo/openib-general
 
___
general mailing list
general@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

RE: [ofa-general] [RFP] support for iWARP requirement - activeconnectside MUST send first FPDU

[Felix Marti]

 -Original Message-
 From: [EMAIL PROTECTED] [mailto:general-
 [EMAIL PROTECTED] On Behalf Of Kanevsky, Arkady
 Sent: Tuesday, October 23, 2007 6:26 PM
 To: Glenn Grundstrom; Sean Hefty; Steve Wise
 Cc: Roland Dreier; [EMAIL PROTECTED]; OpenFabrics
 General
 Subject: RE: [ofa-general] [RFP] support for iWARP requirement -
 activeconnectside MUST send first FPDU
 
 This is still a protocol and should be defined by IETF not OFA.
 But if we get agreement from all iWARP vendors this will be a good
 step.
[felix] This will not work with a Chelsio RNIC which follows the IETF
specification by a) not issuing a 0B RDMA Write to the wire and b)
silently consuming an incoming 0B write. Therefore 0B RDMA Writes cannot
be 'abused' for such a synchronization mechanism. I believe that the
mentioned apps adhering to the iWarp requirement do a 'send' from the
active side and only have the passive side issue RDMA ops once the
incoming send has been received. I would guess that following a similar
model is the best way to go and supported by all iWarp vendors
implementing the IETF spec.


 If we can not get agreement on it on reflector lets do
 it at SC'07 OFA dev. conference.
 
 Arkady Kanevsky   email: [EMAIL PROTECTED]
 Network Appliance Inc.   phone: 781-768-5395
 1601 Trapelo Rd. - Suite 16.Fax: 781-895-1195
 Waltham, MA 02451   central phone: 781-768-5300
 
 
  -Original Message-
  From: Glenn Grundstrom [mailto:[EMAIL PROTECTED]
  Sent: Tuesday, October 23, 2007 9:02 PM
  To: Sean Hefty; Steve Wise
  Cc: Roland Dreier; [EMAIL PROTECTED];
  OpenFabrics General
  Subject: RE: [ofa-general] [RFP] support for iWARP
  requirement - activeconnect side MUST send first FPDU
 
That is what I've been trying to push.  Both MVAPICH2 and
   OMPI have been
open to adjusting their transports to adhere to this
requirement.
   
I wouldn't mind implementing something to enforce this in
   the IWCM or
the iWARP drivers IF there was a clean way to do it.  So
  far there
hasn't been a clean way proposed.
  
   Why can't either uDAPL or iW CM always do a send from the active
to
   passive side that gets stripped off?  From the active side,
  the first
   send is always posted before any user sends, and if
  necessary, a user
   send can be queued by software to avoid a QP/CQ overrun.  The
   completion can simply be eaten by software.  On the passive
  side, you
   have a similar process for receiving the data.
 
  This is similar to an option in the NetEffect driver.  A zero
  byte RDMA write is sent from the active side and accounted
  for on the passive side.  This can be turned on and off by
  compile and module options for compatibility.
 
  I second Sean's question - why can't uDAPL or the iw_cm do this?
 
  
   (Yes this adds wire protocol, which requires both sides to support
   it.)
  
   - Sean
  
  ___
  general mailing list
  general@lists.openfabrics.org
  http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general
 
  To unsubscribe, please visit
  http://openib.org/mailman/listinfo/openib-general
 
 ___
 general mailing list
 general@lists.openfabrics.org
 http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general
 
 To unsubscribe, please visit
http://openib.org/mailman/listinfo/openib-
 general
___
general mailing list
general@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

[ofa-general] Ado6e Acro6at PR0, New Vista/XP Edition 79$, Save 599.95$ 0ff Retai|

[Old Ward]

adobe4less . com
___
general mailing list
general@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

[ofa-general] Ado6e Acro6at PR0, New Vista/XP Edition 79$, Save 599.95$ 0ff Retai|

[Corey Armstrong]

adobe4less . com
___
general mailing list
general@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

[Fwd: [Fwd: [ofa-general] [PATCH] IB/core - remove redundant NULL pointer check in ib_mad_recv_done_handler()]]

[Hal Rosenstock]

Actually to be complete, this one is:

Acked-by: Ralph Campbell [EMAIL PROTECTED]
Acked-by: Hal Rosenstock [EMAIL PROTECTED]

 Forwarded Message 
From: Hal Rosenstock [EMAIL PROTECTED]
To: Roland Dreier [EMAIL PROTECTED]
Cc: general@lists.openfabrics.org, Ralph Campbell
[EMAIL PROTECTED]
Subject: [Fwd: [ofa-general] [PATCH] IB/core - remove redundant NULL
pointer check in ib_mad_recv_done_handler()]
Date: Tue, 23 Oct 2007 15:04:15 -0700
Hi Roland,

This is patch 1. Hope my mailer doesn't munge it.

Acked-by: Hal Rosenstock [EMAIL PROTECTED]

-- Hal

 Forwarded Message 
From: Ralph Campbell [EMAIL PROTECTED]
To: openib general@lists.openfabrics.org
Subject: [ofa-general] [PATCH] IB/core - remove redundant NULL pointer
check in ib_mad_recv_done_handler()
Date: Wed, 17 Oct 2007 18:06:42 -0700

In ib_mad_recv_done_handler(), the response pointer is checked for
NULL after allocating it.  It is then checked again in the local
process_mad() path but there is no possibility of it changing
in between.

Signed-off-by: Ralph Campbell [EMAIL PROTECTED]

diff --git a/drivers/infiniband/core/mad.c b/drivers/infiniband/core/mad.c
index 6f42877..f82900d 100644
--- a/drivers/infiniband/core/mad.c
+++ b/drivers/infiniband/core/mad.c
@@ -1931,15 +1931,6 @@ local:
if (port_priv-device-process_mad) {
int ret;
 
-   if (!response) {
-   printk(KERN_ERR PFX No memory for response MAD\n);
-   /*
-* Is it better to assume that
-* it wouldn't be processed ?
-*/
-   goto out;
-   }
-
ret = port_priv-device-process_mad(port_priv-device, 0,
 port_priv-port_num,
 wc, recv-grh,


___
general mailing list
general@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
___
general mailing list
general@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

Re: [ofa-general] [RFP] support for iWARP requirement - active connect side MUST send first FPDU

[Tom Tucker]

Michael Krause wrote:

At 01:17 PM 10/23/2007, Steve Wise wrote:



Sean Hefty wrote:
There has been much discussion on a private thread regarding bug 
#735 - dapltest performance tests don't adhere to iWARP standard 
that needs to move to the general list.

This bug would be better titled iWarp cannot support uDAPL API. :)
Seriously, the iWarp and uDAPL specs conflict.  One needs to change.

Can someone come up with a solution, possibly in iWARP CM, that 
will work and insure interoperability between iWARP devices?
I thought the restriction was there to support switching between 
streaming and rdma mode.  If a connection only uses rdma mode, is 
the restriction really needed at all?


Yes because all iWARP connections start out as TCP streaming mode 
connections, and the MPA startup messages are sent in streaming mode. 
Then the connection is  transitioned into FPDU (Framed PDU) mode 
using the MPA protocol.


Correct.  The IETF was very clear on these requirements (significant 
debate occurred over at least 12-18 months) and there is unlikely to 
be any traction in changing the iWARP specifications to provide 
another mechanism.  Best to provide API that detect which semantics 
are required and then if the application cannot adjust, then it cannot 
use the iWARP semantics.
First let me apologize in advance, but that is simply not a workable 
solution for the customer. I'm not taking anything away from the efforts 
of those involved with the definition of the MPA protocol, however, 
unfortunately that protracted debate occurred 2-3 years in advance of a 
deployed solution. The duration of the debate doesn't overcome the 
absence of practical perspective.


There are now multiple implementations, the customers of which are 
complaining about the cost of the compromises made. We now have the 
benefit of hindsight and in my option should rev the MPA protocol. After 
all, that's why the number is there in the header -- right? It may be 
that those involved with the original debate have no interest in 
revisiting it, but IMO that is irrelevant. There are now new companies 
involved that implemented RDDP, have customers using it, and have a 
sustaining (both interpretations intended) interest in making RDDP 
better. I, for one, would encourage them to do so.


Protocols are not immutable, unless they're dead.


BTW, if one uses the SDP port mapper protocol (see the IETF SDP 
specification), one can detect from the start that RDMA is being used 
and one could start in RDMA mode sans the MPA requirement.   The SDP 
port mapper protocol also enables one to apply various other policies 
such as determining whether the application / remote node session 
should be allowed to run over RDMA or not - simple point of control 
for management.



Really? What about CRC, Markers and Private Data?

Mike


___
general mailing list
general@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general


___
general mailing list
general@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

Re: [ofa-general] [RFP] support for iWARP requirement - activeconnectside MUST send first FPDU

[Tom Tucker]

Felix Marti wrote:
  

-Original Message-
From: [EMAIL PROTECTED] [mailto:general-
[EMAIL PROTECTED] On Behalf Of Kanevsky, Arkady
Sent: Tuesday, October 23, 2007 6:26 PM
To: Glenn Grundstrom; Sean Hefty; Steve Wise
Cc: Roland Dreier; [EMAIL PROTECTED]; OpenFabrics
General
Subject: RE: [ofa-general] [RFP] support for iWARP requirement -
activeconnectside MUST send first FPDU

This is still a protocol and should be defined by IETF not OFA.
But if we get agreement from all iWARP vendors this will be a good
step.


[felix] This will not work with a Chelsio RNIC which follows the IETF
specification by a) not issuing a 0B RDMA Write to the wire and b)
silently consuming an incoming 0B write. Therefore 0B RDMA Writes cannot
be 'abused' for such a synchronization mechanism. I believe that the
mentioned apps adhering to the iWarp requirement do a 'send' from the
active side and only have the passive side issue RDMA ops once the
incoming send has been received. I would guess that following a similar
model is the best way to go and supported by all iWarp vendors
implementing the IETF spec.

  
IMO, the iWARP vendors _must_ get together and work on MPA '2'. 
Standardizing FPDU 'abuse' might be a good place to start, but it needs 
to be fixed to support peer-to-peer going forward.


In the mean-time, imperfectly hiding the issue in the Firmware, uDAPL, 
the iWARP CM or anywhere else except the application seems to me to be 
the only customer friendly solution.
  

If we can not get agreement on it on reflector lets do
it at SC'07 OFA dev. conference.

Arkady Kanevsky   email: [EMAIL PROTECTED]
Network Appliance Inc.   phone: 781-768-5395
1601 Trapelo Rd. - Suite 16.Fax: 781-895-1195
Waltham, MA 02451   central phone: 781-768-5300




-Original Message-
From: Glenn Grundstrom [mailto:[EMAIL PROTECTED]
Sent: Tuesday, October 23, 2007 9:02 PM
To: Sean Hefty; Steve Wise
Cc: Roland Dreier; [EMAIL PROTECTED];
OpenFabrics General
Subject: RE: [ofa-general] [RFP] support for iWARP
requirement - activeconnect side MUST send first FPDU

  

That is what I've been trying to push.  Both MVAPICH2 and
  

OMPI have been


open to adjusting their transports to adhere to this
  

requirement.
  

I wouldn't mind implementing something to enforce this in
  

the IWCM or


the iWARP drivers IF there was a clean way to do it.  So
  

far there
  

hasn't been a clean way proposed.
  

Why can't either uDAPL or iW CM always do a send from the active


to
  

passive side that gets stripped off?  From the active side,


the first
  

send is always posted before any user sends, and if


necessary, a user
  

send can be queued by software to avoid a QP/CQ overrun.  The
completion can simply be eaten by software.  On the passive


side, you
  

have a similar process for receiving the data.


This is similar to an option in the NetEffect driver.  A zero
byte RDMA write is sent from the active side and accounted
for on the passive side.  This can be turned on and off by
compile and module options for compatibility.

I second Sean's question - why can't uDAPL or the iw_cm do this?

  

(Yes this adds wire protocol, which requires both sides to support
it.)

- Sean



___
general mailing list
general@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general

To unsubscribe, please visit
http://openib.org/mailman/listinfo/openib-general

  

___
general mailing list
general@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general

To unsubscribe, please visit


http://openib.org/mailman/listinfo/openib-
  

general


___
general mailing list
general@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
  


___
general mailing list
general@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

RE: [ofa-general] [RFP] support for iWARP requirement - activeconnectside MUST send first FPDU

[Felix Marti]

 -Original Message-
 From: Tom Tucker [mailto:[EMAIL PROTECTED]
 Sent: Tuesday, October 23, 2007 9:32 PM
 To: Felix Marti
 Cc: Kanevsky, Arkady; Glenn Grundstrom; Sean Hefty; Steve Wise; Roland
 Dreier; [EMAIL PROTECTED]; OpenFabrics General
 Subject: Re: [ofa-general] [RFP] support for iWARP requirement -
 activeconnectside MUST send first FPDU
 
 Felix Marti wrote:
 
  -Original Message-
  From: [EMAIL PROTECTED] [mailto:general-
  [EMAIL PROTECTED] On Behalf Of Kanevsky, Arkady
  Sent: Tuesday, October 23, 2007 6:26 PM
  To: Glenn Grundstrom; Sean Hefty; Steve Wise
  Cc: Roland Dreier; [EMAIL PROTECTED]; OpenFabrics
  General
  Subject: RE: [ofa-general] [RFP] support for iWARP requirement -
  activeconnectside MUST send first FPDU
 
  This is still a protocol and should be defined by IETF not OFA.
  But if we get agreement from all iWARP vendors this will be a good
  step.
 
  [felix] This will not work with a Chelsio RNIC which follows the
IETF
  specification by a) not issuing a 0B RDMA Write to the wire and b)
  silently consuming an incoming 0B write. Therefore 0B RDMA Writes
 cannot
  be 'abused' for such a synchronization mechanism. I believe that the
  mentioned apps adhering to the iWarp requirement do a 'send' from
the
  active side and only have the passive side issue RDMA ops once the
  incoming send has been received. I would guess that following a
 similar
  model is the best way to go and supported by all iWarp vendors
  implementing the IETF spec.
 
 
 IMO, the iWARP vendors _must_ get together and work on MPA '2'.
 Standardizing FPDU 'abuse' might be a good place to start, but it
needs
 to be fixed to support peer-to-peer going forward.
 
 In the mean-time, imperfectly hiding the issue in the Firmware, uDAPL,
 the iWARP CM or anywhere else except the application seems to me to be
 the only customer friendly solution.

[felix] While I'm not against trying to hide the connection migration
details somewhere below the ULP, I'm not convinced that the issue is as
severe as you make it to be and I would not press to have the issue
resolved in a matter that requires a new MPA version. In fact, the
different rdma transports (and maybe even different versions of the same
transport (in the case of IB)) provide different features and I would
assume that ULPs will eventually code to these features and must thus be
aware of the underlying transport protocol. In that bigger picture, the
connection migration issue at hand seems fairly trivial to solve even if
it requires an ULP change... 
 
 
  If we can not get agreement on it on reflector lets do
  it at SC'07 OFA dev. conference.
 
  Arkady Kanevsky   email: [EMAIL PROTECTED]
  Network Appliance Inc.   phone: 781-768-5395
  1601 Trapelo Rd. - Suite 16.Fax: 781-895-1195
  Waltham, MA 02451   central phone: 781-768-5300
 
 
 
  -Original Message-
  From: Glenn Grundstrom [mailto:[EMAIL PROTECTED]
  Sent: Tuesday, October 23, 2007 9:02 PM
  To: Sean Hefty; Steve Wise
  Cc: Roland Dreier; [EMAIL PROTECTED];
  OpenFabrics General
  Subject: RE: [ofa-general] [RFP] support for iWARP
  requirement - activeconnect side MUST send first FPDU
 
 
  That is what I've been trying to push.  Both MVAPICH2 and
 
  OMPI have been
 
  open to adjusting their transports to adhere to this
 
  requirement.
 
  I wouldn't mind implementing something to enforce this in
 
  the IWCM or
 
  the iWARP drivers IF there was a clean way to do it.  So
 
  far there
 
  hasn't been a clean way proposed.
 
  Why can't either uDAPL or iW CM always do a send from the active
 
  to
 
  passive side that gets stripped off?  From the active side,
 
  the first
 
  send is always posted before any user sends, and if
 
  necessary, a user
 
  send can be queued by software to avoid a QP/CQ overrun.  The
  completion can simply be eaten by software.  On the passive
 
  side, you
 
  have a similar process for receiving the data.
 
  This is similar to an option in the NetEffect driver.  A zero
  byte RDMA write is sent from the active side and accounted
  for on the passive side.  This can be turned on and off by
  compile and module options for compatibility.
 
  I second Sean's question - why can't uDAPL or the iw_cm do this?
 
 
  (Yes this adds wire protocol, which requires both sides to
support
  it.)
 
  - Sean
 
 
  ___
  general mailing list
  general@lists.openfabrics.org
  http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general
 
  To unsubscribe, please visit
  http://openib.org/mailman/listinfo/openib-general
 
 
  ___
  general mailing list
  general@lists.openfabrics.org
  http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general
 
  To unsubscribe, please visit
 
  http://openib.org/mailman/listinfo/openib-
 
  general
 
  ___
  general mailing list