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/
Home Products Support Community News


RE: [Xen-devel] RFC: [0/2] Remove netloop by lazy copying in netback

To: "Santos, Jose Renato G" <joserenato.santos@xxxxxx>, "Ian Pratt" <Ian.Pratt@xxxxxxxxxxxx>, "Herbert Xu" <herbert@xxxxxxxxxxxxxxxxxxx>, "Keir Fraser" <Keir.Fraser@xxxxxxxxxxxx>
Subject: RE: [Xen-devel] RFC: [0/2] Remove netloop by lazy copying in netback
From: "Ian Pratt" <Ian.Pratt@xxxxxxxxxxxx>
Date: Tue, 27 Mar 2007 14:15:10 +0100
Cc: Xen Development Mailing List <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Tue, 27 Mar 2007 06:14:44 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
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/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <20070323031757.GA16250@xxxxxxxxxxxxxxxxxxx><C2295D45.C1E2%Keir.Fraser@xxxxxxxxxxxx> <20070323114217.GA19018@xxxxxxxxxxxxxxxxxxx> <8A87A9A84C201449A0C56B728ACF491E0B9EF3@xxxxxxxxxxxxxxxxxxxxxxxxxxx> <08CA2245AFCF444DB3AC415E47CC40AF92873F@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <8A87A9A84C201449A0C56B728ACF491E0B9F18@xxxxxxxxxxxxxxxxxxxxxxxxxxx> <08CA2245AFCF444DB3AC415E47CC40AF928B75@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcdtQK6+ElDZmjcVTH2RKryxth73qAAC160AABN60+AAAdjeEACWVWpgAB0oIiA=
Thread-topic: [Xen-devel] RFC: [0/2] Remove netloop by lazy copying in netback
> > Yep, the approach is similar, but I think having the
> > 'permanent' grants mechanism is probably a bit more flexible
> > for managing the header fragments.
> >
>   Not sure why it would be more flexible. Do you mean dealing with
> headers that are in fragments? If headers are in fragments they will
> linearized when copied into the shared header area by netfront. Also,
> seems to me that having a fixed set of pages at initialization that
> never change is easier to manage. I probably did not understand you
> correctly...

Netfront would copy the header out into a separate (small) fragment,
allocating it from a from a frame in the permanently mapped pool. 

Having a bit to indicate 'permanent' grants means that the header pool
is easily expanded at run time if need be, and seems a more generic
mechanism than having a bunch of frames agreed out-of-band at startup.


Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>