On Thu, 28 Oct 2004 10:42:23 -0400
Hal Rosenstock <[EMAIL PROTECTED]> wrote:
> On Thu, 2004-10-28 at 02:01, Sean Hefty wrote:
> > I've run into a few other issues trying to use separate send queues.
> >
> > One of note is that receives are posted to the QP outside of the
> > lock that inserts the
On Thu, 2004-10-28 at 02:01, Sean Hefty wrote:
> I've run into a few other issues trying to use separate send queues.
> One of note is that receives are posted to the QP outside of the lock
> that inserts them onto the recv_posted_mad_list.
I couldn't find where you were referring to. Can you poi
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
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 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 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, 26 Oct 2004 13:03:58 -0400
Hal Rosenstock <[EMAIL PROTECTED]> wrote:
> On Tue, 2004-10-26 at 12:50, Sean Hefty wrote:
> > > Another alternative is to assume it is a receive if it is not a send is
> > > not matched.
> >
> > I think we have other issues with the completion handling as well.
Hello!
Quoting r. Roland Dreier ([EMAIL PROTECTED]) "Re: [openib-general] [PATCH] ib_mad: In
completion handler, when status != success call?send done handler":
> Sean> As a suggestion, we can allocate 2 CQs per QP, one for
> Sean> receives, and one for sends. This
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 completions based on the callback.
>
> That's one solution, and another way to han
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 completions based on the callback.
That's one solution, and another way to handle it is to have a way of
distinguishing sends from receive
On Tue, 2004-10-26 at 12:50, Sean Hefty wrote:
> > Another alternative is to assume it is a receive if it is not a send is
> > not matched.
>
> 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_p
On Tue, 26 Oct 2004 12:44:56 -0400
Hal Rosenstock <[EMAIL PROTECTED]> wrote:
> On Tue, 2004-10-26 at 12:30, Sean Hefty wrote:
> > > I think this is still not quite right: what if a receive fails?
> >
> > As a suggestion, we can allocate 2 CQs per QP, one for receives,
> > and one for sends. Thi
On Tue, 2004-10-26 at 12:30, Sean Hefty wrote:
> > I think this is still not quite right: what if a receive fails?
>
> As a suggestion, we can allocate 2 CQs per QP, one for receives,
> and one for sends. This would let us separate send from receive
> completions based on the callback.
Another
On Tue, 26 Oct 2004 09:14:03 -0700
Roland Dreier <[EMAIL PROTECTED]> wrote:
> if (wc.status != IB_WC_SUCCESS) {
> printk(KERN_ERR PFX "Completion error %d WRID 0x%Lx\n",
> wc.status, (unsigned long long)
> wc.wr_id);
> +
if (wc.status != IB_WC_SUCCESS) {
printk(KERN_ERR PFX "Completion error %d WRID 0x%Lx\n",
wc.status, (unsigned long long)
wc.wr_id);
+ ib_mad_send_done_handler(port_priv, &wc);
} el
ib_mad: In completion handler, when status != success call send done
handler so that if a request fails we'll complete it. eg if a consumer
uses a bad L_Key for a send request, the send will complete (and if the
consumer ever does ib_unregister_mad_agent it will not hang waiting for
the send to fi
16 matches
Mail list logo
