All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.