[openib-general] [PATCH 00/12] ofed_1_2 - Neighbour update support

[Steve Wise]

On Fri, 2007-02-02 at 01:33 +0200, Michael S. Tsirkin wrote:
> > Quoting Steve Wise <swise at opengridcomputing.com>:
> > Subject: Re: [PATCH 00/12] ofed_1_2 - Neighbour update support
> > 
> > On Fri, 2007-02-02 at 00:48 +0200, Michael S. Tsirkin wrote:
> > > > > I can think of some more complicated approaches that might work better
> > > > > for iwarp. Off the top of my head, our netevents implementation could
> > > > > keep a reference on the skb, start a timer, check the users counter on skb and
> > > > > call the notifier chain when it drops to 1. Let's sleep on it.
> > > > > 
> > 
> > Remembering which skbs to check later requires more complication.  Here
> > is one method to handle this and do what you suggest above.
> > 
> > In the snoop function:
> > 
> > Clone the skb and save the original skb ptr in the new skb->cb area.
> > This area is ours to use on a freshly cloned skbuff.  Add this new skb
> > ptr to a linked list of outstanding netevents to be processed later.
> > Don't free the original skb passed in.  This keeps the reference on it
> > like you proposed above.  Schedule a delayed work handler for a few
> > ticks in the future.
> > 
> > In the delayed work handler:
> > 
> > Walk the pending netevents skb list.  For each pending skb, get the
> > original skb ptr from the cloned skb->cb area, and if the user count is
> > now 1 then do the current destructor() logic, remove the skb from the
> > pending list, and free both skbs.  If the list is not empty reschedule
> > the delayed work handler for a few ticks later.
> > 
> > In the module unload function:
> > 
> > cancel any delayed work handling
> > walk the pending list and free the skbs and the original snooped skbs.
> > 
> > This solves the destructor issue and the rmmod issue, but is more
> > complicated.  If you're worried about regressing straight rdma address
> > translation, then you can call the address translation timer function
> > synchronously in the snoop function like before and change the
> > addr_trans module to not use netevents...
> 
> 
> Yes, this is what I proposed above. It does all sound quite complicated.
> Some notes:
> 	- you don't need an skb just too keep a void*. create your own
> 	  structure for this.
> 	- better use a timer than a workqueue - you are calling netevents
> 	  from atomic context on new kernels anyway.
> 
> So maybe destructor with module ref counting is better.
> Donnu.

We could use a global refcnt to count the number of pending destructions
and use a completion object to block unload until all the destructors
fire and the refcnt goes to zero.