[ovs-dev] Proposal for enabling dp_hash irrespective of OF version

[Jan Scheurich]

With the proposed bridge configuration option in OVS a controller need not be impacted at all. The controller just programs the OF switch using standard Group Mod messages. The select group implementation is an OVS-internal detail that only affects its characteristics.

The static bridge configuration is typically applied at the time when OVS is deployed on the servers in the DC. The cloud supplier/provider would choose the select group implementation that is most suitable for the targeted use cases. 

If your main concern is the introduction of a bridge-level configuration option that might affect the behavior and require testing of both variants, I would suggest to change the hard-coded default implementation to dp_hash. OVS' bond selection logic uses the same mechanism also, so it should be mature enough. We can add some heuristics to fall back to the legacy select group implementation in the case of many buckets (say more than 32) or very uneven weights, so that a dp_hash implementation with 64 slots provides a reasonable accurate distribution.

BR, Jan

> From: Ben Pfaff [mailto:blp at ovn.org]
> Sent: Thursday, 28 September, 2017 17:16
> 
> Hmm, OK.
> 
> Dropping back to a previous suggestion, why do you think it is a big
> deal for a controller to use OF1.5 style group_mods in OF1.1 to OF1.4?
> It is generally a simple matter of sending a different header indicating
> a Nicira Extension.  The controller will need modification in any case
> to support this new feature.  It's better, in my opinion, to support all
> the features of OF1.5 rather than to add them piecemeal in scattered
> places over time.
> 
> On Tue, Sep 26, 2017 at 03:27:24PM +0000, Jan Scheurich wrote:
> > Hi Ben,
> >
> > As usual there is a trade-off scalability vs. max performance: The dp_hash selection method avoids the upcalls and micro-megaflows for
> the price of an additional recirculation.
> >
> > I guess that is why Jarno didn't want to make it the default selection method in the first place. It might have broken characteristics
> assumed by previous users of select groups.
> >
> > Personally I have no strong objection against hard-coding the dp_hash scheme as new default, but there might be users whose use cases
> do not require scalability and determinism.
> >
> > BR, Jan
> >
> > > -----Original Message-----
> > > From: Ben Pfaff [mailto:blp at ovn.org]
> > > Sent: Monday, 25 September, 2017 18:48
> > > To: Jan Scheurich <jan.scheurich at ericsson.com>
> > > Cc: Nitin Katiyar <nitin.katiyar at ericsson.com>; ovs-dev at openvswitch.org
> > > Subject: Re: [ovs-dev] Proposal for enabling dp_hash irrespective of OF version
> > >
> > > If the new selection method is superior to the default one, is there a
> > > reason to require the controller to select it at all?
> > >
> > > On Mon, Sep 25, 2017 at 04:28:26PM +0000, Jan Scheurich wrote:
> > > > Hi Ben,
> > > >
> > > > The current hard-coded default select group implementation requires every single L4 flow to be load-balanced in an upcall and
> creates
> > > a dedicated megaflow for every 5-tuple. This is clearly not scalable in deployments where the number of parallel L4 flows and the L4
> flow
> > > setup rate is unknown and cannot be controlled (e.g. in Telco cloud deployments where the VNFs carry end-user traffic).
> > > >
> > > > We need a scalable select group implementation to implement distributed ECMP L3 forwarding in OVS. The dp_hash based
> > > implementation is mostly already in place, thanks to Jarno, but its use is unfortunately tied to an OF 1.5 Group Mod extension that our
> > > controllers do not support.
> > > >
> > > > Our aim with this proposal is to provide a scalable select group implementation in OVS for any OpenFlow controller. As there is no
> > > functional difference between the original selection method and the dp_hash based one, I don't see a reason why the controller should
> > > have to be involved for choosing one or the other. This is different in nature from the extension to specify the hash fields for the
> bucket
> > > selection.
> > > >
> > > > As Cloud provider we would like to be able to configure OVS to by default use apply the scalable dp_hash selection method, unless
> the
> > > controller specifies something else. A natural place seems to be to add this as a bridge property.
> > > >
> > > > Regards, Jan
> > > >
> > > > N.B.  The pre-OF 1.5 Group Mod message simply has no extension mechanism to carry addition group properties. We would have to
> add
> > > a proprietary new NX Group Mod message, which would not make life much simpler for controllers.
> > > >
> > > > > -----Original Message-----
> > > > > From: ovs-dev-bounces at openvswitch.org [mailto:ovs-dev-bounces at openvswitch.org] On Behalf Of Ben Pfaff
> > > > > Sent: Monday, 25 September, 2017 17:31
> > > > > To: Nitin Katiyar <nitin.katiyar at ericsson.com>
> > > > >
> > > > > This proposes adding a default selection method that could be set via
> > > > > OVSDB.  This would probably work (I have not thought through the
> > > > > implications), but the usual way that we would solve this kind of thing
> > > > > in OVS is by making the features of the OF1.5 group_mod available in
> > > > > earlier versions.
> > > >