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:b...@ovn.org] > Sent: Monday, 25 September, 2017 18:48 > To: Jan Scheurich <jan.scheur...@ericsson.com> > Cc: Nitin Katiyar <nitin.kati...@ericsson.com>; ovs-dev@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-boun...@openvswitch.org > > > [mailto:ovs-dev-boun...@openvswitch.org] On Behalf Of Ben Pfaff > > > Sent: Monday, 25 September, 2017 17:31 > > > To: Nitin Katiyar <nitin.kati...@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. > > _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
