[ofa-general] ofa_1_5_kernel 20090906-0200 daily build status

2009-09-06 Thread Vladimir Sokolovsky (Mellanox)
This email was generated automatically, please do not reply


git_url: git://git.openfabrics.org/ofed_1_5/linux-2.6.git
git_branch: ofed_kernel_1_5

Common build parameters: 

Passed:
Passed on i686 with linux-2.6.18
Passed on i686 with linux-2.6.19
Passed on i686 with linux-2.6.21.1
Passed on i686 with linux-2.6.26
Passed on i686 with linux-2.6.24
Passed on i686 with linux-2.6.22
Passed on i686 with linux-2.6.27
Passed on x86_64 with linux-2.6.16.60-0.21-smp
Passed on x86_64 with linux-2.6.18
Passed on x86_64 with linux-2.6.18-128.el5
Passed on x86_64 with linux-2.6.19
Passed on x86_64 with linux-2.6.18-93.el5
Passed on x86_64 with linux-2.6.21.1
Passed on x86_64 with linux-2.6.20
Passed on x86_64 with linux-2.6.22
Passed on x86_64 with linux-2.6.26
Passed on x86_64 with linux-2.6.24
Passed on x86_64 with linux-2.6.25
Passed on x86_64 with linux-2.6.27
Passed on ia64 with linux-2.6.18
Passed on ia64 with linux-2.6.19
Passed on ia64 with linux-2.6.21.1
Passed on ia64 with linux-2.6.22
Passed on ia64 with linux-2.6.24
Passed on ia64 with linux-2.6.23
Passed on ia64 with linux-2.6.25
Passed on ia64 with linux-2.6.26
Passed on ppc64 with linux-2.6.18
Passed on ppc64 with linux-2.6.19

Failed:
Build failed on x86_64 with linux-2.6.9-67.ELsmp
Log:
/home/vlad/tmp/ofa_1_5_kernel-20090906-0200_linux-2.6.9-67.ELsmp_x86_64_check/net/rds/tcp_listen.c:71:
 error: 'struct inet_sock' has no member named 'daddr'
/home/vlad/tmp/ofa_1_5_kernel-20090906-0200_linux-2.6.9-67.ELsmp_x86_64_check/net/rds/tcp_listen.c:71:
 error: 'struct inet_sock' has no member named 'dport'
/home/vlad/tmp/ofa_1_5_kernel-20090906-0200_linux-2.6.9-67.ELsmp_x86_64_check/net/rds/tcp_listen.c:73:
 error: 'struct inet_sock' has no member named 'saddr'
/home/vlad/tmp/ofa_1_5_kernel-20090906-0200_linux-2.6.9-67.ELsmp_x86_64_check/net/rds/tcp_listen.c:73:
 error: 'struct inet_sock' has no member named 'daddr'
make[3]: *** 
[/home/vlad/tmp/ofa_1_5_kernel-20090906-0200_linux-2.6.9-67.ELsmp_x86_64_check/net/rds/tcp_listen.o]
 Error 1
make[2]: *** 
[/home/vlad/tmp/ofa_1_5_kernel-20090906-0200_linux-2.6.9-67.ELsmp_x86_64_check/net/rds]
 Error 2
make[1]: *** 
[_module_/home/vlad/tmp/ofa_1_5_kernel-20090906-0200_linux-2.6.9-67.ELsmp_x86_64_check]
 Error 2
make[1]: Leaving directory `/home/vlad/kernel.org/x86_64/linux-2.6.9-67.ELsmp'
make: *** [kernel] Error 2
--
Build failed on x86_64 with linux-2.6.9-78.ELsmp
Log:
/home/vlad/tmp/ofa_1_5_kernel-20090906-0200_linux-2.6.9-78.ELsmp_x86_64_check/net/rds/tcp_listen.c:71:
 error: 'struct inet_sock' has no member named 'daddr'
/home/vlad/tmp/ofa_1_5_kernel-20090906-0200_linux-2.6.9-78.ELsmp_x86_64_check/net/rds/tcp_listen.c:71:
 error: 'struct inet_sock' has no member named 'dport'
/home/vlad/tmp/ofa_1_5_kernel-20090906-0200_linux-2.6.9-78.ELsmp_x86_64_check/net/rds/tcp_listen.c:73:
 error: 'struct inet_sock' has no member named 'saddr'
/home/vlad/tmp/ofa_1_5_kernel-20090906-0200_linux-2.6.9-78.ELsmp_x86_64_check/net/rds/tcp_listen.c:73:
 error: 'struct inet_sock' has no member named 'daddr'
make[3]: *** 
[/home/vlad/tmp/ofa_1_5_kernel-20090906-0200_linux-2.6.9-78.ELsmp_x86_64_check/net/rds/tcp_listen.o]
 Error 1
make[2]: *** 
[/home/vlad/tmp/ofa_1_5_kernel-20090906-0200_linux-2.6.9-78.ELsmp_x86_64_check/net/rds]
 Error 2
make[1]: *** 
[_module_/home/vlad/tmp/ofa_1_5_kernel-20090906-0200_linux-2.6.9-78.ELsmp_x86_64_check]
 Error 2
make[1]: Leaving directory `/home/vlad/kernel.org/x86_64/linux-2.6.9-78.ELsmp'
make: *** [kernel] Error 2
--
___
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 1.5-alpha 4 and RHEL 5.3 GA

2009-09-06 Thread Tziporet Koren
Vlad/jack
What should be fixed?

tziporet

-Original Message-
From: general-boun...@lists.openfabrics.org 
[mailto:general-boun...@lists.openfabrics.org] On Behalf Of Higor Aparecido 
Vieira Alves
Sent: Friday, August 28, 2009 6:38 PM
To: OpenIB
Subject: [ofa-general] OFED 1.5-alpha 4 and RHEL 5.3 GA

Hi Guys, 

I tried build OFED1.5 on RHEL 5.3 GA and got an error to build
ofa_kernel. Build log attached.


Regards, 
-- 
Higor Aparecido Vieira Alves
Software Engineer
Linux Technology Center 
IBM Systems  Technology Group
___
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] ibutils: ibdiagnet -r Dead end errors

2009-09-06 Thread Yevgeny Kliteynik

akep...@sgi.com wrote:
On a cluster running sles11 and OFED 1.4, we recently started seeing errors 
like this:


# ibdiagnet -r
.
-I-
-I- Verifying all CA to CA paths ...
-E- Unassigned LFT for lid:1 Dead end at:S080069004057/U1
-E- Fail to find a path from:r1i0n9/U1/1 to:r1lead/U1/1
...


But the forwarding tables (obtained with dump_lfts.sh, and smpdump) 
are correct. The problem turned out to be that the string -lft was 
being interpreted as a port number, resulting in an off-by-one error. 


The following fixed it for us.

Signed-off-by: Arthur Kepner akep...@sgi.com
---



Thanks, applied.

-- Yevgeny
___
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] ibdm/ibnl/* ibnl definition files for Sun IB QDR products

2009-09-06 Thread Yevgeny Kliteynik

Lars Paul Huse wrote:

ibnl definition files for Sun IB QDR products:
- 48 port QNEM
- 36 port Switch
- 72 port Switch
- 648 port Switch

Signed-off-by: Lars Paul Huse lars.paul.h...@sun.com

  


Thanks, applied.

-- Yevgeny

___
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 0/6] ibutils: Build fixes for FC11

2009-09-06 Thread Yevgeny Kliteynik

Sebastien,

sebastien dugue wrote:

  Hi,

  here are some fixes I had to apply in order to be able to build under FC11
due to some changes in the toolchain.

  Sebastien.



Thanks. I've checked in all but patch 3/6.
See details in the mail.

-- Yevgeny
___
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 1/6] ibutils/ibdm: Fix 'invalid conversion from const char* to char*' build error

2009-09-06 Thread Yevgeny Kliteynik

sebastien dugue wrote:

  This occurs under FC11 with gcc 4.4.0-4.

Signed-off-by: Sebastien Dugue sebastien.du...@bull.net



Applied, thanks.

-- Yevgeny
___
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 2/6] ibutils/ibdm: Add -fPIC to libreplace build

2009-09-06 Thread Yevgeny Kliteynik

sebastien dugue wrote:

  This allows to build under FC11. Otherwise, building shared libraries using
libreplace results in the following error:

.../ibutils/ibdm/replace/libreplace.a(regex.o): relocation R_X86_64_32S against
`a local symbol' can not be used when making a shared object;
recompile with -fPIC
.../ibutils/ibdm/replace/libreplace.a: could not read symbols: Bad value

Signed-off-by: Sebastien Dugue sebastien.du...@bull.net


Applied, thanks.

-- Yevgeny
___
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 4/6] ibutils: Add libibsysapi.so to the spec file

2009-09-06 Thread Yevgeny Kliteynik

sebastien dugue wrote:



Signed-off-by: Sebastien Dugue sebastien.du...@bull.net


Applied, thanks.

-- Yevgeny
___
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 5/6] ibutils: Allow parallel build

2009-09-06 Thread Yevgeny Kliteynik

sebastien dugue wrote:



Signed-off-by: Sebastien Dugue sebastien.du...@bull.net


Applied, thanks.

-- Yevgeny
___
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 6/6] ibutils: Fix libibsysapi build for old autotools

2009-09-06 Thread Yevgeny Kliteynik

sebastien dugue wrote:

Signed-off-by: Sebastien Dugue sebastien.du...@bull.net


Applied, thanks.

-- Yevgeny
___
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 3/6] ibutils/ibdm: Fix libibsysapi build

2009-09-06 Thread Yevgeny Kliteynik

Sebastien,

sebastien dugue wrote:

  Add libibdmcom linker path to allow build under FC11.

Signed-off-by: Sebastien Dugue sebastien.du...@bull.net
---
 ibdm/src/Makefile.am |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/ibdm/src/Makefile.am b/ibdm/src/Makefile.am
index 8b2f9ba..b763387 100644
--- a/ibdm/src/Makefile.am
+++ b/ibdm/src/Makefile.am
@@ -61,7 +61,7 @@ ibnlparse_SOURCES = test_ibnl_parser.cpp
 lib_LTLIBRARIES = libibsysapi.la
 libibsysapi_la_SOURCES = ibsysapi.cpp
 libibsysapi_la_LDFLAGS = -version-info 1:0:0
-libibsysapi_la_LIBADD = -libdmcom
+libibsysapi_la_LIBADD = -L../ibdm -libdmcom


This problem was already pointed out by Dale Purdy,
and I already fixed it based on his suggestion.
In fact, my fix is the same as yours :)

-- Yevgeny
___
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: [Scst-devel] [ofa-general] WinOF_2_0_5/SRP initiator: slow reads and eventually hangs

2009-09-06 Thread Bart Van Assche
On Fri, Sep 4, 2009 at 1:20 AM, Chris Worley worl...@gmail.com wrote:
 On Thu, Sep 3, 2009 at 11:38 AM, Chris Worleyworl...@gmail.com wrote:
  I've used a couple of initiators (different systems) w/ different
  OSes, w/ different IB cards (all QDR) and different IB stacks
  (built-in vs. OFED) and can repeat the problem in all but the
  RHEL5.2/OFED 1.4.1 target and initiator (but, if the initiator is
  WinOF and the target is RHEL5.2/OFED1.4.1, then the problem does
  repeat).

 Here's a twist: I used the Ubuntu initiator w/ one of the RHEL
 targets, and the RHEL initiator (same machine as was running WinOF
 from the beginning of this thread) w/ one of the Ubuntu targets: in
 both cases, the problem does not repeat.

 That makes it sound like OFED is the cure on either side of the
 connection, but does not explain the issue w/ WinOF (which does fail
 w/ either Ununtu or RHEL targets).

These results are strange. Regarding the Linux-only tests, I was
assuming failure of a single component (Ubuntu SRP initiator, OFED SRP
initiator, Ubuntu IB driver, OFED IB driver or SRP target), but for
each of these components there is at least one test that passes and at
least one test that fails. So either my assumption is wrong or one of
the above test results is not repeatable. Do you have the time to
repeat the Linux-only tests ?

Bart.
___
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: [Scst-devel] [ofa-general] WinOF_2_0_5/SRP initiator: slow reads and eventually hangs

2009-09-06 Thread Chris Worley
On Sun, Sep 6, 2009 at 3:17 PM, Bart Van Asschebart.vanass...@gmail.com wrote:
 On Fri, Sep 4, 2009 at 1:20 AM, Chris Worley worl...@gmail.com wrote:
 On Thu, Sep 3, 2009 at 11:38 AM, Chris Worleyworl...@gmail.com wrote:
  I've used a couple of initiators (different systems) w/ different
  OSes, w/ different IB cards (all QDR) and different IB stacks
  (built-in vs. OFED) and can repeat the problem in all but the
  RHEL5.2/OFED 1.4.1 target and initiator (but, if the initiator is
  WinOF and the target is RHEL5.2/OFED1.4.1, then the problem does
  repeat).

 Here's a twist: I used the Ubuntu initiator w/ one of the RHEL
 targets, and the RHEL initiator (same machine as was running WinOF
 from the beginning of this thread) w/ one of the Ubuntu targets: in
 both cases, the problem does not repeat.

 That makes it sound like OFED is the cure on either side of the
 connection, but does not explain the issue w/ WinOF (which does fail
 w/ either Ununtu or RHEL targets).

 These results are strange. Regarding the Linux-only tests, I was
 assuming failure of a single component (Ubuntu SRP initiator, OFED SRP
 initiator, Ubuntu IB driver, OFED IB driver or SRP target), but for
 each of these components there is at least one test that passes and at
 least one test that fails. So either my assumption is wrong or one of
 the above test results is not repeatable. Do you have the time to
 repeat the Linux-only tests ?

Last night I was rerunning the RHEL5.2 initiator w/ Ubuntu client, and
the problem repeated; now, I can't repeat the case where it didn't
fail.  Still, no errors, other than the eventual timeouts previously
shown; the target thinks all is fine, the initiator is stuck.

Chris

 Bart.

___
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: [Scst-devel] [ofa-general] WinOF_2_0_5/SRP initiator: slow reads and eventually hangs

2009-09-06 Thread Chris Worley
On Sun, Sep 6, 2009 at 3:36 PM, Chris Worleyworl...@gmail.com wrote:
 On Sun, Sep 6, 2009 at 3:17 PM, Bart Van Asschebart.vanass...@gmail.com 
 wrote:
 On Fri, Sep 4, 2009 at 1:20 AM, Chris Worley worl...@gmail.com wrote:
 On Thu, Sep 3, 2009 at 11:38 AM, Chris Worleyworl...@gmail.com wrote:
  I've used a couple of initiators (different systems) w/ different
  OSes, w/ different IB cards (all QDR) and different IB stacks
  (built-in vs. OFED) and can repeat the problem in all but the
  RHEL5.2/OFED 1.4.1 target and initiator (but, if the initiator is
  WinOF and the target is RHEL5.2/OFED1.4.1, then the problem does
  repeat).

 Here's a twist: I used the Ubuntu initiator w/ one of the RHEL
 targets, and the RHEL initiator (same machine as was running WinOF
 from the beginning of this thread) w/ one of the Ubuntu targets: in
 both cases, the problem does not repeat.

 That makes it sound like OFED is the cure on either side of the
 connection, but does not explain the issue w/ WinOF (which does fail
 w/ either Ununtu or RHEL targets).

 These results are strange. Regarding the Linux-only tests, I was
 assuming failure of a single component (Ubuntu SRP initiator, OFED SRP
 initiator, Ubuntu IB driver, OFED IB driver or SRP target), but for
 each of these components there is at least one test that passes and at
 least one test that fails. So either my assumption is wrong or one of
 the above test results is not repeatable. Do you have the time to
 repeat the Linux-only tests ?

 Last night I was rerunning the RHEL5.2 initiator w/ Ubuntu client, and
 the problem repeated; now, I can't repeat the case where it didn't
 fail.  Still, no errors, other than the eventual timeouts previously
 shown; the target thinks all is fine, the initiator is stuck.

... and I haven't had any success w/ Ubuntu target and initiator, 8.10 or 9.04.

Chris

 Chris

 Bart.


___
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 1.5-alpha 4 and RHEL 5.3 GA

2009-09-06 Thread Vladimir Sokolovsky

Tziporet Koren wrote:

Vlad/jack
What should be fixed?

tziporet

  


Hi,
I can't reproduce this failure with the latest build 
(OFED-1.5-20090905-0600) on RHEL5.3, 2.6.18-128.el5, ppc64.

Probably, the issue was fixed after 1.5-alpha4.

Regards,
Vladimir



-Original Message-
From: general-boun...@lists.openfabrics.org 
[mailto:general-boun...@lists.openfabrics.org] On Behalf Of Higor Aparecido 
Vieira Alves
Sent: Friday, August 28, 2009 6:38 PM
To: OpenIB
Subject: [ofa-general] OFED 1.5-alpha 4 and RHEL 5.3 GA

Hi Guys, 


I tried build OFED1.5 on RHEL 5.3 GA and got an error to build
ofa_kernel. Build log attached.


Regards, 
  



___
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] InfiniBand/RDMA merge plans for 2.6.32

2009-09-06 Thread Tziporet Koren

Roland Dreier wrote:

  What about RDMAoE?
  Patches were sent few weeks ago and it seems you ignore them.

Sorry, I should have mentioned that.

Yes, I have been ignoring the patches -- I want to get through XRC
first, 

We can help with XRC if this will expedite the RDMAoE. Will it?

Tziporet


  


___
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] opensm: use mgrp pointer in port mcm_info

2009-09-06 Thread Sasha Khapyorsky

Port needs to access multicast groups where it is joined to. Now it is
implemented by keeping list of list of mcm_info elements where MLID of
each multicast group is stored. Obviously this assumes single MGID to
MLID mapping model.

This patch changes this so that instead of MLID mcm_info stores pointer
to multicast group object (mgrp). Such model makes it possible to
have MGIDs to MLID compression.

Signed-off-by: Sasha Khapyorsky sas...@voltaire.com
---
 opensm/include/opensm/osm_mcm_info.h |   13 +++--
 opensm/include/opensm/osm_port.h |   13 +++--
 opensm/opensm/osm_drop_mgr.c |   10 +++---
 opensm/opensm/osm_mcm_info.c |8 
 opensm/opensm/osm_port.c |   10 +-
 opensm/opensm/osm_sm.c   |6 +++---
 6 files changed, 29 insertions(+), 31 deletions(-)

diff --git a/opensm/include/opensm/osm_mcm_info.h 
b/opensm/include/opensm/osm_mcm_info.h
index dec607f..62ae326 100644
--- a/opensm/include/opensm/osm_mcm_info.h
+++ b/opensm/include/opensm/osm_mcm_info.h
@@ -47,6 +47,7 @@
 #include iba/ib_types.h
 #include complib/cl_qlist.h
 #include opensm/osm_base.h
+#include opensm/osm_multicast.h
 
 #ifdef __cplusplus
 #  define BEGIN_C_DECLS extern C {
@@ -73,15 +74,15 @@ BEGIN_C_DECLS
 */
 typedef struct osm_mcm_info {
cl_list_item_t list_item;
-   ib_net16_t mlid;
+   osm_mgrp_t *mgrp;
 } osm_mcm_info_t;
 /*
 * FIELDS
 *  list_item
 *  Linkage structure for cl_qlist.  MUST BE FIRST MEMBER!
 *
-*  mlid
-*  MLID of this multicast group.
+*  mgrp
+*  The pointer to multicast group where this port is member of
 *
 * SEE ALSO
 */
@@ -95,11 +96,11 @@ typedef struct osm_mcm_info {
 *
 * SYNOPSIS
 */
-osm_mcm_info_t *osm_mcm_info_new(IN const ib_net16_t mlid);
+osm_mcm_info_t *osm_mcm_info_new(IN osm_mgrp_t *mgrp);
 /*
 * PARAMETERS
-*  mlid
-*  [in] MLID value for this multicast group.
+*  mgrp
+*  [in] the pointer to multicast group.
 *
 * RETURN VALUES
 *  Pointer to an initialized tree node.
diff --git a/opensm/include/opensm/osm_port.h b/opensm/include/opensm/osm_port.h
index 7079e74..0e0d3d2 100644
--- a/opensm/include/opensm/osm_port.h
+++ b/opensm/include/opensm/osm_port.h
@@ -65,6 +65,7 @@ BEGIN_C_DECLS
 */
 struct osm_port;
 struct osm_node;
+struct osm_mgrp;
 
 /h* OpenSM/Physical Port
 * NAME
@@ -1420,14 +1421,14 @@ osm_get_port_by_base_lid(IN const osm_subn_t * const 
p_subn,
 * SYNOPSIS
 */
 ib_api_status_t
-osm_port_add_mgrp(IN osm_port_t * const p_port, IN const ib_net16_t mlid);
+osm_port_add_mgrp(IN osm_port_t * const p_port, IN struct osm_mgrp *mgrp);
 /*
 * PARAMETERS
 *  p_port
 *  [in] Pointer to an osm_port_t object.
 *
-*  mlid
-*  [in] MLID of the multicast group.
+*  mgrp
+*  [in] Pointer to the multicast group.
 *
 * RETURN VALUES
 *  IB_SUCCESS
@@ -1449,14 +1450,14 @@ osm_port_add_mgrp(IN osm_port_t * const p_port, IN 
const ib_net16_t mlid);
 * SYNOPSIS
 */
 void
-osm_port_remove_mgrp(IN osm_port_t * const p_port, IN const ib_net16_t mlid);
+osm_port_remove_mgrp(IN osm_port_t * const p_port, IN struct osm_mgrp *mgrp);
 /*
 * PARAMETERS
 *  p_port
 *  [in] Pointer to an osm_port_t object.
 *
-*  mlid
-*  [in] MLID of the multicast group.
+*  mgrp
+*  [in] Pointer to the multicast group.
 *
 * RETURN VALUES
 *  None.
diff --git a/opensm/opensm/osm_drop_mgr.c b/opensm/opensm/osm_drop_mgr.c
index c9a4f33..4891bb8 100644
--- a/opensm/opensm/osm_drop_mgr.c
+++ b/opensm/opensm/osm_drop_mgr.c
@@ -158,7 +158,6 @@ static void drop_mgr_remove_port(osm_sm_t * sm, IN 
osm_port_t * p_port)
osm_port_t *p_port_check;
cl_qmap_t *p_sm_guid_tbl;
osm_mcm_info_t *p_mcm;
-   osm_mgrp_t *p_mgrp;
cl_ptr_vector_t *p_port_lid_tbl;
uint16_t min_lid_ho;
uint16_t max_lid_ho;
@@ -212,12 +211,9 @@ static void drop_mgr_remove_port(osm_sm_t * sm, IN 
osm_port_t * p_port)
 
p_mcm = (osm_mcm_info_t *) cl_qlist_remove_head(p_port-mcm_list);
while (p_mcm != (osm_mcm_info_t *) cl_qlist_end(p_port-mcm_list)) {
-   p_mgrp = osm_get_mgrp_by_mlid(sm-p_subn, p_mcm-mlid);
-   if (p_mgrp) {
-   osm_mgrp_delete_port(sm-p_subn, sm-p_log,
-p_mgrp, p_port-guid);
-   osm_mcm_info_delete((osm_mcm_info_t *) p_mcm);
-   }
+   osm_mgrp_delete_port(sm-p_subn, sm-p_log, p_mcm-mgrp,
+p_port-guid);
+   osm_mcm_info_delete(p_mcm);
p_mcm =
(osm_mcm_info_t *) cl_qlist_remove_head(p_port-mcm_list);
}
diff --git a/opensm/opensm/osm_mcm_info.c b/opensm/opensm/osm_mcm_info.c
index 0325a34..c07c70b 100644
--- a/opensm/opensm/osm_mcm_info.c
+++ b/opensm/opensm/osm_mcm_info.c

[ofa-general] [PATCH] opensm: use mgrp pointer as osm_sm_mcgrp_join/leave() parameter

2009-09-06 Thread Sasha Khapyorsky

Use mgrp pointer to multicast group instead of mlid as parameter for
osm_sm_mcgrp_join/leave() functions. This simplifies the current
implementation, makes those functions MLID independent and in this way
helps to implement MGID to MLID compression.

Signed-off-by: Sasha Khapyorsky sas...@voltaire.com
---
 opensm/include/opensm/osm_sm.h |   13 ---
 opensm/opensm/osm_sa_mcmember_record.c |8 +---
 opensm/opensm/osm_sm.c |   57 ++-
 3 files changed, 20 insertions(+), 58 deletions(-)

diff --git a/opensm/include/opensm/osm_sm.h b/opensm/include/opensm/osm_sm.h
index 152ecd7..0914a95 100644
--- a/opensm/include/opensm/osm_sm.h
+++ b/opensm/include/opensm/osm_sm.h
@@ -61,6 +61,7 @@
 #include opensm/osm_port.h
 #include opensm/osm_db.h
 #include opensm/osm_remote_sm.h
+#include opensm/osm_multicast.h
 
 #ifdef __cplusplus
 #  define BEGIN_C_DECLS extern C {
@@ -538,15 +539,15 @@ osm_resp_send(IN osm_sm_t * sm,
 */
 ib_api_status_t
 osm_sm_mcgrp_join(IN osm_sm_t * const p_sm,
- IN const ib_net16_t mlid,
+ IN osm_mgrp_t *mgrp,
  IN const ib_net64_t port_guid);
 /*
 * PARAMETERS
 *  p_sm
 *  [in] Pointer to an osm_sm_t object.
 *
-*  mlid
-*  [in] Multicast LID
+*  mgrp
+*  [in] Pointer to multicast group to join
 *
 *  port_guid
 *  [in] Port GUID to add to the group.
@@ -572,14 +573,14 @@ osm_sm_mcgrp_join(IN osm_sm_t * const p_sm,
 */
 ib_api_status_t
 osm_sm_mcgrp_leave(IN osm_sm_t * const p_sm,
-  IN const ib_net16_t mlid, IN const ib_net64_t port_guid);
+  IN osm_mgrp_t *mgrp, IN const ib_net64_t port_guid);
 /*
 * PARAMETERS
 *  p_sm
 *  [in] Pointer to an osm_sm_t object.
 *
-*  mlid
-*  [in] Multicast LID
+*  mgrp
+*  [in] Poniter to multicast group to leave
 *
 *  port_guid
 *  [in] Port GUID to remove from the group.
diff --git a/opensm/opensm/osm_sa_mcmember_record.c 
b/opensm/opensm/osm_sa_mcmember_record.c
index a9e0a3b..7f2bc34 100644
--- a/opensm/opensm/osm_sa_mcmember_record.c
+++ b/opensm/opensm/osm_sa_mcmember_record.c
@@ -1010,7 +1010,6 @@ static void mcmr_rcv_leave_mgrp(IN osm_sa_t * sa, IN 
osm_madw_t * p_madw)
ib_sa_mad_t *p_sa_mad;
ib_member_rec_t *p_recvd_mcmember_rec;
ib_member_rec_t mcmember_rec;
-   ib_net16_t mlid;
ib_net64_t portguid;
osm_mcm_port_t *p_mcm_port;
int removed;
@@ -1041,7 +1040,6 @@ static void mcmr_rcv_leave_mgrp(IN osm_sa_t * sa, IN 
osm_madw_t * p_madw)
goto Exit;
}
 
-   mlid = p_mgrp-mlid;
portguid = p_recvd_mcmember_rec-port_gid.unicast.interface_id;
 
/* check validity of the delete request o15-0.1.14 */
@@ -1074,7 +1072,7 @@ static void mcmr_rcv_leave_mgrp(IN osm_sa_t * sa, IN 
osm_madw_t * p_madw)
CL_PLOCK_RELEASE(sa-p_lock);
 
/* we can leave if port was deleted from MCG */
-   if (removed  osm_sm_mcgrp_leave(sa-sm, mlid, portguid))
+   if (removed  osm_sm_mcgrp_leave(sa-sm, p_mgrp, portguid))
OSM_LOG(sa-p_log, OSM_LOG_ERROR, ERR 1B09: 
osm_sm_mcgrp_leave failed\n);
 
@@ -1094,7 +1092,6 @@ static void mcmr_rcv_join_mgrp(IN osm_sa_t * sa, IN 
osm_madw_t * p_madw)
ib_sa_mad_t *p_sa_mad;
ib_member_rec_t *p_recvd_mcmember_rec;
ib_member_rec_t mcmember_rec;
-   ib_net16_t mlid;
osm_mcm_port_t *p_mcmr_port;
ib_net64_t portguid;
osm_port_t *p_port;
@@ -1217,7 +1214,6 @@ static void mcmr_rcv_join_mgrp(IN osm_sa_t * sa, IN 
osm_madw_t * p_madw)
is_new_group = 0;
 
CL_ASSERT(p_mgrp);
-   mlid = p_mgrp-mlid;
 
/*
 * o15-0.2.4: If SA supports UD multicast, then SA shall cause an
@@ -1302,7 +1298,7 @@ static void mcmr_rcv_join_mgrp(IN osm_sa_t * sa, IN 
osm_madw_t * p_madw)
CL_PLOCK_RELEASE(sa-p_lock);
 
/* do the actual routing (actually schedule the update) */
-   status = osm_sm_mcgrp_join(sa-sm, mlid,
+   status = osm_sm_mcgrp_join(sa-sm, p_mgrp,
   p_recvd_mcmember_rec-port_gid.unicast.
   interface_id);
 
diff --git a/opensm/opensm/osm_sm.c b/opensm/opensm/osm_sm.c
index 2794775..50aee91 100644
--- a/opensm/opensm/osm_sm.c
+++ b/opensm/opensm/osm_sm.c
@@ -467,10 +467,9 @@ static ib_api_status_t sm_mgrp_process(IN osm_sm_t * p_sm,
 
 /**
  **/
-ib_api_status_t osm_sm_mcgrp_join(IN osm_sm_t * p_sm, IN const ib_net16_t mlid,
+ib_api_status_t osm_sm_mcgrp_join(IN osm_sm_t * p_sm, IN osm_mgrp_t *mgrp,
  IN const ib_net64_t port_guid)
 {
-   osm_mgrp_t *p_mgrp;
osm_port_t *p_port;

[ofa-general] [PATCH] opensm: remove not used osm_mgrp_apply_func() function

2009-09-06 Thread Sasha Khapyorsky

Remove not used osm_mgrp_apply_func() function and associated types,
variables, etc..

Signed-off-by: Sasha Khapyorsky sas...@voltaire.com
---
 opensm/include/opensm/osm_multicast.h |   66 -
 opensm/opensm/osm_multicast.c |   38 ---
 2 files changed, 0 insertions(+), 104 deletions(-)

diff --git a/opensm/include/opensm/osm_multicast.h 
b/opensm/include/opensm/osm_multicast.h
index 9a47de5..eda447e 100644
--- a/opensm/include/opensm/osm_multicast.h
+++ b/opensm/include/opensm/osm_multicast.h
@@ -174,38 +174,6 @@ typedef struct osm_mgrp {
 * SEE ALSO
 */
 
-/f* OpenSM: Vendor API/osm_mgrp_func_t
-* NAME
-*  osm_mgrp_func_t
-*
-* DESCRIPTION
-*  Callback for the osm_mgrp_apply_func function.
-*  The callback function must not modify the tree linkage.
-*
-* SYNOPSIS
-*/
-typedef void (*osm_mgrp_func_t) (IN const osm_mgrp_t * const p_mgrp,
-IN const osm_mtree_node_t * const p_mtn,
-IN void *context);
-/*
-* PARAMETERS
-*  p_mgrp
-*  [in] Pointer to the multicast group object.
-*
-*  p_mtn
-*  [in] Pointer to the multicast tree node.
-*
-*  context
-*  [in] User context.
-*
-* RETURN VALUES
-*  None.
-*
-* NOTES
-*
-* SEE ALSO
-*/
-
 /f* OpenSM: Multicast Group/osm_mgrp_new
 * NAME
 *  osm_mgrp_new
@@ -456,39 +424,5 @@ osm_mgrp_delete_port(IN osm_subn_t * const p_subn,
 int osm_mgrp_remove_port(osm_subn_t *subn, osm_log_t *log, osm_mgrp_t *mgrp,
 osm_mcm_port_t *mcm, uint8_t join_state);
 
-/f* OpenSM: Multicast Group/osm_mgrp_apply_func
-* NAME
-*  osm_mgrp_apply_func
-*
-* DESCRIPTION
-*  Calls the specified function for each element in the tree.
-*  Elements are passed to the callback function in no particular order.
-*
-* SYNOPSIS
-*/
-void
-osm_mgrp_apply_func(const osm_mgrp_t * const p_mgrp,
-   osm_mgrp_func_t p_func, void *context);
-/*
-* PARAMETERS
-*  p_mgrp
-*  [in] Pointer to an osm_mgrp_t object.
-*
-*  p_func
-*  [in] Pointer to the users callback function.
-*
-*  context
-*  [in] User context passed to the callback function.
-*
-*
-* RETURN VALUES
-*  None.
-*
-* NOTES
-*
-* SEE ALSO
-*  Multicast Group
-*/
-
 END_C_DECLS
 #endif /* _OSM_MULTICAST_H_ */
diff --git a/opensm/opensm/osm_multicast.c b/opensm/opensm/osm_multicast.c
index d2733c4..4b4a6b0 100644
--- a/opensm/opensm/osm_multicast.c
+++ b/opensm/opensm/osm_multicast.c
@@ -260,41 +260,3 @@ boolean_t osm_mgrp_is_port_present(IN const osm_mgrp_t * 
p_mgrp,
*pp_mcm_port = NULL;
return FALSE;
 }
-
-/**
- **/
-static void mgrp_apply_func_sub(const osm_mgrp_t * p_mgrp,
-   const osm_mtree_node_t * p_mtn,
-   osm_mgrp_func_t p_func, void *context)
-{
-   uint8_t i = 0;
-   uint8_t max_children;
-   osm_mtree_node_t *p_child_mtn;
-
-   /* Call the user, then recurse. */
-   p_func(p_mgrp, p_mtn, context);
-
-   max_children = osm_mtree_node_get_max_children(p_mtn);
-   for (i = 0; i  max_children; i++) {
-   p_child_mtn = osm_mtree_node_get_child(p_mtn, i);
-   if (p_child_mtn)
-   mgrp_apply_func_sub(p_mgrp, p_child_mtn, p_func,
-   context);
-   }
-}
-
-/**
- **/
-void osm_mgrp_apply_func(const osm_mgrp_t * p_mgrp, osm_mgrp_func_t p_func,
-void *context)
-{
-   osm_mtree_node_t *p_mtn;
-
-   CL_ASSERT(p_mgrp);
-   CL_ASSERT(p_func);
-
-   p_mtn = p_mgrp-p_root;
-
-   if (p_mtn)
-   mgrp_apply_func_sub(p_mgrp, p_mtn, p_func, context);
-}
-- 
1.6.4.2

___
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] opensm doc: Indicated limited (rather than partial) partition membership

2009-09-06 Thread Sasha Khapyorsky
On 09:00 Thu 03 Sep , Hal Rosenstock wrote:
 
 Signed-off-by: Hal Rosenstock hal.rosenst...@gmail.com

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] [PATCH] opensm: improve multicast re-routing requests processing

2009-09-06 Thread Sasha Khapyorsky

When we have two or more changes in a same multicast group multiple
multicast rerouting requests will be created and processed. To prevent
this we will use array of requests indexed by mlid value minus
IB_LID_MCAST_START_HO and for each multicast group change we will just
mark that specific mlid requires re-routing and duplicated requests
will be merged there.

Also in this way we will be able to process multicast group routing
entries deletion for already removed groups by just knowing its MLID
and not using its content - this will let us to not delay mutlicast
groups deletion ('to_be_deleted' flag) and will simplify many multicast
related code flows.

Signed-off-by: Sasha Khapyorsky sas...@voltaire.com
---
 opensm/include/opensm/osm_sm.h |4 +-
 opensm/opensm/osm_mcast_mgr.c  |   27 +
 opensm/opensm/osm_sm.c |   49 +---
 3 files changed, 30 insertions(+), 50 deletions(-)

diff --git a/opensm/include/opensm/osm_sm.h b/opensm/include/opensm/osm_sm.h
index 0914a95..986143a 100644
--- a/opensm/include/opensm/osm_sm.h
+++ b/opensm/include/opensm/osm_sm.h
@@ -126,8 +126,8 @@ typedef struct osm_sm {
cl_dispatcher_t *p_disp;
cl_plock_t *p_lock;
atomic32_t sm_trans_id;
-   cl_spinlock_t mgrp_lock;
-   cl_qlist_t mgrp_list;
+   unsigned mlids_req_max;
+   uint8_t *mlids_req;
osm_sm_mad_ctrl_t mad_ctrl;
osm_lid_mgr_t lid_mgr;
osm_ucast_mgr_t ucast_mgr;
diff --git a/opensm/opensm/osm_mcast_mgr.c b/opensm/opensm/osm_mcast_mgr.c
index d7c5ce1..dd504ef 100644
--- a/opensm/opensm/osm_mcast_mgr.c
+++ b/opensm/opensm/osm_mcast_mgr.c
@@ -1116,7 +1116,6 @@ static int mcast_mgr_set_mftables(osm_sm_t * sm)
 int osm_mcast_mgr_process(osm_sm_t * sm)
 {
cl_qmap_t *p_sw_tbl;
-   cl_qlist_t *p_list = sm-mgrp_list;
osm_mgrp_t *p_mgrp;
int i, ret = 0;
 
@@ -1150,16 +1149,14 @@ int osm_mcast_mgr_process(osm_sm_t * sm)
mcast_mgr_process_mgrp(sm, p_mgrp);
}
 
+   memset(sm-mlids_req, 0, sm-mlids_req_max);
+   sm-mlids_req_max = 0;
+
/*
   Walk the switches and download the tables for each.
 */
ret = mcast_mgr_set_mftables(sm);
 
-   while (!cl_is_qlist_empty(p_list)) {
-   cl_list_item_t *p = cl_qlist_remove_head(p_list);
-   free(p);
-   }
-
 exit:
CL_PLOCK_RELEASE(sm-p_lock);
 
@@ -1174,11 +1171,10 @@ exit:
  **/
 int osm_mcast_mgr_process_mgroups(osm_sm_t * sm)
 {
-   cl_qlist_t *p_list = sm-mgrp_list;
osm_mgrp_t *p_mgrp;
ib_net16_t mlid;
-   osm_mcast_mgr_ctxt_t *ctx;
int ret = 0;
+   unsigned i;
 
OSM_LOG_ENTER(sm-p_log);
 
@@ -1192,14 +1188,12 @@ int osm_mcast_mgr_process_mgroups(osm_sm_t * sm)
goto exit;
}
 
-   while (!cl_is_qlist_empty(p_list)) {
-   ctx = (osm_mcast_mgr_ctxt_t *) cl_qlist_remove_head(p_list);
-
-   /* nice copy no warning on size diff */
-   memcpy(mlid, ctx-mlid, sizeof(mlid));
+   for (i = 0; i = sm-mlids_req_max; i++) {
+   if (!sm-mlids_req[i])
+   continue;
+   sm-mlids_req[i] = 0;
 
-   /* we can destroy the context now */
-   free(ctx);
+   mlid = cl_hton16(i + IB_LID_MCAST_START_HO);
 
/* since we delayed the execution we prefer to pass the
   mlid as the mgrp identifier and then find it or abort */
@@ -1223,6 +1217,9 @@ int osm_mcast_mgr_process_mgroups(osm_sm_t * sm)
mcast_mgr_process_mgrp(sm, p_mgrp);
}
 
+   memset(sm-mlids_req, 0, sm-mlids_req_max);
+   sm-mlids_req_max = 0;
+
/*
   Walk the switches and download the tables for each.
 */
diff --git a/opensm/opensm/osm_sm.c b/opensm/opensm/osm_sm.c
index 50aee91..e446c9d 100644
--- a/opensm/opensm/osm_sm.c
+++ b/opensm/opensm/osm_sm.c
@@ -166,7 +166,6 @@ void osm_sm_construct(IN osm_sm_t * p_sm)
cl_event_construct(p_sm-subnet_up_event);
cl_event_wheel_construct(p_sm-trap_aging_tracker);
cl_thread_construct(p_sm-sweeper);
-   cl_spinlock_construct(p_sm-mgrp_lock);
osm_sm_mad_ctrl_construct(p_sm-mad_ctrl);
osm_lid_mgr_construct(p_sm-lid_mgr);
osm_ucast_mgr_construct(p_sm-ucast_mgr);
@@ -234,8 +233,8 @@ void osm_sm_destroy(IN osm_sm_t * p_sm)
cl_event_destroy(p_sm-signal_event);
cl_event_destroy(p_sm-subnet_up_event);
cl_spinlock_destroy(p_sm-signal_lock);
-   cl_spinlock_destroy(p_sm-mgrp_lock);
cl_spinlock_destroy(p_sm-state_lock);
+   free(p_sm-mlids_req);
 
osm_log(p_sm-p_log, OSM_LOG_SYS, Exiting SM\n);  /* Format 
Waived */
OSM_LOG_EXIT(p_sm-p_log);
@@ -288,11 +287,14 @@ ib_api_status_t osm_sm_init(IN osm_sm_t * p_sm, IN 

[ofa-general] [PATCH] opensm/multicast: remove change id tracking

2009-09-06 Thread Sasha Khapyorsky

Following previous patch 'opensm: improve multicast re-routing requests
processing' remove multicast change id (last_change_id, last_tree_id),
we don't need to track it anymore i- all requests are processed only
once per mlid.

Signed-off-by: Sasha Khapyorsky sas...@voltaire.com
---
 opensm/include/opensm/osm_multicast.h |   10 --
 opensm/opensm/osm_mcast_mgr.c |   21 ++---
 opensm/opensm/osm_multicast.c |7 ---
 3 files changed, 2 insertions(+), 36 deletions(-)

diff --git a/opensm/include/opensm/osm_multicast.h 
b/opensm/include/opensm/osm_multicast.h
index eda447e..ce3d310 100644
--- a/opensm/include/opensm/osm_multicast.h
+++ b/opensm/include/opensm/osm_multicast.h
@@ -128,8 +128,6 @@ typedef struct osm_mgrp {
ib_member_rec_t mcmember_rec;
boolean_t well_known;
boolean_t to_be_deleted;
-   uint32_t last_change_id;
-   uint32_t last_tree_id;
unsigned full_members;
 } osm_mgrp_t;
 /*
@@ -163,14 +161,6 @@ typedef struct osm_mgrp {
 *  track the fact the group is about to be deleted so we can
 *  track the fact a new join is actually a create request.
 *
-*  last_change_id
-*  a counter for the number of changes applied to the group.
-*  This counter shuold be incremented on any modification
-*  to the group: joining or leaving of ports.
-*
-*  last_tree_id
-*  the last change id used for building the current tree.
-*
 * SEE ALSO
 */
 
diff --git a/opensm/opensm/osm_mcast_mgr.c b/opensm/opensm/osm_mcast_mgr.c
index dd504ef..0553277 100644
--- a/opensm/opensm/osm_mcast_mgr.c
+++ b/opensm/opensm/osm_mcast_mgr.c
@@ -1039,12 +1039,10 @@ static ib_api_status_t mcast_mgr_process_mgrp(osm_sm_t 
* sm,
 
if (p_mgrp-full_members) {
status = mcast_mgr_build_spanning_tree(sm, p_mgrp);
-   if (status != IB_SUCCESS) {
+   if (status != IB_SUCCESS)
OSM_LOG(sm-p_log, OSM_LOG_ERROR, ERR 0A17: 
Unable to create spanning tree (%s)\n,
ib_get_err_str(status));
-   goto Exit;
-   }
} else  if (p_mgrp-to_be_deleted) {
OSM_LOG(sm-p_log, OSM_LOG_DEBUG,
Destroying mgrp with lid:0x%x\n,
@@ -1054,12 +1052,8 @@ static ib_api_status_t mcast_mgr_process_mgrp(osm_sm_t * 
sm,
cl_fmap_remove_item(sm-p_subn-mgrp_mgid_tbl,
p_mgrp-map_item);
osm_mgrp_delete(p_mgrp);
-   goto Exit;
}
 
-   p_mgrp-last_tree_id = p_mgrp-last_change_id;
-
-Exit:
OSM_LOG_EXIT(sm-p_log);
return status;
 }
@@ -1201,19 +1195,8 @@ int osm_mcast_mgr_process_mgroups(osm_sm_t * sm)
if (!p_mgrp)
continue;
 
-   /* if there was no change from the last time
-* we processed the group we can skip doing anything
-*/
-   if (p_mgrp-last_change_id == p_mgrp-last_tree_id) {
-   OSM_LOG(sm-p_log, OSM_LOG_DEBUG,
-   Skip processing mgrp with lid:0x%X change 
id:%u\n,
-   cl_ntoh16(mlid), p_mgrp-last_change_id);
-   continue;
-   }
-
OSM_LOG(sm-p_log, OSM_LOG_DEBUG,
-   Processing mgrp with lid:0x%X change id:%u\n,
-   cl_ntoh16(mlid), p_mgrp-last_change_id);
+   Processing mgrp with lid:0x%x\n, cl_ntoh16(mlid));
mcast_mgr_process_mgrp(sm, p_mgrp);
}
 
diff --git a/opensm/opensm/osm_multicast.c b/opensm/opensm/osm_multicast.c
index 4b4a6b0..1326161 100644
--- a/opensm/opensm/osm_multicast.c
+++ b/opensm/opensm/osm_multicast.c
@@ -86,8 +86,6 @@ osm_mgrp_t *osm_mgrp_new(IN const ib_net16_t mlid)
memset(p_mgrp, 0, sizeof(*p_mgrp));
cl_qmap_init(p_mgrp-mcm_port_tbl);
p_mgrp-mlid = mlid;
-   p_mgrp-last_change_id = 0;
-   p_mgrp-last_tree_id = 0;
p_mgrp-to_be_deleted = FALSE;
 
return p_mgrp;
@@ -167,9 +165,6 @@ osm_mcm_port_t *osm_mgrp_add_port(IN osm_subn_t * subn, 
osm_log_t * log,
p_mcm_port-scope_state =
ib_member_set_scope_state(prev_scope,
  prev_join_state | join_state);
-   } else {
-   /* track the fact we modified the group ports */
-   p_mgrp-last_change_id++;
}
 
if ((join_state  IB_JOIN_STATE_FULL) 
@@ -211,8 +206,6 @@ int osm_mgrp_remove_port(osm_subn_t * subn, osm_log_t * 
log, osm_mgrp_t * mgrp,
OSM_LOG(log, OSM_LOG_DEBUG, removing port 0x% PRIx64 \n,
cl_ntoh64(mcm-port_gid.unicast.interface_id));
osm_mcm_port_delete(mcm);
-   /* track the fact 

[ofa-general] [PATCH] opensm/osm_mcast_mgr.c: multicast routing by mlid - renaming

2009-09-06 Thread Sasha Khapyorsky

This patch renames mcast_mgr_process_mgrp() - mcast_mgr_process_mlid()
function and this gets MLID (in host byte order) as parameter. This
simplifies caller flows and makes the code ready for MGID to MLID
compression.

Signed-off-by: Sasha Khapyorsky sas...@voltaire.com
---
 opensm/opensm/osm_mcast_mgr.c |   71 +---
 1 files changed, 23 insertions(+), 48 deletions(-)

diff --git a/opensm/opensm/osm_mcast_mgr.c b/opensm/opensm/osm_mcast_mgr.c
index 0553277..24fb5b1 100644
--- a/opensm/opensm/osm_mcast_mgr.c
+++ b/opensm/opensm/osm_mcast_mgr.c
@@ -1017,41 +1017,37 @@ Exit:
  Process the entire group.
  NOTE : The lock should be held externally!
  **/
-static ib_api_status_t mcast_mgr_process_mgrp(osm_sm_t * sm,
- IN osm_mgrp_t * p_mgrp)
+static ib_api_status_t mcast_mgr_process_mlid(osm_sm_t * sm, uint16_t mlid)
 {
ib_api_status_t status = IB_SUCCESS;
-   ib_net16_t mlid;
+   osm_mgrp_t *mgrp;
 
OSM_LOG_ENTER(sm-p_log);
 
-   mlid = osm_mgrp_get_mlid(p_mgrp);
-
OSM_LOG(sm-p_log, OSM_LOG_DEBUG,
-   Processing multicast group 0x%X\n, cl_ntoh16(mlid));
+   Processing multicast group with lid 0x%X\n, mlid);
 
-   /*
-  Clear the multicast tables to start clean, then build
+   /* Clear the multicast tables to start clean, then build
   the spanning tree which sets the mcast table bits for each
-  port in the group.
-*/
-   mcast_mgr_clear(sm, cl_ntoh16(mlid));
+  port in the group. */
+   mcast_mgr_clear(sm, mlid);
+
+   mgrp = osm_get_mgrp_by_mlid(sm-p_subn, cl_hton16(mlid));
+   if (!mgrp) /* already removed */
+   return IB_SUCCESS;
 
-   if (p_mgrp-full_members) {
-   status = mcast_mgr_build_spanning_tree(sm, p_mgrp);
+   if (mgrp-full_members) {
+   status = mcast_mgr_build_spanning_tree(sm, mgrp);
if (status != IB_SUCCESS)
OSM_LOG(sm-p_log, OSM_LOG_ERROR, ERR 0A17: 
-   Unable to create spanning tree (%s)\n,
-   ib_get_err_str(status));
-   } else  if (p_mgrp-to_be_deleted) {
+   Unable to create spanning tree (%s) for mlid 
+   0x%x\n, ib_get_err_str(status), mlid);
+   } else if (mgrp-to_be_deleted) {
OSM_LOG(sm-p_log, OSM_LOG_DEBUG,
-   Destroying mgrp with lid:0x%x\n,
-   cl_ntoh16(p_mgrp-mlid));
-   sm-p_subn-mgroups[cl_ntoh16(p_mgrp-mlid) -
-   IB_LID_MCAST_START_HO] = NULL;
-   cl_fmap_remove_item(sm-p_subn-mgrp_mgid_tbl,
-   p_mgrp-map_item);
-   osm_mgrp_delete(p_mgrp);
+   Destroying mgrp with lid:0x%x\n, mlid);
+   sm-p_subn-mgroups[mlid - IB_LID_MCAST_START_HO] = NULL;
+   cl_fmap_remove_item(sm-p_subn-mgrp_mgid_tbl, 
mgrp-map_item);
+   osm_mgrp_delete(mgrp);
}
 
OSM_LOG_EXIT(sm-p_log);
@@ -1110,7 +1106,6 @@ static int mcast_mgr_set_mftables(osm_sm_t * sm)
 int osm_mcast_mgr_process(osm_sm_t * sm)
 {
cl_qmap_t *p_sw_tbl;
-   osm_mgrp_t *p_mgrp;
int i, ret = 0;
 
OSM_LOG_ENTER(sm-p_log);
@@ -1132,16 +1127,9 @@ int osm_mcast_mgr_process(osm_sm_t * sm)
}
 
for (i = 0; i = sm-p_subn-max_mcast_lid_ho - IB_LID_MCAST_START_HO;
-i++) {
-   /*
-  We reached here due to some change that caused a heavy sweep
-  of the subnet. Not due to a specific multicast request.
-  So the request type is subnet_change and the port guid is 0.
-*/
-   p_mgrp = sm-p_subn-mgroups[i];
-   if (p_mgrp)
-   mcast_mgr_process_mgrp(sm, p_mgrp);
-   }
+i++)
+   if (sm-p_subn-mgroups[i])
+   mcast_mgr_process_mlid(sm, i + IB_LID_MCAST_START_HO);
 
memset(sm-mlids_req, 0, sm-mlids_req_max);
sm-mlids_req_max = 0;
@@ -1165,8 +1153,6 @@ exit:
  **/
 int osm_mcast_mgr_process_mgroups(osm_sm_t * sm)
 {
-   osm_mgrp_t *p_mgrp;
-   ib_net16_t mlid;
int ret = 0;
unsigned i;
 
@@ -1186,18 +1172,7 @@ int osm_mcast_mgr_process_mgroups(osm_sm_t * sm)
if (!sm-mlids_req[i])
continue;
sm-mlids_req[i] = 0;
-
-   mlid = cl_hton16(i + IB_LID_MCAST_START_HO);
-
-   /* since we delayed the execution we prefer to pass the
-  mlid as the mgrp identifier and then find it or abort */
-   p_mgrp = osm_get_mgrp_by_mlid(sm-p_subn, 

Re: [ofa-general] Cannot export multiple directories using nfs-rdma

2009-09-06 Thread Tom Tucker

Jeff Johnson wrote:
I have a nfs-rdma configuration using Mellanox ConnectX-DDR, ofed-1.4.2 
on Centos 5.3 x86_64.
My ConnectX cards are running 2.5.0 firmware as I have read that 2.6.0 
had rdma issues. I saw these issues and down rev'd the cards to 2.5.0.


I am seeing a peculiar behavior where if I export two separate 
directories from the server and attempt to mount them separately from a 
client I end up with the same export mounted to two different client 
directories.




Hi Jeff:

The mount service does not run over RDMA, it only runs on TCP/UDP. I 
believe you should be able to reproduce this behavior on plain old 
GigE/IPoIB.


Is this the case?

Tom



e.g.:server:/raid1
server:/raid2

'mount.rnfs 10.0.0.251:/raid1 /raid1 -i -o rdma,port=2050'
client:/raid1   ---has server:/raid1 contents
'mount.rnfs 10.0.0.251:/raid2 /raid2 -i -o rdma,port=2050'
client:/raid2   ---has server:/raid1 contents


I have tried creating multiple rdma ports on the server (2050 and 
2051) and then using different ports for each separate mount. The result 
is the same.


I have verified that I am indeed mounting rdma and not merely ipoib.

Is nfs-rdma capable of multiple exports? If so, I cannot find a 
method for dealing with multiple exports from the server or client side 
in any ofed docs.


Thanks for any assistance..

--
Jeff Johnson
Manager
Aeon Computing

jeff.john...@aeoncomputing.com
t: 858-412-3810   f: 858-412-3845
m: 619-204-9061

4905 Morena Boulevard, Suite 1313 - San Diego, CA 92117






___
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