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

[Steven Smith <steven.smith@xxxxxxxxxx>]

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