Hi Dave,
> I ran 3 iterations of 45 sec tests (total 1 hour 16 min, but I will
> run a longer one tonight). The results are (results in KB/s, and %):
I ran a 8.5 hours run with no batching + another 8.5 hours run with
batching (Buffer sizes: "32 128 512 4096 16384", Threads: "1 8 32",
Each test
>> Quoting Kilian Cavalotti <[EMAIL PROTECTED]>:
>> Subject: Re: OFED 1.2.5 - GA release
>>
>> Hi all,
>>
>> Quoting Tziporet Koren <[EMAIL PROTECTED]>:
>> >I am happy to announce on OFED 1.2.5 GA release.
>>
>> Thanks for the release. I just wanted to let you know that I got a
>> compilation err
Sean Hefty wrote:
The resulting executables will still run without Valgrind, just a
little bit more slowly than they otherwise would, but otherwise
unchanged. When not running on valgrind, each client request
consumes very few (eg. 7) instructions, so the resulting performance
loss is
OSM Simulation Regression Summary
[Generated mail - please do NOT reply]
OpenSM rev = Tue_Aug_14_19:41:02_2007 [3faa14cf64da6e58900c1abbcafe0f33ae1c69e2]
ibutils rev = Thu_Aug_9_15:39:12_2007 [d1681ad8afb35441ac1741392d9e2e94a9d7e22f]
Total=560 Pass=560 Fail=0
Pass:
42 Stability IS1
Michael S. Tsirkin wrote:
> Use common CQ for all TX QPs: keep a per-device counter of outstanding TX WRs,
> and stop the interface when this counter reaches the send queue size, to avoid
> CQ overruns. This should help reduce the number of interrupts for
> bi-directional traffic (such as TCP).
C
> The resulting executables will still run without Valgrind, just a
> little bit more slowly than they otherwise would, but otherwise
> unchanged. When not running on valgrind, each client request
> consumes very few (eg. 7) instructions, so the resulting performance
> loss is negligible
On Thu, 16 Aug 2007 18:36:56 +0300
"Tziporet Koren" <[EMAIL PROTECTED]> wrote:
> I am happy to announce on OFED 1.2.5 GA release.
>
> The release can be found under:
> http://www.openfabrics.org/builds/ofed-1.2.5/release/
Cool, could I get the git tree/tag for each of the sub projects? Especial
Trivial code reordering to make it more readable.
Signed-off-by: Sasha Khapyorsky <[EMAIL PROTECTED]>
---
opensm/opensm/osm_vl15intf.c | 234 -
1 files changed, 114 insertions(+), 120 deletions(-)
diff --git a/opensm/opensm/osm_vl15intf.c b/opensm/opensm
Formatting changes as produced by opensm/osm_indent.
Signed-off-by: Sasha Khapyorsky <[EMAIL PROTECTED]>
---
opensm/opensm/osm_vl15intf.c | 758 -
1 files changed, 370 insertions(+), 388 deletions(-)
diff --git a/opensm/opensm/osm_vl15intf.c b/opensm/ope
Drop unneeded braces, consolidate some flows.
Signed-off-by: Sasha Khapyorsky <[EMAIL PROTECTED]>
---
opensm/opensm/osm_vl15intf.c | 59 --
1 files changed, 11 insertions(+), 48 deletions(-)
diff --git a/opensm/opensm/osm_vl15intf.c b/opensm/opensm/osm_
Some trivial flow consolidations and removing unneeded braces.
Signed-off-by: Sasha Khapyorsky <[EMAIL PROTECTED]>
---
opensm/opensm/osm_sm_mad_ctrl.c | 265 +--
1 files changed, 117 insertions(+), 148 deletions(-)
diff --git a/opensm/opensm/osm_sm_mad_ctrl.
On 15:00 Thu 16 Aug , Ira Weiny wrote:
> For some reason there was a +1 in here. This resulted in the dump function
> printing a fictitious extra port for each node.
>
> Ira
>
>
> From 873fc9b19ddb8e4db068d0b2d9618310e57f3fd1 Mon Sep 17 00:00:00 2001
> From: Ira K. Weiny <[EMAIL PROTECTED]>
For some reason there was a +1 in here. This resulted in the dump function
printing a fictitious extra port for each node.
Ira
>From 873fc9b19ddb8e4db068d0b2d9618310e57f3fd1 Mon Sep 17 00:00:00 2001
From: Ira K. Weiny <[EMAIL PROTECTED]>
Date: Tue, 14 Aug 2007 19:16:56 -0700
Subject: [PATCH] Fi
Some trivial renames + more formatting (with osm_indent).
Signed-off-by: Sasha Khapyorsky <[EMAIL PROTECTED]>
---
opensm/opensm/osm_subnet.c | 662 +++-
1 files changed, 282 insertions(+), 380 deletions(-)
diff --git a/opensm/opensm/osm_subnet.c b/opensm
From: Tom Tucker <[EMAIL PROTECTED]>
Date: Thu, 16 Aug 2007 08:43:11 -0500
> Isn't RDMA _part_ of the "software net stack" within Linux?
It very much is not so.
When using RDMA you lose the capability to do packet shaping,
classification, and all the other wonderful networking facilities
you've
hi roland, thanks, i get it now, it also helped
when i saw this in the memlock manpage:
Limits and permissions
In Linux 2.6.8 and earlier, a process must be privileged (CAP_IPC_LOCK)
in order to lock memory and the RLIMIT_MEMLOCK soft resource limit
defines a limit on
> the calculation looks ok, but it looks to me like
> the && should be an || in the test, esp since earlier
> in the routine, we do an:
>
> if (!can_do_mlock())
> return ERR_PTR(-EPERM);
>
> so, maybe the !capable(CAP_IPC_LOCK) should not be
> there at all?
No, I
hi all, in ib_umem_get() in drivers/infiniband/core/umem.c in the kernel.org
driver at around line 115, we:
locked = npages + current->mm->locked_vm;
lock_limit = current->signal->rlim[RLIMIT_MEMLOCK].rlim_cur >>
PAGE_SHIFT;
if ((locked > lock_limit) && !capable(CAP_I
> Quoting Kilian Cavalotti <[EMAIL PROTECTED]>:
> Subject: Re: OFED 1.2.5 - GA release
>
> Hi all,
>
> Quoting Tziporet Koren <[EMAIL PROTECTED]>:
> >I am happy to announce on OFED 1.2.5 GA release.
>
> Thanks for the release. I just wanted to let you know that I got a
> compilation error (usi
Hi all,
Quoting Tziporet Koren <[EMAIL PROTECTED]>:
I am happy to announce on OFED 1.2.5 GA release.
Thanks for the release. I just wanted to let you know that I got a
compilation error (using RHEL4) in ofa_kernel:
In file included from
/var/tmp/OFEDRPM/BUILD/ofa_kernel-1.2.5/drivers/scs
[EMAIL PROTECTED] wrote on 16.08.2007 18:17:22:
> I don't understand this patch. says this about
> ib_create_qp():
>
> * @qp_init_attr: A list of initial attributes required to create the
> * QP. If QP creation succeeds, then the attributes are updated to
> * the actual capabilities of t
Hi all,
I am currently trying to install/compile OFED on SLES 10 SP1 with the
xen kernel and each time the compilation errors out at the same place.
kernel: 2.6.16.46-0.12-xen
OS: SLES 10 SP1 x86_64
build All applications via the build.sh script
the last few lines from the OFED.log file
gcc
> Hmm, if these things are appropriate for 2.6.23, maybe my patch
> adding linux/mutex.h to ehca_classes.h can go in too?
Actually I queued Dotan's patches quite a while ago, although Linus
seems to be ignoring my pull requests.
I don't see any urgency in adding more similar patches to 2.6.23,
I don't understand this patch. says this about
ib_create_qp():
* @qp_init_attr: A list of initial attributes required to create the
* QP. If QP creation succeeds, then the attributes are updated to
* the actual capabilities of the created QP.
So it seems the current code is actually cor
I am happy to announce on OFED 1.2.5 GA release.
The release can be found under:
http://www.openfabrics.org/builds/ofed-1.2.5/release/
And later it will be on the OpenFabrics download page:
http://www.openfabrics.org/downloads.htm
This release was done in a joint effort of all companies in t
> It seems a trailing ';' has slipped into mlx4_MAD_IFC() which causes
> the response to be copied out unconditionally.
Thanks -- this is the third time someone has sent me this patch in the
last day ;)
- R.
___
general mailing list
general@lists.ope
Check that the LID in attach/detach multicast group is a multicast LID.
Signed-off-by: Dotan Barak <[EMAIL PROTECTED]>
---
diff --git a/drivers/infiniband/core/verbs.c b/drivers/infiniband/core/verbs.c
index 86ed8af..97353ff 100644
--- a/drivers/infiniband/core/verbs.c
+++ b/drivers/infiniband/c
On Wed, 2007-08-15 at 22:26 -0400, Jeff Garzik wrote:
[...snip...]
> > I think removing the RDMA stack is the wrong thing to do, and you
> > shouldn't just threaten to yank entire subsystems because you don't like
> > the technology. Lets keep this constructive, can we? RDMA should get
> > t
It seems a trailing ';' has slipped into mlx4_MAD_IFC() which causes
the response to be copied out unconditionally.
Signed-off-by: Andy Whitcroft <[EMAIL PROTECTED]>
Cc: Roland Dreier <[EMAIL PROTECTED]>
Cc: Sean Hefty <[EMAIL PROTECTED]>
Cc: Hal Rosenstock <[EMAIL PROTECTED]>
Cc: general@lists.o
Use common CQ for all TX QPs: keep a per-device counter of outstanding TX WRs,
and stop the interface when this counter reaches the send queue size, to avoid
CQ overruns. This should help reduce the number of interrupts for
bi-directional traffic (such as TCP).
This helps fix "driver is hogging i
<>___
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_1_2_c_kernel-20070816-0200_linux-2.6.19_powerpc_check/drivers/infiniband/hw/ehca/ehca_main.c:831:
error: invalid type argument of â->â
/home/vlad/tmp/ofa_1_2_c_kernel-20070816-0200_linux-2.6.19_powerpc_check/drivers/infiniband/hw/ehca/ehca_main.c:834:
error: invalid type argument of â->â
Sean Hefty wrote:
+if test x$with_valgrind = x || test x$with_valgrind = xno; then
+want_valgrind=no
+AC_DEFINE([NVALGRIND], 1, [Define to 1 to disable Valgrind
annotations.])
+AC_CHECK_HEADER(valgrind/memcheck.h,
+[AC_DEFINE(HAVE_VALGRIND_MEMCHECK_H, 1,
+[Define to 1 if
This email was generated automatically, please do not reply
git_url: git://git.openfabrics.org/ofed_1_2/linux-2.6.git
git_branch: ofed_1_2
Common build parameters: --with-ipoib-mod --with-sdp-mod --with-srp-mod
--with-user_mad-mod --with-user_access-mod --with-mthca-mod --with-core-mod
--wit
34 matches
Mail list logo
