[ovs-dev] [PATCH/RFC 4/9] Check pre-requisites of selection method fields

Ben Pfaff blp at nicira.com
Fri Dec 12 03:16:36 UTC 2014


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.horman at 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).



More information about the dev mailing list