How about keeping the cache, but keeping it always up-to-date by
registering it to process incomind mads instead of events?
___
general mailing list
general@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general
To
This email was generated automatically, please do not reply
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
--with-addr_trans-mod --with-rds-mod --with-cxgb3-mod
Passed:
Passed on i686 with
On Friday 27 April 2007 20:11:11 Ralph Campbell wrote:
This patch fixes the problem reported by Bernd Schubert [EMAIL PROTECTED]
with kernel debug options enabled.
BUG: at kernel/lockdep.c:1860 trace_hardirqs_on()
Hopefully, this can be included in OFED 1.2 as well as
going upstream.
When the system is busy it may happen that the command actually
completed but it took more than the specified timeout till the
task executing the command was actually given CPU time. This test
checks that the completion is really missing before failing.
Signed-off-by: Eli Cohen [EMAIL PROTECTED]
Quoting Eli Cohen [EMAIL PROTECTED]:
Subject: [PATCH] IB/mlx4 mlx4_ib: commands timeout
When the system is busy it may happen that the command actually
completed but it took more than the specified timeout till the
task executing the command was actually given CPU time. This test
checks
On Mon, 2007-05-07 at 15:04 +0300, Michael S. Tsirkin wrote:
How likely is this to help in practice?
Like I said, when the system is very busy. In this case the command may
actually complete very soon but wait_for_completion_timeout() will
nevertheless return zero since the task did not get CPU
On Sun, 2007-05-06 at 09:03, Sasha Khapyorsky wrote:
Replace repeated strlen() calls used in sprintf() by actual string
length accumulated from sprintf() return values.
Signed-off-by: Sasha Khapyorsky [EMAIL PROTECTED]
Thanks. Applied to master only (as this is a cleanup rather than a bug
The issue addressed is keeping ipoib interfaces alive despite port's pkey order
is changed.
pkey-to-index queries were using a cache. however, the cache might not be
up-to-date when
ipoib asks it to resolve a pkey. Therefore must use a direct query. On the
other hand, in
build_mlx_header, the
core: uncached find gid and find pkey queries
* Add ib_find_gid and ib_find_pkey over possibly blocking device
queries.
Signed-off-by: Yosef Etigin [EMAIL PROTECTED]
---
drivers/infiniband/core/device.c | 96 +++
include/rdma/ib_verbs.h | 23
core, ulp: don't use ib_cahce
* Modify users of the ib cache in: core, ipoib, srp, to use
blocking device queries.
Signed-off-by: Yosef Etigin [EMAIL PROTECTED]
---
drivers/infiniband/core/cm.c|8
drivers/infiniband/core/cma.c |9 -
ipoib: handle pkey change events
This issue was found during partitioning SM fail over testing.
* added flush flag to ipoib_ib_dev_stop(), ipoib_ib_dev_down() alike
* fixed a bug in device extraction from the work struct
* removed some warnings in case they are caused due to missing PKEY as
mad: cache port lmc
* Instead of using the ib cache, mad core will keep the up-to-date
lmc of each port inside port_priv struct. It will be updated by
incoming PORT_INFO mads.
* use the uncached version of query gid.
This query will be cache-optimized in the provider level.
Signed-off-by:
On Sun, 2007-05-06 at 13:41, Sasha Khapyorsky wrote:
remove unneeded run-time NULL pointer check (followed free() is not
under this check anyway).
Signed-off-by: Sasha Khapyorsky [EMAIL PROTECTED]
Thanks. Applied (to master only).
-- Hal
___
Quoting Yosef Etigin [EMAIL PROTECTED]:
Subject: [PATCH 1/6 v2] fix pkey change handling and remove the cahce
core: uncached find gid and find pkey queries
* Add ib_find_gid and ib_find_pkey over possibly blocking device
queries.
Before I look into this deeper, a note on submissin
@@ -139,6 +139,9 @@ static void smp_snoop(struct ib_device *
event.element.port_num = port_num;
ib_dispatch_event(event);
}
+
+ /* update cache with the incoming mad */
Please don't add such comments: name
Michael S. Tsirkin wrote:
@@ -139,6 +139,9 @@ static void smp_snoop(struct ib_device *
event.element.port_num = port_num;
ib_dispatch_event(event);
}
+
+ /* update cache with the incoming mad */
Please don't add such
@@ -1865,6 +1863,15 @@ static void ib_mad_recv_done_handler(str
recv-header.recv_wc.recv_buf.mad = recv-mad.mad;
recv-header.recv_wc.recv_buf.grh = recv-grh;
+ /* update our lmc cache with port info smps */
+ if ((recv-mad.mad.mad_hdr.mgmt_class ==
Eli Cohen wrote:
On Mon, 2007-05-07 at 15:04 +0300, Michael S. Tsirkin wrote:
How likely is this to help in practice?
Like I said, when the system is very busy. In this case the command may
actually complete very soon but wait_for_completion_timeout() will
nevertheless return zero
Quoting Tziporet Koren [EMAIL PROTECTED]:
Subject: Re: [ofa-general] Re: [PATCH] IB/mlx4 mlx4_ib: commands timeout
Eli Cohen wrote:
On Mon, 2007-05-07 at 15:04 +0300, Michael S. Tsirkin wrote:
How likely is this to help in practice?
Like I said, when the system is very busy. In
Michael S. Tsirkin wrote:
@@ -1865,6 +1863,15 @@ static void ib_mad_recv_done_handler(str
recv-header.recv_wc.recv_buf.mad = recv-mad.mad;
recv-header.recv_wc.recv_buf.grh = recv-grh;
+ /* update our lmc cache with port info smps */
+ if ((recv-mad.mad.mad_hdr.mgmt_class ==
On Mon, 2007-05-07 at 07:12 -0700, Roland Dreier wrote:
When the system is busy it may happen that the command actually
completed but it took more than the specified timeout till the
task executing the command was actually given CPU time. This test
checks that the completion is really
Hi,
I have question regarding ibdiagnet and credit loop checking. In debug.tcl
there seems to be two different credit checks:
# report credit loops
ibdmCalcMinHopTables $fabric
set roots [ibdmFindRootNodesByMinHop $fabric]
if {[llength $roots]} {
inform -I-reporting:found.roots $roots
Hi Yosef,
On Mon, 2007-05-07 at 10:18, Yosef Etigin wrote:
Michael S. Tsirkin wrote:
@@ -1865,6 +1863,15 @@ static void ib_mad_recv_done_handler(str
recv-header.recv_wc.recv_buf.mad = recv-mad.mad;
recv-header.recv_wc.recv_buf.grh = recv-grh;
+ /* update our lmc cache with port
Quoting Roland Dreier [EMAIL PROTECTED]:
Subject: Re: [PATCH] IB/mlx4 mlx4_ib: commands timeout
When the system is busy it may happen that the command actually
completed but it took more than the specified timeout till the
task executing the command was actually given CPU time. This
Quoting Yosef Etigin [EMAIL PROTECTED]:
Subject: Re: [PATCH 5/6 v2] fix pkey change handling and remove the cahce
Michael S. Tsirkin wrote:
@@ -1865,6 +1863,15 @@ static void ib_mad_recv_done_handler(str
recv-header.recv_wc.recv_buf.mad = recv-mad.mad;
Michael S. Tsirkin wrote:
Quoting Yosef Etigin [EMAIL PROTECTED]:
Subject: Re: [PATCH 5/6 v2] fix pkey change handling and remove the cahce
Michael S. Tsirkin wrote:
@@ -1865,6 +1863,15 @@ static void ib_mad_recv_done_handler(str
recv-header.recv_wc.recv_buf.mad = recv-mad.mad;
Hal Rosenstock wrote:
Hi Yosef,
On Mon, 2007-05-07 at 10:18, Yosef Etigin wrote:
Michael S. Tsirkin wrote:
@@ -1865,6 +1863,15 @@ static void ib_mad_recv_done_handler(str
recv-header.recv_wc.recv_buf.mad = recv-mad.mad;
recv-header.recv_wc.recv_buf.grh = recv-grh;
+ /* update our
In order to prevent losing interrupts, all EQs must be rearmed
whenever an interrupt occurs, regardless if that interrupt is
generated for the EQ or not.
Signed-off-by: Eli Cohen [EMAIL PROTECTED]
---
Index: connectx_kernel/drivers/net/mlx4/eq.c
All in all, this patch tries to do many things at once. I wonder whether you
can split the patch in 2: fix the pkey change case separately, and remove pkey
polling separately.
Quoting Yosef Etigin [EMAIL PROTECTED]:
Subject: [PATCH 3/6 v2] fix pkey change handling and remove the cahce
On Sun, 2007-05-06 at 16:00, Sasha Khapyorsky wrote:
Consolidate CA and router PortInfo receiving processing code.
Signed-off-by: Sasha Khapyorsky [EMAIL PROTECTED]
Thanks. Applied (to master only).
-- Hal
___
general mailing list
On Mon, 2007-05-07 at 11:12, Yosef Etigin wrote:
Hal Rosenstock wrote:
Hi Yosef,
On Mon, 2007-05-07 at 10:18, Yosef Etigin wrote:
Michael S. Tsirkin wrote:
@@ -1865,6 +1863,15 @@ static void ib_mad_recv_done_handler(str
recv-header.recv_wc.recv_buf.mad = recv-mad.mad;
Thanks... should we optimize out the
if (eqes_found)
eq_set_ci(eq, 1);
at the end of mlx4_eq_int() now? Actually the best fix is probably:
diff --git a/drivers/net/mlx4/eq.c b/drivers/net/mlx4/eq.c
index 8d641b8..acf1c80 100644
--- a/drivers/net/mlx4/eq.c
+++
Hi,
I am currently experimenting with Infiniband data transfers across
servers with different operating systems.
Is it possible for two servers with different Infiniband drivers (and
OS) to communicate for data transfers - as in
the example below.
Server A runs VxWorks and uses SBS IB driver
I am not familiar with SBS IB driver for VxWorks, but in general any IB
compliant HCA
should talk with any other IB compliant switch/HCA with no regards to
the driver implementation.
Make sure to run SM on one of the ends to enable link establishment.
Boris
On Sun, 2007-05-06 at 21:17 -0700, Sean Hefty wrote:
Are there man pages for the rdma-cm in the pipeline? I think it would
be great (requirement?) to have these for ofed-1.2 since we do have the
other verbs man pages.
I've added man pages for the APIs and test programs to my master and
A simple question:
Is it possible to connect a SDR HCA to a DDR switch?
If so, what happens with the data that is send from a DDR HCA to the SDR
HCA?
Regards,
Koen
*** Disclaimer ***
Vlaamse Radio- en Televisieomroep
Auguste Reyerslaan 52, 1043 Brussel
nv van publiek recht
BTW BE 0244.142.664
Michael S. Tsirkin wrote:
All in all, this patch tries to do many things at once. I wonder whether you
can split the patch in 2: fix the pkey change case separately, and remove pkey
polling separately.
I'm not sure it's nessesary. What I had in mind is that the polling was created
since we
Add userspace support for iWARP verbs Send w/ INV and Send w/ SE and INV.
Signed-off-by: Mikkel Hagen [EMAIL PROTECTED]
--- linux-2.6.21.1/drivers/infiniband/core/uverbs_cmd.c2007-05-04
14:25:50.0 -0400
+++ linux-2.6.21.1/drivers/infiniband/core/uverbs_cmd.c2007-05-04
Here are a few comments. Consider them for inclusion, but what you've
done so far is a great start.
Thanks for the feedback. I'll try to update this before RC3 freezes.
- rdma_disconnect - for iWARP connections, this initiates a RDMAC Verbs
normal close. If the connection was properly
On Mon, 2007-05-07 at 10:03 -0700, Sean Hefty wrote:
Here are a few comments. Consider them for inclusion, but what you've
done so far is a great start.
Thanks for the feedback. I'll try to update this before RC3 freezes.
- rdma_disconnect - for iWARP connections, this initiates a
Roland,
Last night you submitted the NAPI work for 2.6.22. When I checked a few
minutes ago I saw that the NAPI work has been merged into the for-linus
tree and not the for-2.6.22 tree.
I want to merge and test my patch against the latest tree -which git
tree should I use? Can you please
Add a new routine and rename another to encapsulate common code for
synchronizing with device removal.
Signed-off-by: Sean Hefty [EMAIL PROTECTED]
---
drivers/infiniband/core/cma.c | 89 ++---
1 files changed, 48 insertions(+), 41 deletions(-)
diff --git
The cma_iw_handler needs to validate the state of the rdma_cm_id before
processing a new connection request to ensure that a device removal is
not already being processed for the same rdma_cm_id. Without the state
check, the user can receive simultaneous callbacks for the same cm_id, or
a
Several checks in the rdma_cm check against the state of the
cm_id, but only to validate that the cm_id is bound to an underlying
transport specific CM and an RDMA device. Make the check explicit
in what we're trying to check for, since we're not synchronizing
against the cm_id state.
This will
Last night you submitted the NAPI work for 2.6.22. When I checked a
few minutes ago I saw that the NAPI work has been merged into the
for-linus tree and not the for-2.6.22 tree.
Yes, that was a temporary situation until Linus pulled everything into
his tree (which he now has done).
I
On Sat, 2007-04-28 at 16:20 -0400, Jeff Squyres wrote:
You'd probably be better asking this question on the Open MPI mailing
lists, not here. :-)
FWIW, yes, adding RDMA CM support has actually been on my to-do list
for a while, but it keeps getting bumped by higher priority items.
Also, there appears to be a DAPL BTL in OMPI. Is this BTL complete and
enabled for the ofed-1.2 udapl library?
Steve.
On Mon, 2007-05-07 at 17:09 -0500, Steve Wise wrote:
On Sat, 2007-04-28 at 16:20 -0400, Jeff Squyres wrote:
You'd probably be better asking this question on the Open MPI
On May 7, 2007, at 6:52 PM, Steve Wise wrote:
Also, there appears to be a DAPL BTL in OMPI. Is this BTL complete
and
enabled for the ofed-1.2 udapl library?
Yes, it is complete and is well-tested in Solaris.
It is not well tested in Linux/OFED (we've been concentrating on the
verbs
Congratulations!
You won 470,274.11 pounds and it is equivalent to $921,201 dollars from the NET
ON-LINE LOTTERY CORPORATION IN UNITED KINGDOM this year bonanza.
Contact Claims Department quoting winning draw number: 53Q8/02.
CONTACT PERSON: Mr. Michael Watson
EMAIL: [EMAIL PROTECTED]
Hi !
So I see this construct:
/* There is already a thread processing this queue. */
if (test_and_set_bit(0, dd-ipath_rcv_pending))
goto bail;
.../...
done:
clear_bit(0, dd-ipath_rcv_pending);
smp_mb__after_clear_bit();
So that's
50 matches
Mail list logo
