From: Sean Hefty [mailto:[EMAIL PROTECTED]
Sent: Thursday, September 30, 2004 9:55 AM
On Wed, 29 Sep 2004 11:17:05 -0700
Sean Hefty [EMAIL PROTECTED] wrote:
Here's a patch for discussion for an API and implementation that should
allow canceling a sent MAD.
Patch is similar to
On Wed, 29 Sep 2004 11:17:05 -0700
Sean Hefty [EMAIL PROTECTED] wrote:
+ if (mad_send_wr-refcount == 0) {
+ list_del(mad_send_wr-agent_send_list);
+ spin_unlock_irqrestore(mad_agent_priv-send_list_lock, flags);
+
+ mad_send_wc.status =
On Wed, 29 Sep 2004 15:20:20 -0700
Roland Dreier [EMAIL PROTECTED] wrote:
Sean Currently, the consumer _only_ has to free their send
Sean context in their send MAD completion handler. No reference
Sean counting by the consumer is needed. And it doesn't matter
Sean if a send
From: Sean Hefty [mailto:[EMAIL PROTECTED]
Sent: Wednesday, September 29, 2004 3:27 PM
On Wed, 29 Sep 2004 15:20:20 -0700
Roland Dreier [EMAIL PROTECTED] wrote:
Sean Currently, the consumer _only_ has to free their send
Sean context in their send MAD completion handler. No
Sean What is the client doing with the reference counting? When
Sean their send handler gets called, they free their send
Sean context. After they deregister, they free their mad_agent
Sean context.
OK, here's a realistic example. In IPoIB, I'll probably only create
one
From: Roland Dreier [mailto:[EMAIL PROTECTED]
Sent: Wednesday, September 29, 2004 4:58 PM
Fab If deregistration is synchronous then as long as the MAD
Fab layer keeps reference counts for outstanding sends, the
Fab client does not need to. The client is guaranteed that their
Fab I think as long as ib_cancel_mad can return before the
Fab corresponding send completes (i.e. return -EBUSY), you have
Fab this problem and client must provide their own
Fab synchronization, whether through reference counting or some
Fab other means.
Fab Returning
Sean Note that returning -EBUSY from ib_cancel_mad would only
Sean indicate that a callback *might* be invoked. It could have
Sean already been called, which leads me to think that no return
Sean value would be better than one that a client tries to use.
Agree... at least with
