* shared rings. rsp_cons, rsp_events, req_prod, req_events docs, charts, timelines?
@ 2011-05-16 17:05 Konrad Rzeszutek Wilk
2011-05-16 20:03 ` Daniel Stodden
0 siblings, 1 reply; 3+ messages in thread
From: Konrad Rzeszutek Wilk @ 2011-05-16 17:05 UTC (permalink / raw)
To: xen-devel, Ian Campbell, daniel.stodden, keir, JBeulich
The current ring implementation uses these values and then macros such
as RING_HAS_UNCONSUMED_REQUESTS, FINAL_RING_CHECK, etc to determine whether
to continue or how to control the flow. Looking way back in the history
at c/s 8153 it used to have a 'server_is_sleeping' value to determine whether
to kick the back (now called 'req_event'), and the 'rsp_event' (unchanged)
to kick the frontend.
Anyhow, are there any diagrams or design docs documenting how these simple four
shared values help to control the pipeline and interrupt generation? Or how
they evolved over time to become what they are right now?
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: shared rings. rsp_cons, rsp_events, req_prod, req_events docs, charts, timelines?
2011-05-16 17:05 shared rings. rsp_cons, rsp_events, req_prod, req_events docs, charts, timelines? Konrad Rzeszutek Wilk
@ 2011-05-16 20:03 ` Daniel Stodden
2011-05-16 21:16 ` Konrad Rzeszutek Wilk
0 siblings, 1 reply; 3+ messages in thread
From: Daniel Stodden @ 2011-05-16 20:03 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk
Cc: Ian, Campbell, xen-devel@lists.xensource.com, keir@xen.org,
JBeulich@novell.com
On Mon, 2011-05-16 at 13:05 -0400, Konrad Rzeszutek Wilk wrote:
> The current ring implementation uses these values and then macros such
> as RING_HAS_UNCONSUMED_REQUESTS, FINAL_RING_CHECK, etc to determine whether
> to continue or how to control the flow. Looking way back in the history
> at c/s 8153 it used to have a 'server_is_sleeping' value to determine whether
> to kick the back (now called 'req_event'), and the 'rsp_event' (unchanged)
> to kick the frontend.
>
> Anyhow, are there any diagrams or design docs documenting how these simple four
> shared values help to control the pipeline and interrupt generation? Or how
> they evolved over time to become what they are right now?
Iirc, I've known these headers since late xen 2.x versions and never saw
it done differently (i.e. req/rsp_event, and symmetrically).
Never saw dedicated documentation either, but found the header comments
and sources sufficient.
Do you just want documentation to point at, or is there something not
clear about them?
Daniel
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: shared rings. rsp_cons, rsp_events, req_prod, req_events docs, charts, timelines?
2011-05-16 20:03 ` Daniel Stodden
@ 2011-05-16 21:16 ` Konrad Rzeszutek Wilk
0 siblings, 0 replies; 3+ messages in thread
From: Konrad Rzeszutek Wilk @ 2011-05-16 21:16 UTC (permalink / raw)
To: Daniel Stodden
Cc: Ian Campbell, xen-devel@lists.xensource.com, keir@xen.org,
JBeulich@novell.com
On Mon, May 16, 2011 at 01:03:07PM -0700, Daniel Stodden wrote:
> On Mon, 2011-05-16 at 13:05 -0400, Konrad Rzeszutek Wilk wrote:
> > The current ring implementation uses these values and then macros such
> > as RING_HAS_UNCONSUMED_REQUESTS, FINAL_RING_CHECK, etc to determine whether
> > to continue or how to control the flow. Looking way back in the history
> > at c/s 8153 it used to have a 'server_is_sleeping' value to determine whether
> > to kick the back (now called 'req_event'), and the 'rsp_event' (unchanged)
> > to kick the frontend.
> >
> > Anyhow, are there any diagrams or design docs documenting how these simple four
> > shared values help to control the pipeline and interrupt generation? Or how
> > they evolved over time to become what they are right now?
>
> Iirc, I've known these headers since late xen 2.x versions and never saw
> it done differently (i.e. req/rsp_event, and symmetrically).
>
> Never saw dedicated documentation either, but found the header comments
> and sources sufficient.
>
> Do you just want documentation to point at, or is there something not
> clear about them?
I was hoping to be able to double-check what I groked from the code. Figured
an example of the flow between frontend and backend over some time with
different scenarios would exist somwhere.
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2011-05-16 21:16 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-05-16 17:05 shared rings. rsp_cons, rsp_events, req_prod, req_events docs, charts, timelines? Konrad Rzeszutek Wilk
2011-05-16 20:03 ` Daniel Stodden
2011-05-16 21:16 ` Konrad Rzeszutek Wilk
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).