Lines Matching refs:ring
117 in the command ring.
119 ring-ref
123 the sole page in a single page sized command ring.
158 request ring. |
168 - Connect to the request ring and
184 will is used to exchange messages over a ring, and an event channel,
220 The shared ring is used by the frontend to forward POSIX function calls
221 to the backend. We shall refer to this ring as **commands ring** to
223 lifecycle of the protocol (see [Indexes Page and Data ring]). The grant
224 reference for shared page for this ring is shared on xenstore (see
225 [Frontend XenBus Nodes]). The ring format is defined using the familiar
226 `DEFINE_RING_TYPES` macro (`xen/include/public/io/ring.h`). Frontend
227 requests are allocated on the ring using the `RING_GET_REQUEST` macro.
327 Similarly to other Xen ring based protocols, after writing a request to
328 the ring, the frontend calls `RING_PUSH_REQUESTS_AND_CHECK_NOTIFY` and
331 Backend responses are allocated on the ring using the `RING_GET_RESPONSE` macro.
437 The connect operation creates a new shared ring, which we'll call **data
438 ring**. The data ring is used to send and receive data from the
442 ring. **ref** is the grant reference of the **indexes page**: a page
444 in the **data ring**. The **indexes page** also contains the full array
445 of grant references for the **data ring**. When the frontend issues a
453 uses them as shared memory for the **data ring**
457 The [Indexes Page and Data ring] format will be described in the
458 following section. The **data ring** is unmapped and freed upon issuing
471 - **evtchn**: port number of the evtchn to signal activity on the **data ring**
505 issued for an active socket, the data ring and indexes page are also
510 - backend unmaps the data ring
514 - frontend frees data ring, indexes page and unbinds event channel
524 (indexes page and data ring) and event channel when creating one of
645 Page and Data ring]. The **data ring** is used to send and receive data from
649 ring. **ref** is the grant reference of the **indexes page**: a page
651 in the **data ring**. The **indexes page** also contains the full array of
652 grant references for the **data ring**.
669 ring **in** and **out** arrays
680 - **evtchn**: port number of the evtchn to signal activity on the data ring
851 ### Indexes Page and Data ring
856 receiving data from a data ring, and updating the corresponding indexes
863 constitute the **in** and **out** buffers of the data ring, see ref[]
867 buffers for transferring data, and, together, they are the data ring.
871 | Command ring: | +----------------------+
880 v (data ring)
916 It represents the order of the data ring. The following list of grant
949 ring as soon as it is available).
968 The binary layout of the data ring follow:
975 #### Why ring.h is not needed argument
977 Many Xen PV protocols use the macros provided by [ring.h] to manage
978 their shared ring for communication. PVCalls does not, because the [Data
979 Ring Structure] actually comes with two rings: the **in** ring and the
980 **out** ring. Each of them is mono-directional, and there is no static
981 request size: the producer writes opaque data to the ring. On the other
982 end, in [ring.h] they are combined, and the request size is static and
988 In the case of the **in** ring, the frontend is the consumer, and the
990 **out** ring.
993 ring. In fact, the producer doesn't need any notifications unless the
994 ring is full. This version of the protocol doesn't take advantage of it,
998 is already actively reading from the ring. The producer can figure it
1001 what [ring.h] does.
1092 [ring.h]: http://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=xen/include/public/io/ring.h;hb=HEAD