[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [DOC v3] Xen transport for 9pfs
> > > > ## Ring Setup > > > > The shared page has the following layout: > > > > typedef uint32_t XEN_9PFS_RING_IDX; > > > > struct xen_9pfs_intf { > > XEN_9PFS_RING_IDX in_cons, in_prod, in_event; > > XEN_9PFS_RING_IDX out_cons, out_prod, out_event; > > > > uint32_t ring_order; > > /* this is an array of (1 << ring_order) elements */ > > grant_ref_t ref[1]; > > }; > > Could you explain why DEFINE_RING_TYPES would not work? > > Could you explain more what '[in|out]_event' ? > > Also would it be possible to re-organize this structure > so there are no cache bounces? This, along with a similar layout in the PV Calls got me thinking. Why aren't you using the standard old fashioned DEFINE_RING_TYPES. And if there is something wrong with it - why not use something that has been tried and true. Like the VirtIO available and used ring? That has the idea of 'avail_even't as an index. And also it provides two nice pages where one is written by the frontend while the other by the backend. Which nicely takes into account cache bounces. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx https://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |