[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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.