Re: [Xen-devel] [PATCH v7 2/2] public/io/netif.h: document control ring and toeplitz hashing

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 18.01.16 at 17:07, <ian.campbell@xxxxxxxxxx> wrote:
> On Tue, 2016-01-12 at 09:58 +0000, Paul Durrant wrote:
>> + * NETIF_CTRL_TYPE_SET_TOEPLITZ_MAPPING
>> + * ------------------------------------
>> + *
>> + * This is sent by the frontend to set the content of the table mapping
>> + * toeplitz hash value to queue number. The backend should calculate the
>> + * hash from the packet header, use it as an index into the table (modulo
>> + * the size of the table) and then steer the packet to the queue number
>> + * found at that index.
>> + *
>> + * Request:
>> + *
>> + *  type    = NETIF_CTRL_TYPE_SET_TOEPLITZ_MAPPING
>> + *  data[0] = grant reference of page containing the mapping (sub-)table
>> + *            (assumed to start at beginning of grant)
>> + *  data[1] = size of (sub-)table in entries
>> + *  data[2] = offset, in entries, of sub-table within overall table
> 
> Adding data[2] seems reasonable to me, but if you wanted to avoid adding it
> then saying data[1][8:0] == size and data[1][31:9] == offset would allow a
> size of 512 (biggest possible in a single gref) and 8.3M for the offset.

I may be lacking some context here, so please ignore if it reads
like nonsense, but is the 9-bit width bound to a page size of 4k,
or an inherent property of the Toeplitz algorithm? In the former
case I think we should try to avoid putting further limitations to
4k pages into any interface. (And as an aside, 512 is also not
representable in 9 bits, but this can clearly be addressed quite
easily.)

Jan


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