[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] Poor network performance between DomU with multiqueue support



On Mon, Dec 08, 2014 at 06:44:26AM +0000, Zhangleiqiang (Trump) wrote:
> > On Fri, Dec 05, 2014 at 01:17:16AM +0000, Zhangleiqiang (Trump) wrote:
> > [...]
> > > > I think that's expected, because guest RX data path still uses
> > > > grant_copy while guest TX uses grant_map to do zero-copy transmit.
> > >
> > > As far as I know, there are three main grant-related operations used in 
> > > split
> > device model: grant mapping, grant transfer and grant copy.
> > > Grant transfer has not used now, and grant mapping and grant transfer both
> > involve "TLB" refresh work for hypervisor, am I right?  Or only grant 
> > transfer
> > has this overhead?
> > 
> > Transfer is not used so I can't tell. Grant unmap causes TLB flush.
> > 
> > I saw in an email the other day XenServer folks has some planned improvement
> > to avoid TLB flush in Xen to upstream in 4.6 window. I can't speak for sure 
> > it will
> > get upstreamed as I don't work on that.
> > 
> > > Does grant copy surely has more overhead than grant mapping?
> > >
> > 
> > At the very least the zero-copy TX path is faster than previous copying 
> > path.
> > 
> > But speaking of the micro operation I'm not sure.
> > 
> > There was once persistent map prototype netback / netfront that establishes 
> > a
> > memory pool between FE and BE then use memcpy to copy data. Unfortunately
> > that prototype was not done right so the result was not good.
> 
> The newest mail about persistent grant I can find is sent from 16 Nov
> 2012
> (http://lists.xen.org/archives/html/xen-devel/2012-11/msg00832.html).
> Why is it not done right and not merged into upstream?

AFAICT there's one more memcpy than necessary, i.e. frontend memcpy data
into the pool then backend memcpy data out of the pool, when backend
should be able to use the page in pool directly.

> 
> And I also search for virtio support in XEN, and I find that the one
> who are familiar with it is you, too,
> (http://wiki.xen.org/wiki/Virtio_On_Xen), :-). I am wondering what is
> the current state for virtio on XEN?

Yes, it was me. I never have the time to revisit that. I don't think we
support virtio network at the moment.

Wei.

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.