[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v7 2/2] public/io/netif.h: document control ring and toeplitz hashing
(Re-adding the list and full quoting since I think that was just a button- o) On Mon, 2016-01-18 at 16:24 +0000, Paul Durrant wrote: > > -----Original Message----- > [snip] > > > > I noticed (after trimming the quotes unfortunately) that the request gained > > a data[2] in v5 (as part of handling the table differently), so the req + > > rsp are no longer the same size. > > > > I'm not sure if that is worth worrying about. I don't think it would > > simplify anything to include a padding bit, but it might be nice? > > > > The ring macros take the max of the req and rsp so I'd like to leave out > explicit padding. > > > > > > > + * 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. > > > > Probably better to leave data[2] in there. > > > Do the updates tend to come in large batches, or is setting single entries > > or small runs of contiguous entries the norm? I suspect you are trying to > > avoid copying 4K worth of data ofr each update when only a couple of > > entries have changed, is that right? > > Updates are fairly infrequent and, in my experience, only tend to modify a > handful of entries. For a small table (which basic RSS has now, at 127 > entries) it's probably not worth the complexity of sending the diffs but if > we move onto newer RSS versions with larger tables in the future we have that > option. > > > > > All the above are just suggestions, which you are free to ignore, so if you > > prefer things as they are that's fine by me: > > > > I think that it's good enough as it is. Thanks for the thorough review! Right, applied then, thanks! _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |