On Fri, Dec 12, 2014 at 12:26:38PM +0900, Simon Horman wrote: > On Thu, Dec 11, 2014 at 07:16:36PM -0800, Ben Pfaff wrote: > > On Fri, Dec 12, 2014 at 12:09:25PM +0900, Simon Horman wrote: > > > 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? > > > > I don't know. > > > > I see two ways we could viably go here (I take back the bit ranges, > > that's a bad idea): > > > > * Just a list of OXM fields, and don't worry about masks. > > > > * A list of OXM fields, each one followed by an appropriately > > sized mask. > > > > The latter case starts to look a little like a flow, but I don't think > > that it is really is because you don't have any prerequisites and in > > fact you can have contradictory fields (e.g. both UDP and TCP). > > I wonder if we could take an incremental approach. First implement > the list of fields, then try adding the masks as you suggest.
That's fine as long as we lock down the wire format before we branch for release. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
