On Wed, 27 Oct 2004 22:29:02 -0700
Roland Dreier <[EMAIL PROTECTED]> wrote:
> 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> u
On Wed, 27 Oct 2004 09:53:28 -0700
Sean Hefty <[EMAIL PROTECTED]> wrote:
> I'll create a patch that uses separate send_posted_mad_list's for
> QP0/1, but try to keep the changes fairly minimal. I'll do this after
> changing the completion handling to use the current workqueue, rather
> than allo
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 bra
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
===
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 line
On Wed, 2004-10-27 at 16:35, Roland Dreier 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 can continue to me
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
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 transitio
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 recei
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)
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
I'm unclear on how to use this.
logset print gives back nothing.
logset debug 8 gives back nothing.
what is this thing?
how do I get trace logging of something like vstat, given that vstat is
not working on my machine?
thanks
ron
___
openib-gene
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
On Wed, 27 Oct 2004, Ronald G. Minnich wrote:
>
>
> I just noticed this tree from a VAPI make :-)
>
> ââsshdâââbashâââmakeâââmakeâââsh¬âcat
>ââ2*[grep]
>
well that didn't translate
make make sh make make make (cat|grep)
w
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 list_
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 =
I just noticed this tree from a VAPI make :-)
ââsshdâââbashâââmakeâââmakeâââsh¬âcat
ââ2*[grep]
This is a bit of work for my poor machine :=)
ron
___
openib-general mailing list
[EMAIL PROTECT
On Wed, 2004-10-27 at 13:45, Sean Hefty wrote:
> If you have time. I'll get to it if not. I don't think this will be a
> large change.
I think the signature for ib_free_recv_mad needs to add in a mad_agent
parameter as there is currently no need to know which mad_agent was
returning the buffers
On Wed, 27 Oct 2004 13:11:17 -0400
Hal Rosenstock <[EMAIL PROTECTED]> wrote:
> On Wed, 2004-10-27 at 12:40, Sean Hefty wrote:
> > I'm just wondering more about whether we should permit an agent to unregister
> > while it has received MADs outstanding. Or, if it makes more sense to block
> > unr
ib_agent: In agent_mad_send, destroy address handle on send completion
rather than immediately
Index: ib_agent_priv.h
===
--- ib_agent_priv.h (revision 1071)
+++ ib_agent_priv.h (working copy)
@@ -32,6 +32,7 @@
struct ib_ag
On Wed, 2004-10-27 at 12:47, Sean Hefty wrote:
> > I can post a patch for this but this depends on whether the agent or MAD
> > layer should destroy the AH.
>
> I think that the MAD agent should, since it allocated the AH.
That's what I thought but didn't want to post a patch and find out
otherwi
On Wed, 2004-10-27 at 12:40, Sean Hefty wrote:
> I'm just wondering more about whether we should permit an agent to unregister
> while it has received MADs outstanding. Or, if it makes more sense to block
> unregister until all MADs have been returned.
That sounds reasonable to me since if the
On Wed, 27 Oct 2004 10:20:05 -0400
Hal Rosenstock <[EMAIL PROTECTED]> wrote:
> 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_
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
On Tue, 26 Oct 2004 21:17:34 -0700
Roland Dreier <[EMAIL PROTECTED]> wrote:
> Sean> In agent_mad_send, a call is made to create an address
> Sean> handle. Immediately after calling ib_post_send_mad, the
> Sean> address handle is destroyed. I think that we want to wait
> Sean> unt
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
On Mon, 2004-10-25 at 16:10, Roland Dreier wrote:
> Just to be clear -- SMI checks should happen before the
> low-level driver gets the MAD, and the low-level driver should only
> get the MAD once (and only generate one reply if necessary).
If I understand correctly, this obviates the need for wha
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 ma
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 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 wait until the send is completed before destroying
> the address handle, and
30 matches
Mail list logo
