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

[Ian Campbell <ian.campbell@xxxxxxxxxx>]

(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