|
[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 |