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

[Steve Wise]

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.