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

Ben Pfaff blp at ovn.org
Thu Sep 28 15:15:37 UTC 2017


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


More information about the dev mailing list