Re: [Xen-devel] [DOC v3] Xen transport for 9pfs

[Stefano Stabellini <stefano@xxxxxxxxxxx>]

On Fri, 27 Jan 2017, Konrad Rzeszutek Wilk wrote:
> > > 
> > > ## 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?

They cannot work because they require fixed length messages.


> > Could you explain more what '[in|out]_event' ?

I'll write more about them in reply to your other email, but they are
just an optimization to remove unnecessary event notifications. In fact
the first version I sent didn't have them
(http://marc.info/?l=xen-devel&m=148046256107032).


> > Also would it be possible to re-organize this structure
> > so there are no cache bounces?

I'll separate in and out indexes.


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

They only work with fixed length messages.


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

This is something that has been tried and true: it is based on the Xen
console ring with only few modifications. See
xen/include/public/io/console.h. The [in|out]_event things are optional
optimizations.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel