|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH 2/3] public/io/netif.h: document control ring and toeplitz hashing
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
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |