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

[Paul Durrant <Paul.Durrant@citrix.com>]

> -----Original Message-----
> From: Ian Campbell [mailto:ian.campbell@citrix.com]
> Sent: 16 February 2016 14:13
> To: Paul Durrant; xen-devel@lists.xenproject.org
> Cc: Ian Jackson; Jan Beulich; Keir (Xen.org); Tim (Xen.org)
> Subject: Re: [PATCH v2] public/io/netif.h: make control ring hash protocol
> more general
> 
> 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 could change things to allow for a non power-of-two hash table now, so I'll do that so as not to rule it out. And with that, of course, you can provide a table to give a simple hash-mod-N mapping.

  Paul

> 
> 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