WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

[Xen-devel] Re: SKB paged fragment lifecycle on receive

On Fri, 2011-06-24 at 13:11 -0700, Jeremy Fitzhardinge wrote:
> On 06/24/2011 12:46 PM, David Miller wrote:
> > Pages get transferred between different SKBs all the time.
> >
> > For example, GRO makes extensive use of this technique.
> > See net/core/skbuff.c:skb_gro_receive().
> >
> > It is just one example.
> 
> I see, and the new skb doesn't get a destructor copied from the
> original, so there'd be no second callback.

What about if we were to have a per-shinfo destructor (called once for
each page as its refcount goes 1->0, from whichever skb ends up with the
last ref) as well as the skb-destructors. This already handles the
cloning case but when pages are moved between shinfo then would it make
sense for that to be propagated between skb's under these circumstances
and/or require them to be the same? Since in the case of something like
skb_gro_receive the skbs (and hence the frag array pages) are all from
the same 'owner' (even if the skb is actually created by the stack on
their behalf) I suspect this could work?

But I bet this assumption isn't valid in all cases.

In which case I end up wondering about a destructor per page in the frag
array. At which point we might as well consider it as a part of the core
mm stuff rather than something net specific?

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel