Re: [Xen-devel] [RFC][PATCH 0/5] Add V4V to Xen

[Jean Guyader <jean.guyader@xxxxxxxxxx>]

On 28/06 11:50, Tim Deegan wrote:
> 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?
> 

Yes sorry that is right. On send a get a pointer from the guest
and then Xen memcpy the data on the receiver's ring.

So the second copy that will probably happened between the ring
and some memory in the receiver will be mostly free.

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

Maybe if you ring is big enough and if the guest sends very big buffer to be
copied that will makes sence to use async copy like i/oat or DMA.

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


Jean


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel