Re: [PATCH v2] public/io/netif.h: make control ring hash protocol more general

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

On Tue, 2016-02-16 at 14:02 +0000, Paul Durrant wrote:
> > -----Original Message-----
> [snip]
> > > 
> > > > >   *
> > > > > - * NETIF_CTRL_TYPE_SET_TOEPLITZ_MAPPING_ORDER
> > > > > - * ------------------------------------------
> > > > > + * NETIF_CTRL_TYPE_SET_HASH_MAPPING_ORDER
> > > > 
> > > > This one needs a similar "if the hash algorithm requires it"
> > > > wording
> > > > like the setting the key one had.
> > > > 
> > > 
> > > Why? Is there any point of doing hashing at all if the backend is not
> > > going to map it to a queue via a mapping table?
> > 
> > But will all hashing algorithms work via a table with a variable order?
> > 
> 
> My view is that the algorithm used to generate the hash (which is after
> all just a number) and then mapping that hash to a queue via a table are
> pretty separate. Do you have an example in mind where these things are
> more intertwined? (Maybe my view is too simplistic).

I don't know of a specific example, but was just trying to generalise along
the lines this was already heading in order to avoid future headaches when
trying to add new (perhaps not yet invented) schemes, e.g. to algorithms
with fixed numbers of queues, which support non-power of two table sizes or
which take the hash output mod N as the queue number without passing via a
table lookup phase etc.

I was concerned about retro fitting such things, but now I think about it
that would involve adding a new hash type and perhaps new ops for the
parameters of that hash, at which point the table size op could become
optional based on the hash type at that point too, without causing any
forward/backward compatibility concerns.

Ian.

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