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: [PATCH 00/17] Netchannel2 for a modern git kernel

To: Steven Smith <steven.smith@xxxxxxxxxx>
Subject: [Xen-devel] Re: [PATCH 00/17] Netchannel2 for a modern git kernel
From: Jeremy Fitzhardinge <jeremy@xxxxxxxx>
Date: Tue, 20 Oct 2009 15:00:04 +0900
Cc: Steven Smith <Steven.Smith@xxxxxxxxxxxxx>, Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Keir Fraser <Keir.Fraser@xxxxxxxxxxxxx>, "joserenato.santos@xxxxxx" <joserenato.santos@xxxxxx>
Delivery-date: Mon, 19 Oct 2009 23:00:39 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <20091007081510.GA14268@xxxxxxxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <cover.1254667618.git.ssmith@xxxxxxxxxxxxxxxxxxxxxxxxxx> <4AC92B44.5020208@xxxxxxxx> <20091005092937.GA1036@xxxxxxxxxxxxxxxxxxxxxxxxxx> <4ACA638A.5060209@xxxxxxxx> <20091006090616.GA21511@xxxxxxxxxxxxxxxxxxxxxxxxxx> <4ACB7909.7000804@xxxxxxxx> <20091007081510.GA14268@xxxxxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.4pre) Gecko/20090922 Fedora/3.0-2.7.b4.fc11 Lightning/1.0pre Thunderbird/3.0b4
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