From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tim Deegan Subject: Re: [RFC][PATCH 0/5] Add V4V to Xen Date: Thu, 28 Jun 2012 11:50:33 +0100 Message-ID: <20120628105033.GC34995@ocelot.phlegethon.org> References: <20120613104858.GC23207@boiler.cam.xci-test.com> <20120613114427.GA21809@ocelot.phlegethon.org> <20120614145608.GG90181@ocelot.phlegethon.org> <20120614151043.GB24063@spongy> <20120614153556.GI90181@ocelot.phlegethon.org> <20120625090537.GC1488@ocelot.phlegethon.org> <1340721486.3832.145.camel@zakaz.uk.xensource.com> <20120628103858.GB7935@spongy> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <20120628103858.GB7935@spongy> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jean Guyader Cc: Ian Campbell , Jean Guyader , "xen-devel@lists.xen.org" List-Id: xen-devel@lists.xenproject.org At 11:38 +0100 on 28 Jun (1340883538), Jean Guyader wrote: > On 26/06 03:38, Ian Campbell wrote: > > Lastly -- have you given any thoughts to making the copy operation > > asynchronous? This might allow us to take advantage of copy offload > > hardware in the future? > > A CPU copy already has to happen once in the guest to put it in the > ring I don't understand -- isn't the vector-send operation designed to have Xen do a single copy from scattered sources into the destination ring? So the sender could be zero-copy? > so the second copy that is done in Xen will be really cheap because > it's very linkely going to be in the cache. I don't doing async copy > in Xen will have a huge impact on the performance. Using a DMA engine to do the copy could free up CPU cycles that Xen could use for other vcpus, so even if there isn't a throughput increase on the v4v channel, there could be a benefit to the system as a whole. We could do that with synchronous copies, pausing the vcpu while the copy happens, but I think to get full throughput we'd want to pipeline a few writes ahead. Anyway, that's all very forward-looking: AFAICS there's no need to address it right now except to be careful not to bake things into the interface that would stop us doing this later on. Cheers, Tim.