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... Steve. _______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
