[Xen-devel] Re: [PATCH 00/17] Netchannel2 for a modern git kernel

[Jeremy Fitzhardinge <jeremy@xxxxxxxx>]

On 10/07/09 17:15, Steven Smith wrote:
>>>> Thanks.  I've pulled it anyway, but not yet merged it into anything yet.
>>>>     
>>>>         
>>> Okay.  I'm going to change the interface a bit following the review
>>> comments; would you prefer I shove a fixup patch on the end or edit
>>> history and keep the patches sensibly self-contained?
>>>       
>> At this point I haven't done anything with the branch, so just rewrite
>> it to your heart's content.
>>     
> Okay.
>
>   
>> BTW, do you see this is something as a candidate for merging upstream?
>>     
> I've mostly been defining ``upstream'' as you, but, yes, sending it
> further would be good.
>   

OK, but that's a fair bit more work.

> The NC2 approach is basically similar to the NC1 approach, but
> generalised so that NC1 and NC2 can cooperate in a reasonably sane
> way.  It still uses the PG_foreign bit to identify foreign pages, and
> the page->private and page->mapping fields for various bits of
> information.
>   

Unfortunately the PG_foreign approach is a non-starter for upstream,
mainly because adding new page flags is strongly frowned upon unless
there's a very compelling reason.  Unless we can find some other kernel
subsystems which can make use of a page destructor, we probably won't
make the cut.  (It doesn't help that there are no more page flags left
on 32-bit.)

The approach I'm trying at the moment is to use the skb destructor
mechanism to grab the pages out of the skb as its freed.  To deal with
skb_clone, I'm adding a flag to the skb to force a clone to do a
complete copy so there are no more aliases to the pages (skb_clone
should be rare in the common case).

> The basic idea is that everything which can map foreign pages and
> expose them to the rest of Linux needs to allocate a foreign page
> tracker (effectively an array of (domid, grant_ref, void *ctxt)
> tuples), and to register mapped pages with that tracker.  It then uses
> the top few bits of page->private to identify the tracker, and the
> rest to index into the array.  This allows you to forward packets from
> a foreign domain without knowing whether it was received by NC1 or
> NC2.
>   

Well, if its wrapped by a skb, we can get the skb destructor to handle
the cleanup phase.  So long as we get the callback, I don't think it
should affect the rest of the mechanism.

> Arguably, blkback should be using this mechanism as well, but since
> we've gotten away with it so far I thought it'd be best to let
> sleeping dogs lie.  The only time it'd make any difference would be
> when pages out of a block request somehow get attached to network
> packets, which seems unlikely.
>   

Block lifetimes are simpler because there's no cloning and bios have a
end_io callback which is more or less equivalent to the skb destructor.

    J

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