On Wed, 2011-11-09 at 17:24 +0000, Michał Mirosław wrote:

On Wed, Nov 09, 2011 at 04:25:14PM +0000, Ian Campbell wrote:

quoted

On Wed, 2011-11-09 at 15:33 +0000, Michał Mirosław wrote:

quoted

On Wed, Nov 09, 2011 at 03:02:04PM +0000, Ian Campbell wrote:

quoted

Entities which care about the complete lifecycle of pages which they inject
into the network stack via an skb paged fragment can choose to set this
destructor in order to receive a callback when the stack is really finished
with a page (including all clones, retransmits, pull-ups etc etc).

[...]

quoted

--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h

@@ -139,9 +139,16 @@ struct sk_buff;
 
 typedef struct skb_frag_struct skb_frag_t;
 
+struct skb_frag_destructor {
+	atomic_t ref;
+	int (*destroy)(void *data);
+	void *data;
+};
+
 struct skb_frag_struct {
 	struct {
 		struct page *p;
+		struct skb_frag_destructor *destructor;
 	} page;

You can get rid of the data field of skb_frag_destructor: if destroy() gets
pointer to the destroyed struct skb_frag_set_destructor, its users can
get at containing struct via container_of() if needed and the memory
pointed to by data won't have to be managed separately.

At the moment you can share one destructor between all the frags,
whereas data is specific to the frag.

[...]

If you want distinct data pointers then you need to also have per-frag
skb_frag_destructor as you wrote in this patch. So removing 'data' field
saves memory but doesn't change anything else except the way to reference
the data (container_of() instead of pointer dereference).

Oh yes, you are absolutely right.

Ian.

Best Regards,
Michał Mirosław