From mboxrd@z Thu Jan  1 00:00:00 1970
From: David Vrabel <david.vrabel@citrix.com>
Subject: Re: [PATCH 2/3] public/io/netif.h: document control
 ring and toeplitz hashing
Date: Mon, 4 Jan 2016 10:55:52 +0000
Message-ID: <568A4FB8.7070100@citrix.com>
References: <1450865195-12883-1-git-send-email-paul.durrant@citrix.com>
	<1450865195-12883-3-git-send-email-paul.durrant@citrix.com>
	<567AA148.4070207@citrix.com>
	<9AAE0902D5BC7E449B7C8E4E778ABCD02F711A79@AMSPEX01CL01.citrite.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <prvs=8047ed68d=david.vrabel@citrix.com>)
	id 1aG2nu-0007g9-Bb
	for xen-devel@lists.xenproject.org; Mon, 04 Jan 2016 10:55:58 +0000
In-Reply-To: <9AAE0902D5BC7E449B7C8E4E778ABCD02F711A79@AMSPEX01CL01.citrite.net>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: Paul Durrant <Paul.Durrant@citrix.com>, David Vrabel <david.vrabel@citrix.com>, "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Cc: "Keir (Xen.org)" <keir@xen.org>, "Tim (Xen.org)" <tim@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>, Jan Beulich <jbeulich@suse.com>, Ian Jackson <Ian.Jackson@citrix.com>
List-Id: xen-devel@lists.xenproject.org

On 04/01/16 09:37, Paul Durrant wrote:
>>> + * The layout of the shared page is as follows:
>>> + *
>>> + *    0     1     2     3     4     5     6     7  octet
>>> + * +-----+-----+-----+-----+-----+-----+-----+-----+
>>> + * |        req_cons       |        req_prod       |
>>> + * +-----+-----+-----+-----+-----+-----+-----+-----+
>>> + * |        rsp_cons       |        rsp_prod       |
>>> + * +-----+-----+-----+-----+-----+-----+-----+-----+
>>> + * |                                               |
>>> + * +                                               +
>>> + * |                      req[1024]                |
>>> + *                         .
>>> + *                         .
>>> + * |                                               |
>>> + * +-----+-----+-----+-----+-----+-----+-----+-----+
>>> + * |                                               |
>>> + * +                                               +
>>> + * |                      rsp[1024]                |
>>> + *                         .
>>> + *                         .
>>> + * |                                               |
>>> + * +-----+-----+-----+-----+-----+-----+-----+-----+
>>
>> You should use the standard ring format and infrastructure.
> 
> Is there one for variable message size rings? I didn't find one. I
> don't want to use the fixed size balanced ring macros for control
> messages as fixed size messages really aren't appropriate in this case.

Perhaps union the request/response message types with a uint8_t
pad[1024] and use this as the request/response type?

You can use the standard macros like so (to avoid copying the full 1024
bytes every time):

hdr = RING_GET_REQUEST(...);
switch (READ_ONCE(hdr->type)) {
case FOO:
    {
        struct foo foo;
        RING_COPY_REQUEST(ring, cons, &foo);
        handle_foo(&foo);
    }
    break;
case ...:
    ...
}

David