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

> >> 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.

> > I needed to make some changes to netback to make forwarding packets
> > between NC1 and NC2 interfaces work, but apart from that it's fairly
> > self-contained.  Would you like me to rebase to
> > xen/dom0/backend/netback?
> An outstanding problem with netback is how we can deal with "foreign"
> pages in dom0's network stack.  The current approach isn't viable for
> upstream, but there has only been slow movement in coming up with a
> better approach.
> 
> I haven't looked at nc2 yet, but does it use the same technique for
> memory management, or something else?
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.

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.

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.

Steven.

Attachment: signature.asc
Description: Digital signature

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