[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |