On Thu, Dec 11, 2014 at 07:02:29PM -0800, Ben Pfaff wrote: > On Fri, Dec 12, 2014 at 11:31:50AM +0900, Simon Horman wrote: > > On Thu, Dec 11, 2014 at 11:49:33AM -0800, Ben Pfaff wrote: > > > On Wed, Nov 19, 2014 at 09:44:58AM +0900, Simon Horman wrote: > > > > NMX selection method > > > > Signed-off-by: Simon Horman <simon.hor...@netronome.com> > > > > > > I'm not sure that it makes sense to check the prerequisites. It's easy > > > to imagine wanting to use fields as part of the selection method when > > > they are present, and simply omitting them when they are not. TCP ports > > > are one obvious example (you probably still want to be able to pass > > > non-TCP flows through the group); the IPv6 flow id is another. > > > > Thanks, that was not something that I had considered. > > > > I was thinking more of a scenario where matches and groups > > were closely tied. So the scenario you describe would involve > > different groups with different fields though possibly their buckets > > would be identical. > > I see. The use case that I had in mind was to use a group as part of > the implementation of a more general construct like a LAG. I know of > one part of Open vSwitch that already behaves like this: the > eviction_fields in an oftable. Those already have a hashing function > (see eviction_group_hash_rule()) and so there might be something in > common there.
Thanks, I'll look into that. I do see the value of grouping things (i.e. the group in "groups"). > In the discussion of patch 2 you brought up the reason for a mask. I > see that the eviction group code uses bit ranges for a similar purpose. Thanks, I wasn't aware of that. I will look into it. Do you feel that approach could be useful here too? _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
