Date: Tue, 9 Jul 2013 19:38:43 +0100
From: Wei Liu <wei.liu2@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
CC: Roger Pau =?iso-8859-1?Q?Monn=E9?= <roger.pau@citrix.com>,
        <linux-kernel@vger.kernel.org>, <xen-devel@lists.xen.org>,
        <wei.liu2@citrix.com>
Subject: Re: [Xen-devel] [PATCH RFC 4/4] xen-block: introduce a new request
 type to unmap grants
Message-ID: <20130709183843.GA8754@zion.uk.xensource.com>
References: <1373288607-1876-1-git-send-email-roger.pau@citrix.com>
 <1373288607-1876-5-git-send-email-roger.pau@citrix.com>
 <20130708194152.GJ4927@phenom.dumpdata.com>
 <51DC3C66.2030606@citrix.com>
 <20130709183207.GA9924@phenom.dumpdata.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20130709183207.GA9924@phenom.dumpdata.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 3207
Lines: 73

On Tue, Jul 09, 2013 at 02:32:07PM -0400, Konrad Rzeszutek Wilk wrote:
> On Tue, Jul 09, 2013 at 06:37:58PM +0200, Roger Pau Monn? wrote:
> > On 08/07/13 21:41, Konrad Rzeszutek Wilk wrote:
> > > On Mon, Jul 08, 2013 at 03:03:27PM +0200, Roger Pau Monne wrote:
> > >> Right now blkfront has no way to unmap grant refs, if using persistent
> > >> grants once a grant is used blkfront cannot assure if blkback will
> > >> have this grant mapped or not. To solve this problem, a new request
> > >> type (BLKIF_OP_UNMAP) that allows requesting blkback to unmap certain
> > >> grants is introduced.
> > > 
> > > I don't think this is the right way of doing it. It is a new operation
> > > (BLKIF_OP_UNMAP) that has nothing to do with READ/WRITE. All it is
> > > is just some way for the frontend to say: unmap this grant if you can.
> > > 
> > > As such I would think a better mechanism would be to have a new
> > > grant mechanism that can say: 'I am done with this grant you can
> > > remove it' - that is called to the hypervisor. The hypervisor
> > > can then figure out whether it is free or not and lazily delete it.
> > > (And the guest would be notified when it is freed).
> > 
> > I would prefer not to involve the hypervisor in persistent grants, this
> > is something between the frontends and the backends. The hypervisor
> > already provides the basic operations (map/unmap), IMHO there's no need
> > to add more logic to the hypervisor itself.
> > 
> > I agree that it would be better to have a generic way to request a
> > backend to unmap certain grants, but so far this seems like the best
> > solution.
> 
> Lets concentrate on a generic way that any frontend/backend can use.
> 
> Please keep in mind that the indirect descriptors could be implemented by
> using mapped grants if a backend or frontend wanted to do it.
> 
> This all is tied in the 'feature-persistent-grant' and as that could be
> implemented in a similar fashion on netfront (perhaps by only doing it
> for one of the rings - the TX ring, or is it RX?).
> 
> > 
> > > 
> > > I would presume that this problem would also exist with netback/netfront
> > > if it started using persisten grants, right?
> > 
> > I'm not sure of that, it depends on the number of persistent grants
> > netfront/netback use, in the block case we need this operation because
> > of indirect descriptors, but netfront/netback might not suffer from this
> > problem if the maximum number of grants they use is relatively small.
> 
> 256 is the default amount of grants one ring can have. Since there is 
> a RX and TX ring that means we can have around 512 for one VIF.
> 
> I presume that with the multi-queue (not yet implemented) this can expand
> to be 512 * vCPU.
> 

Yes. We need to allow for some space for multiqueue as well as multi
page ring.


Wei.

> 
> > 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/