>>> On 18.01.16 at 17:07, <ian.campb...@citrix.com> 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@lists.xen.org http://lists.xen.org/xen-devel
