On Fri, 2007-02-02 at 01:33 +0200, Michael S. Tsirkin wrote: > > Quoting Steve Wise <[EMAIL PROTECTED]>: > > 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. _______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
