Re: [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:b...@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 +, 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: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 +, 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.
> > > >
>

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

[Ben Pfaff]

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 +, 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: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 +, 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

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

[Jan Scheurich]

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 +, 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

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

[Ben Pfaff]

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 +, 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 
> > 
> > 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

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

[Jan Scheurich]

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

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

[Ben Pfaff]

On Mon, Sep 25, 2017 at 11:15:55AM +, Nitin Katiyar wrote:
> Hi,
> I have a proposal to add a provision for using "dp_hash" as selection method 
> (which can currently be used with OF1.5 based controllers only) irrespective 
> of the OF version being used by controller.
> 
> The link for document is : 
> https://docs.google.com/document/d/13Jiwbs0atV_Y8Vatj6SmQeB_qdM-AyHu8uhtsO6P-_8/edit?usp=sharing

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

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

[Nitin Katiyar]

Hi,
I have a proposal to add a provision for using "dp_hash" as selection method 
(which can currently be used with OF1.5 based controllers only) irrespective of 
the OF version being used by controller.

The link for document is : 
https://docs.google.com/document/d/13Jiwbs0atV_Y8Vatj6SmQeB_qdM-AyHu8uhtsO6P-_8/edit?usp=sharing

Let me know your comments.

Regards,
Nitin

___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev