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

[Ian Campbell <ian.campbell@citrix.com>]

(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@lists.xen.org
http://lists.xen.org/xen-devel