xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Dario Faggioli <dario.faggioli@citrix.com>
To: Stefano Stabellini <stefano@aporeto.com>, xen-devel@lists.xenproject.org
Cc: wei.liu2@citrix.com
Subject: Re: [DOC v1] Xen transport for 9pfs
Date: Thu, 1 Dec 2016 11:56:48 +0100	[thread overview]
Message-ID: <1480589808.3445.15.camel@citrix.com> (raw)
In-Reply-To: <alpine.DEB.2.10.1611221126340.21858@sstabellini-ThinkPad-X260>


[-- Attachment #1.1: Type: text/plain, Size: 3360 bytes --]

On Tue, 2016-11-29 at 15:34 -0800, Stefano Stabellini wrote:
> ### Frontend XenBus Nodes
> 
>     num-rings
>          Values:         <uint32_t>
>     
>          Number of rings. It needs to be lower or equal to max-rings.
>     
>     port-<num> (port-0, port-1, etc)
>          Values:         <uint32_t>
>     
>          The identifier of the Xen event channel used to signal
> activity
>          in the ring buffer. One for each ring.
>     
>     ring-ref-<num> (ring-ref-0, ring-ref-1, etc)
>
blkif uses ring-ref%u, rather than ring-ref-%u (i.e., no dash before
the index). Not a big deal, I guess, but I thought it could be nice to
be a bit more uniform.

>          Values:         <uint32_t>
>     
>          The Xen grant reference granting permission for the backend
> to
>          map a page with information to setup a share ring. One for
> each
>          ring.
> 
So, this means there can be multiple rings (up to max-rings advertised
by backend), _each_of_which_ has its own event channel, and
_each_of_which_ can be a multi-page (in case ring_order > 0) ring... Is
this correct?

If it is, what's the typical envisioned use of these multiple rings, if
I can ask?

(Maybe it's obvious, I'm still not so familiar with these protocols..
but I'm trying to improve, and that's why I'm here, so bear with me if
possible. :-D)

> ## 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;
>     	XEN_9PFS_RING_IDX out_cons, out_prod;
>     
>     	uint32_t ring_order;
>     	grant_ref_t ref[];
>     };
> 
>     /* not actually C compliant (ring_order changes from socket to
> socket) */
>     struct ring_data {
>         char in[((1 << ring_order) << PAGE_SHIFT) / 2];
>         char out[((1 << ring_order) << PAGE_SHIFT) / 2];
>     };
>
Sorry, what does "ring_order changes from socket to socket" mean?

> The binary layout of `struct xen_9pfs_intf` follows:
> 
>     0         4         8         12        16        20
>     +---------+---------+---------+---------+---------+
>     | in_cons | in_prod |out_cons |out_prod |ring_orde|
>     +---------+---------+---------+---------+---------+
> 
>     20        24        26      4092      4096
>     +---------+---------+----//---+---------+
>     |  ref[0] |  ref[1] |         |  ref[N] |
>     +---------+---------+----//---+---------+
> 
> **N.B** For one page, N is maximum 1019 ((4096-20)/4), but given that
> N
> needs to be a power of two, actually max N is 512.
>
It may again be me being still too naive, but I'd quickly add at least
another example, with the value of N computed for a multiple pages
ring. Something like: "For 4 pages (i.e., ring_orfer=2), N is..."

Regards,
Dario
-- 
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)

[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

[-- Attachment #2: Type: text/plain, Size: 127 bytes --]

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

  parent reply	other threads:[~2016-12-01 10:56 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-11-29 23:34 [DOC v1] Xen transport for 9pfs Stefano Stabellini
2016-11-30 10:59 ` David Vrabel
2016-12-02  0:29   ` Stefano Stabellini
2016-12-02 10:45     ` David Vrabel
2016-12-02 21:45       ` Stefano Stabellini
2016-12-02 10:57     ` Andrew Cooper
2016-12-01 10:56 ` Dario Faggioli [this message]
2016-12-01 23:14   ` Stefano Stabellini
2016-12-02  8:54     ` Dario Faggioli
2016-12-02 22:01       ` Stefano Stabellini

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1480589808.3445.15.camel@citrix.com \
    --to=dario.faggioli@citrix.com \
    --cc=stefano@aporeto.com \
    --cc=wei.liu2@citrix.com \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).