Evgeniy, > You can use existing skb destructor and appropriate reference > counter is already there. In your own destructor you need to > call old one of course, and it's type can be determined from > the analysis of the headers and skb itself (there are not so > much destructor's types actually). If that level of > abstraction is not enough, it is possible to change > skb_release_data()/__kfree_skb() so that it would be possible > in skb->destructor() to determine if attached pages will be > freed or not.
Yes absolutely. My first thought was to use the skbuf destructor but I was paranoid I might screw up the destructor stacking. Maybe I should have been braver? Since the callback descriptor needs to track the pages in skb_shinfo() rather than the skbuf itself, it seemed "natural" to make skb_release_data() the trigger. > Existing sendfile() implementation is synchronous, it does not > require async callback. Is it not true that you cannot know when it is safe to overwrite pages sent in this way? > skbs are allocated from own cache, and the smaller it is, the better. As I mentioned in another reply, skbs are indeed allocated from their own cache, but skb_shinfo() is allocated contiguously with the packet header using kmalloc. -- Cheers, Eric - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html