Lines Matching refs:ring
52 supported by the backend. The size of every ring is also configurable
88 max-ring-page-order
134 in the ring buffer. One for each ring.
136 ring-ref<num> (ring-ref0, ring-ref1, etc)
140 map a page with information to setup a share ring. One for each
141 ring.
153 request ring. |
163 - Connect to the request ring and
179 ring, which are used to setup the rings, and an event channel per ring,
230 /* not actually C compliant (ring_order changes from ring to ring) */
237 It represents the order of the data ring. The following list of grant
239 **max-ring-page-order**, as specified by the backend on XenBus.
278 the maximum possible max-ring-page-order value is 9.
280 The binary layout of the ring buffers follow:
287 ## Why ring.h is not needed
289 Many Xen PV protocols use the macros provided by [ring.h] to manage
290 their shared ring for communication. This procotol does not, because it
291 actually comes with two rings: the **in** ring and the **out** ring.
293 the producer writes opaque data to the ring. On the other end, in
294 [ring.h] they are combined, and the request size is static and
300 In the case of the **in** ring, the frontend is the consumer, and the
302 **out** ring.
305 ring. In fact, the producer doesn't need any notifications unless the
306 ring is full. This version of the protocol doesn't take advantage of it,
310 is already actively reading from the ring. The producer can figure it
313 what [ring.h] does.
408 the *in* array of the same ring, following the producer workflow as
409 usual. Thus, every request/response pair is on one ring.
419 [ring.h]: http://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=xen/include/public/io/ring.h;hb=HEAD