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