On Tue, 2004-10-26 at 12:40, Sean Hefty wrote:
Currently, a call to ib_free_recv_mad does not dereference the mad_agent that
the mad was given to. The call itself does not access the mad_agent,
but should a reference be held on the mad_agent while it has a received MAD?
Looking at the
On Tue, 2004-10-26 at 12:50, Sean Hefty wrote:
I think we have other issues with the completion handling as well.
Since we use a single CQ for both QPs, I think that we need to search
the send_posted_mad_list to find the corresponding completion.
We cannot assume that the completion
On Wed, 27 Oct 2004 10:08:45 -0400
Hal Rosenstock [EMAIL PROTECTED] wrote:
On Tue, 2004-10-26 at 12:40, Sean Hefty wrote:
Currently, a call to ib_free_recv_mad does not dereference the mad_agent that
the mad was given to. The call itself does not access the mad_agent,
but should a
On Wed, 27 Oct 2004 09:47:25 -0400
Hal Rosenstock [EMAIL PROTECTED] wrote:
On Tue, 2004-10-26 at 18:29, Sean Hefty wrote:
In agent_mad_send, a call is made to create an address handle.
Immediately after calling ib_post_send_mad, the address handle is destroyed.
I think that we want to
Hal If I understand correctly, this obviates the need for what is
Hal now ib_agent. All that might remain is SMI handling for DR
Hal SMPs. Is that right ?
I think the receive path looks something like
if (DR SMP)
SMI checks (discard on failure)
rc =
Index: access/ib_mad_priv.h
===
--- access/ib_mad_priv.h(revision 1078)
+++ access/ib_mad_priv.h(working copy)
@@ -153,6 +153,7 @@
struct ib_mad_mgmt_class_table *version[MAX_MGMT_VERSION];
struct
On Wed, 27 Oct 2004, Ronald G. Minnich wrote:
I just noticed this tree from a VAPI make :-)
sshdbashmakemakeshcat
2*[grep]
well that didn't translate
make make sh make make make (cat|grep)
was the tree.
ron
On Wed, 2004-10-27 at 14:59, Sean Hefty wrote:
Thanks. Applied.
-- Hal
___
openib-general mailing list
[EMAIL PROTECTED]
http://openib.org/mailman/listinfo/openib-general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
OK, I'm going to go ahead and rename ib_mad.c - mad.c, ib_agent.c -
agent.c etc. (This also makes it possible to build a module named
ib_mad.o, which I think makes more sense than ib_al.o, from multiple
sources).
I can continue to merge by hand but it might make sense to make the
same change on
On Wed, 27 Oct 2004 13:35:22 -0700
Roland Dreier [EMAIL PROTECTED] wrote:
OK, I'm going to go ahead and rename ib_mad.c - mad.c, ib_agent.c -
agent.c etc. (This also makes it possible to build a module named
ib_mad.o, which I think makes more sense than ib_al.o, from multiple
sources).
I
On Tue, 26 Oct 2004 13:14:00 -0400
Hal Rosenstock [EMAIL PROTECTED] wrote:
On Tue, 2004-10-26 at 13:10, Roland Dreier wrote:
Sean As a suggestion, we can allocate 2 CQs per QP, one for
Sean receives, and one for sends. This would let us separate
Sean send from receive
There appears to be a minor race in ib_mad_port_start where the MAD
layer could begin accepting and processing receives before the QP allows
sends, or even before we know if the QP will finish initializing
properly. This makes it difficult to handle traffic that comes in
before the QP is
What's the purpose behind the index field in the receive wr_id?
- Sean
___
openib-general mailing list
[EMAIL PROTECTED]
http://openib.org/mailman/listinfo/openib-general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Here's the new SA module (with support only for PathRecord GETs and
MCMemberRecord SETs) that I just checked in. All comments and
criticism welcome...
(It may be easier to review the code just by looking at
include/ib_sa.h and core/sa_query.c in the repo rather than a diff
that is just added
This converts IPoIB to use the new SA API for PathRecord and
MCMemberRecord transactions.
Correcting the component mask used for multicast joins after the initial
broadcast group still needs to be done...
- R.
Index: ulp/ipoib/ipoib_main.c
Sean I didn't realize that you had taken a copy of the current
Sean mad code. Is there anything in the openib-candidate branch
Sean that isn't in your branch? Does it make sense to just
Sean update the code in the roland-merge branch?
I've got everything up to r1080 in my branch
16 matches
Mail list logo