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

Re: [Xen-devel] RFC v1: Xen block protocol overhaul - problem statement (with pictures!)



On Fri, 2013-01-18 at 18:20 +0000, Konrad Rzeszutek Wilk wrote:
> 
> > > E). The network stack has showed that going in a polling mode does improve
> > > performance. The current mechanism of kicking the guest and or block
> > > backend is not always clear.  [TODO: Konrad to explain it in details]
> 
> Oh, I never did explain this - but I think the patches that Daniel came
> up with actually fix a part of it. They make the kick-the-other guest
> only happen when the backend has processed all of the requests and
> cannot find anything else to do. Previously it was more of 'done one
> request, lets kick the backend.'.

blkback uses RING_PUSH_RESPONSES_AND_CHECK_NOTIFY so doesn't it get some
amount of evthcn mitigation for free?

> But going forward, this 'kick-the-other-guest' could be further modulated.
> If we have a full ring and the frontend keeps on adding entries we (backend)
> should never get an interrupt. As of matter of fact the frontend should be 
> just
> polling all the time and process them as fast as possible.

I think the existing req_event/rsp_event ring fields should enable this
already, assuming the front- and back-ends are using them right.

Ian.


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