[ovs-dev] [OVN] DB backup and restore

[Tony Liu]

Hi,

There is any guidance to backup and restore OVN nb-db and sb-db?

Is /var/lib/openvswitch/ovn-[ns]b/ovn[ns]b.db the only database file?

For 3-node DB cluster, is replication 3 (the data is replicated onto
All 3 nodes)?

Are DB files on 3 nodes identical?

If I stop a DB follower and empty the DB file on the follower node,
when I start it back, is the whole DB going to be replicated to it?

To backup the DB, is it OK to copy the DB file from any node, assuming
no transaction ongoing?

Is the following going to work to restore the DB?
* Stop all 3 DBs.
* Copy backup DB file to one node, empty DB file on the rest two nodes.
* Bootstrap the node with DB file.
* Start the rest two nodes to join the cluster.

Do I need to restore sb-db as well? Or restore nb-db only and let
ovn-northd to sync data from nb-db to sb-db. Chassis data should be
updated by onv-controller?

I am running scaling test. It takes quite a lot of time to build
Configurations. Wondering if I can back and restore DB to rollback
to some checkpoint to avoid restart all over.


Thanks!

Tony

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

Re: [ovs-dev] [PATCH ovn] expr.c: Fix argument type of expr_write_scope().

[Numan Siddique]

On Thu, Jul 30, 2020 at 9:58 AM Han Zhou  wrote:

> On Wed, Jul 29, 2020 at 9:03 PM Ankur Sharma 
> wrote:
> >
> > Hi Han,
> >
> > Changes look fine.
> >
> > Acked-by: Ankur Sharma 
> >
> > Regards,
> > Ankur
>
> Thanks Ankur, I applied this to master.
>
> > 
> > From: dev  on behalf of Han Zhou <
> hz...@ovn.org>
> > Sent: Wednesday, July 29, 2020 6:44 PM
> > To: d...@openvswitch.org 
> > Cc: Han Zhou 
> > Subject: [ovs-dev] [PATCH ovn] expr.c: Fix argument type of
> expr_write_scope().
> >
> > There is compile error introduced by the commit 2054d01247.
> > ***
> > ../lib/expr.c:3328:6: error: symbol 'expr_type_check' redeclared with
> different
> > type (originally declared at ../include/ovn/expr.h:481) - incompatible
> argument
> > 4 (different signedness)
> > Makefile:1971: recipe for target 'lib/expr.lo' failed
> > ***
>


Thanks for the fix Han. I'm surprised I didn't see the error.
Probably due to different  gcc and clang versions.

I've below versions installed on my fedora 32.

gcc (GCC) 10.1.1 20200507 (Red Hat 10.1.1-1)
clang version 10.0.0 (Fedora 10.0.0-1.fc32)

Thanks
Numan



> >
> > Fixes: 2054d01247 ("Add expression writeability scopes.")
> > Signed-off-by: Han Zhou 
> > ---
> >  lib/expr.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/lib/expr.c b/lib/expr.c
> > index c07e7dd..6fb9675 100644
> > --- a/lib/expr.c
> > +++ b/lib/expr.c
> > @@ -3327,7 +3327,7 @@ expr_evaluate(const struct expr *e, const struct
> flow *uflow,
> >   * must free(). */
> >  char * OVS_WARN_UNUSED_RESULT
> >  expr_type_check(const struct expr_field *f, int n_bits, bool rw,
> > -uint32_t write_scope)
> > +enum expr_write_scope write_scope)
> >  {
> >  if (n_bits != f->n_bits) {
> >  if (n_bits && f->n_bits) {
> > --
> > 2.1.0
> >
> > ___
> > dev mailing list
> > d...@openvswitch.org
> >
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.openvswitch.org_mailman_listinfo_ovs-2Ddev=DwICAg=s883GpUCOChKOHiocYtGcg=mZwX9gFQgeJHzTg-68aCJgsODyUEVsHGFOfL90J6MJY=6Hq4Iu6-qDZ2r4dRyx_Qw-HEpTmmqfEEJO5Chyck7Bs=8TfuSpbakHFWk34kNULN61Hyg4Z4qCeCA49VZ-T83E0=
> ___
> dev mailing list
> d...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-dev
>
>
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH net-next v3 2/2] net: openvswitch: make masks cache size configurable

[Tonghao Zhang]

On Wed, Jul 29, 2020 at 9:27 PM Eelco Chaudron  wrote:
>
> This patch makes the masks cache size configurable, or with
> a size of 0, disable it.
>
> Reviewed-by: Paolo Abeni 
> Signed-off-by: Eelco Chaudron 
> ---
> Changes in v3:
>  - Use is_power_of_2() function
>  - Use array_size() function
>  - Fix remaining sparse errors
>
> Changes in v2:
>  - Fix sparse warnings
>  - Fix netlink policy items reported by Florian Westphal
>
>  include/uapi/linux/openvswitch.h |1
>  net/openvswitch/datapath.c   |   14 +
>  net/openvswitch/flow_table.c |   97 
> +-
>  net/openvswitch/flow_table.h |   10 
>  4 files changed, 108 insertions(+), 14 deletions(-)
>
> diff --git a/include/uapi/linux/openvswitch.h 
> b/include/uapi/linux/openvswitch.h
> index 7cb76e5ca7cf..8300cc29dec8 100644
> --- a/include/uapi/linux/openvswitch.h
> +++ b/include/uapi/linux/openvswitch.h
> @@ -86,6 +86,7 @@ enum ovs_datapath_attr {
> OVS_DP_ATTR_MEGAFLOW_STATS, /* struct ovs_dp_megaflow_stats */
> OVS_DP_ATTR_USER_FEATURES,  /* OVS_DP_F_*  */
> OVS_DP_ATTR_PAD,
> +   OVS_DP_ATTR_MASKS_CACHE_SIZE,
> __OVS_DP_ATTR_MAX
>  };
>
> diff --git a/net/openvswitch/datapath.c b/net/openvswitch/datapath.c
> index a54df1fe3ec4..114b2ddb8037 100644
> --- a/net/openvswitch/datapath.c
> +++ b/net/openvswitch/datapath.c
> @@ -1498,6 +1498,7 @@ static size_t ovs_dp_cmd_msg_size(void)
> msgsize += nla_total_size_64bit(sizeof(struct ovs_dp_stats));
> msgsize += nla_total_size_64bit(sizeof(struct ovs_dp_megaflow_stats));
> msgsize += nla_total_size(sizeof(u32)); /* OVS_DP_ATTR_USER_FEATURES 
> */
> +   msgsize += nla_total_size(sizeof(u32)); /* 
> OVS_DP_ATTR_MASKS_CACHE_SIZE */
>
> return msgsize;
>  }
> @@ -1535,6 +1536,10 @@ static int ovs_dp_cmd_fill_info(struct datapath *dp, 
> struct sk_buff *skb,
> if (nla_put_u32(skb, OVS_DP_ATTR_USER_FEATURES, dp->user_features))
> goto nla_put_failure;
>
> +   if (nla_put_u32(skb, OVS_DP_ATTR_MASKS_CACHE_SIZE,
> +   ovs_flow_tbl_masks_cache_size(>table)))
> +   goto nla_put_failure;
> +
> genlmsg_end(skb, ovs_header);
> return 0;
>
> @@ -1599,6 +1604,13 @@ static int ovs_dp_change(struct datapath *dp, struct 
> nlattr *a[])
>  #endif
> }
>
> +   if (a[OVS_DP_ATTR_MASKS_CACHE_SIZE]) {
> +   u32 cache_size;
> +
> +   cache_size = nla_get_u32(a[OVS_DP_ATTR_MASKS_CACHE_SIZE]);
> +   ovs_flow_tbl_masks_cache_resize(>table, cache_size);
Do we should return error code, if we can't change the "mask_cache"
size ? for example, -EINVAL, -ENOMEM
> +   }
> +
> dp->user_features = user_features;
>
> if (dp->user_features & OVS_DP_F_TC_RECIRC_SHARING)
> @@ -1894,6 +1906,8 @@ static const struct nla_policy 
> datapath_policy[OVS_DP_ATTR_MAX + 1] = {
> [OVS_DP_ATTR_NAME] = { .type = NLA_NUL_STRING, .len = IFNAMSIZ - 1 },
> [OVS_DP_ATTR_UPCALL_PID] = { .type = NLA_U32 },
> [OVS_DP_ATTR_USER_FEATURES] = { .type = NLA_U32 },
> +   [OVS_DP_ATTR_MASKS_CACHE_SIZE] =  NLA_POLICY_RANGE(NLA_U32, 0,
> +   PCPU_MIN_UNIT_SIZE / sizeof(struct mask_cache_entry)),
>  };
>
>  static const struct genl_ops dp_datapath_genl_ops[] = {
> diff --git a/net/openvswitch/flow_table.c b/net/openvswitch/flow_table.c
> index a5912ea05352..5280aeeef628 100644
> --- a/net/openvswitch/flow_table.c
> +++ b/net/openvswitch/flow_table.c
> @@ -38,8 +38,8 @@
>  #define MASK_ARRAY_SIZE_MIN16
>  #define REHASH_INTERVAL(10 * 60 * HZ)
>
> +#define MC_DEFAULT_HASH_ENTRIES256
>  #define MC_HASH_SHIFT  8
> -#define MC_HASH_ENTRIES(1u << MC_HASH_SHIFT)
>  #define MC_HASH_SEGS   ((sizeof(uint32_t) * 8) / MC_HASH_SHIFT)
>
>  static struct kmem_cache *flow_cache;
> @@ -341,15 +341,75 @@ static void flow_mask_remove(struct flow_table *tbl, 
> struct sw_flow_mask *mask)
> }
>  }
>
> +static void __mask_cache_destroy(struct mask_cache *mc)
> +{
> +   if (mc->mask_cache)
> +   free_percpu(mc->mask_cache);
free_percpu the NULL is safe. we can remove the "if".
> +   kfree(mc);
> +}
> +
> +static void mask_cache_rcu_cb(struct rcu_head *rcu)
> +{
> +   struct mask_cache *mc = container_of(rcu, struct mask_cache, rcu);
> +
> +   __mask_cache_destroy(mc);
> +}
> +
> +static struct mask_cache *tbl_mask_cache_alloc(u32 size)
> +{
> +   struct mask_cache_entry __percpu *cache = NULL;
> +   struct mask_cache *new;
> +
> +   /* Only allow size to be 0, or a power of 2, and does not exceed
> +* percpu allocation size.
> +*/
> +   if ((!is_power_of_2(size) && size != 0) ||
> +   (size * sizeof(struct mask_cache_entry)) > PCPU_MIN_UNIT_SIZE)
> +   return NULL;
> +   new = kzalloc(sizeof(*new), GFP_KERNEL);
> +   if (!new)
> +  

Re: [ovs-dev] [PATCH ovn] expr.c: Fix argument type of expr_write_scope().

[Han Zhou]

On Wed, Jul 29, 2020 at 9:03 PM Ankur Sharma 
wrote:
>
> Hi Han,
>
> Changes look fine.
>
> Acked-by: Ankur Sharma 
>
> Regards,
> Ankur

Thanks Ankur, I applied this to master.

> 
> From: dev  on behalf of Han Zhou <
hz...@ovn.org>
> Sent: Wednesday, July 29, 2020 6:44 PM
> To: d...@openvswitch.org 
> Cc: Han Zhou 
> Subject: [ovs-dev] [PATCH ovn] expr.c: Fix argument type of
expr_write_scope().
>
> There is compile error introduced by the commit 2054d01247.
> ***
> ../lib/expr.c:3328:6: error: symbol 'expr_type_check' redeclared with
different
> type (originally declared at ../include/ovn/expr.h:481) - incompatible
argument
> 4 (different signedness)
> Makefile:1971: recipe for target 'lib/expr.lo' failed
> ***
>
> Fixes: 2054d01247 ("Add expression writeability scopes.")
> Signed-off-by: Han Zhou 
> ---
>  lib/expr.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/lib/expr.c b/lib/expr.c
> index c07e7dd..6fb9675 100644
> --- a/lib/expr.c
> +++ b/lib/expr.c
> @@ -3327,7 +3327,7 @@ expr_evaluate(const struct expr *e, const struct
flow *uflow,
>   * must free(). */
>  char * OVS_WARN_UNUSED_RESULT
>  expr_type_check(const struct expr_field *f, int n_bits, bool rw,
> -uint32_t write_scope)
> +enum expr_write_scope write_scope)
>  {
>  if (n_bits != f->n_bits) {
>  if (n_bits && f->n_bits) {
> --
> 2.1.0
>
> ___
> dev mailing list
> d...@openvswitch.org
>
https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.openvswitch.org_mailman_listinfo_ovs-2Ddev=DwICAg=s883GpUCOChKOHiocYtGcg=mZwX9gFQgeJHzTg-68aCJgsODyUEVsHGFOfL90J6MJY=6Hq4Iu6-qDZ2r4dRyx_Qw-HEpTmmqfEEJO5Chyck7Bs=8TfuSpbakHFWk34kNULN61Hyg4Z4qCeCA49VZ-T83E0=
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH ovn] expr.c: Fix argument type of expr_write_scope().

[Ankur Sharma]

Hi Han,

Changes look fine.

Acked-by: Ankur Sharma 

Regards,
Ankur

From: dev  on behalf of Han Zhou 

Sent: Wednesday, July 29, 2020 6:44 PM
To: d...@openvswitch.org 
Cc: Han Zhou 
Subject: [ovs-dev] [PATCH ovn] expr.c: Fix argument type of expr_write_scope().

There is compile error introduced by the commit 2054d01247.
***
../lib/expr.c:3328:6: error: symbol 'expr_type_check' redeclared with different
type (originally declared at ../include/ovn/expr.h:481) - incompatible argument
4 (different signedness)
Makefile:1971: recipe for target 'lib/expr.lo' failed
***

Fixes: 2054d01247 ("Add expression writeability scopes.")
Signed-off-by: Han Zhou 
---
 lib/expr.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/expr.c b/lib/expr.c
index c07e7dd..6fb9675 100644
--- a/lib/expr.c
+++ b/lib/expr.c
@@ -3327,7 +3327,7 @@ expr_evaluate(const struct expr *e, const struct flow 
*uflow,
  * must free(). */
 char * OVS_WARN_UNUSED_RESULT
 expr_type_check(const struct expr_field *f, int n_bits, bool rw,
-uint32_t write_scope)
+enum expr_write_scope write_scope)
 {
 if (n_bits != f->n_bits) {
 if (n_bits && f->n_bits) {
--
2.1.0

___
dev mailing list
d...@openvswitch.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.openvswitch.org_mailman_listinfo_ovs-2Ddev=DwICAg=s883GpUCOChKOHiocYtGcg=mZwX9gFQgeJHzTg-68aCJgsODyUEVsHGFOfL90J6MJY=6Hq4Iu6-qDZ2r4dRyx_Qw-HEpTmmqfEEJO5Chyck7Bs=8TfuSpbakHFWk34kNULN61Hyg4Z4qCeCA49VZ-T83E0=
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH ovn v2] Fix the routing for external logical ports of bridged logical switches.

[Ankur Sharma]

Hi Numan, Daniel, Lucas,

Thank  you so much for the feedback and providing your inputs.
I went the through the bug that was being referenced and Numan's inputs and 
following is my take on it.
Its a lengthy email, if you just want to look at the suggestions for fix then 
please scroll to the second section :).

Just taking a summary of the input/feedback points and the ones that are most 
pertinent to the discussion.

a. "Hard to colocate the the gateway ports of External port and Router port"
[ANKUR]:  Looking at https://bugzilla.redhat.com/show_bug.cgi?id=1829762.
I do not see a reference to an attempt for using "HA Chassis group" (or may be 
i missed it).
OVN has a primitive which allows a HA chassis cluster to be shared across 
multiple entities. I like this primitive, i think it can be easily used here.
And the whole purpose of having a separate table for HA chassis group is so 
that it can be shared.
Other than openstack implementation, if there are other hindrances in adopting 
it then we should try to address the same in OVN.

b. " if you see the logical swithes ls_vlan4 and ls_vlan5 in this example don't 
provide any N/S connectivity and hence it may not be accurate
to consider them as having gateway ports."
[ANKUR]: Its just the terminology and its interpretation, i.e what is our 
interpretation of NS traffic and gateway ports.
>From the router's perspective, all we are trying to say is that for a 
>distributed router port, if we receive traffic from non OVN endpoint
(i.e entry point to chassis is localnet port), then we need to have a specific 
designated chassis which is the entry point for ARP and Unicast traffic.

Now, the existing gateway port primitive does exactly what i have described 
above. However, if we want to use some other
term for discussion/documentation, i am totally fine with it.


c. "ideally there should be no external entity sharing the IP address from 
these subnets and using the same VLAN. Although practically it's possible to do 
so"
[ANKUR]: Even in an ideal world its a valid requirement. Especially for vlan 
backed subnets, it is a valid and practical use case where OVN does not own
the whole ip space of a CIDR. For example, there could be baremetal endpoints 
or there is a transition phase of migrating virtual non ovn endpoints  
to ovn, or to avoid the pain of migration there are both ovn and non ovn 
virtual endpoints in same subnet, similarly there could be 
stretched subnet across sites (hybrid cloud use case), where both sites (and 
both of them need not be OVN run)
manage non overlapping ip pools for their respective endpoints.


d.  " If there is such a requirement, I think CMS should consider using 
'external' port for this"
[ANKUR]: Use of external port is that we leverage on DHCP service by OVN for 
non ovn endpoints.
Which is definitely good to have, but not mandatory (infact it MUST not be 
mandatory).
A deployment could have its own external DHCP server even for ovn endpoints or
external dhcp server for non ovn endpoints or non ovn endpoints have static IPs.
Neither of which mandates that non ovn endpoint has to be marked as external.
Infact, for hybrid connectivity cases like (like stretched subnets across 
sites/AZs as mentioned in c. above),
mandating DHCP service for whole CIDR by OVN would be non desirable.
TOR gateway is also a non ovn endpoint :).


==

ALTERNATIVE PROPOSALS:
There are multiple ways the scenario called out in this thread can be addressed.

a. Remove the "ls_in_external_port" stage in pipeline. For example, in the 
topology mentioned here:
https://docs.google.com/document/d/117yskeP1S3qHmkNrBrZ0PxXCvMJCCVJhcPG4phw1Qls/edit?usp=sharing

I see following flows in "ls_in_external_port":
  table=18(ls_in_external_port), priority=100  , match=(inport == 
"ls-underlay-physnet1" && eth.src == 50:6b:8d:cc:17:7d && 
!is_chassis_resident("lsp-external") && arp.tpa == 10.15.24.135 && arp.op == 
1), action=(drop;)
  table=18(ls_in_external_port), priority=100  , match=(inport == 
"ls-underlay-physnet1" && eth.src == 50:6b:8d:cc:17:7d && 
!is_chassis_resident("lsp-external") && nd_ns && ip6.dst == 
{fe80::200:1ff:fe01:204, ff02::1:ff01:204} && nd.target == 
fe80::200:1ff:fe01:204), action=(drop;)
  table=18(ls_in_external_port), priority=0, match=(1), action=(next;)

My opinion/understanding is that it is on router to decide where it wants 
router port ARP to be resolved. A logical switch port cannot/should not decide, 
where it want the attached router port ip to be resolved.
If we do not have above flow, then it implies that significance of HA_Chassis 
group for external port is to call out which chassis will behave like a DHCP 
server for a given external endpoint.
For regular datapath operations, packet flow stays consistent with any 
external/non ovn endpoint.

If at all the stage was meant to have additional work, then atleast the flows 
at priority=100 should not be there.

P.N: I have not tried 

[ovs-dev] [PATCH ovn] expr.c: Fix argument type of expr_write_scope().

[Han Zhou]

There is compile error introduced by the commit 2054d01247.
***
../lib/expr.c:3328:6: error: symbol 'expr_type_check' redeclared with different
type (originally declared at ../include/ovn/expr.h:481) - incompatible argument
4 (different signedness)
Makefile:1971: recipe for target 'lib/expr.lo' failed
***

Fixes: 2054d01247 ("Add expression writeability scopes.")
Signed-off-by: Han Zhou 
---
 lib/expr.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/expr.c b/lib/expr.c
index c07e7dd..6fb9675 100644
--- a/lib/expr.c
+++ b/lib/expr.c
@@ -3327,7 +3327,7 @@ expr_evaluate(const struct expr *e, const struct flow 
*uflow,
  * must free(). */
 char * OVS_WARN_UNUSED_RESULT
 expr_type_check(const struct expr_field *f, int n_bits, bool rw,
-uint32_t write_scope)
+enum expr_write_scope write_scope)
 {
 if (n_bits != f->n_bits) {
 if (n_bits && f->n_bits) {
-- 
2.1.0

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

Re: [ovs-dev] [PATCH ovn v3 0/5] Add ECMP symmetric replies

[Mark Michelson]

On 7/29/20 9:43 AM, Numan Siddique wrote:



On Wed, Jul 29, 2020 at 1:54 AM Mark Michelson > wrote:


In some cases, it is important that traffic that arrived over an ECMP
route has its replies sent out over that same route. This series of
commits adds some prerequisite changes in order to facilitate using
conntrack labels to store information about the incoming traffic. The
final commit adds the new feature, storing the source MAC and incoming
logical router port for new incoming connections over an ECMP route. The
feature is only used if a specific option is set, and it may only be
used in gateway routers.


Acked-by: Numan Siddique mailto:num...@ovn.org>> for 
the entire series.


Thanks
Numan


Thanks for the reviews Numan. I merged this to master.



---
v3 -> v4
* Rebased to current master
* Fixed failing conntrack fields test
* Bumped ovn-nb minor version.
v2 -> v3
* Added this cover letter
* Added writeability scope commit to series
* Added assignment writeability alteration commit to series
* Added test to ovn.at  to ensure flows are only
present on gateway
   routers
* Changed the bits used in the ct_label. Previous commits used bits
   0-63. This commit changes it to use bits 32-95.
v1 -> v2
* Fixed test failures
---
Mark Michelson (5):
   Add IP address normalization to ovn-utils.
   Don't check for writeability of rhs during assignment.
   Add expression writeability scopes.
   Used nested actions in ct_commit
   Add ECMP symmetric replies.

  include/ovn/actions.h     |   9 +-
  include/ovn/expr.h        |  53 +++---
  lib/actions.c             | 154 
  lib/expr.c                |  35 ---
  lib/logical-fields.c      |  15 ++-
  lib/ovn-util.c            |  39 +++
  lib/ovn-util.h            |   4 +
  northd/ovn-northd.8.xml   |  49 +++--
  northd/ovn-northd.c       | 131 
  ovn-architecture.7.xml    |   7 +-
  ovn-nb.ovsschema          |   5 +-
  ovn-nb.xml                |  16 +++
  ovn-sb.xml                |  11 +-
  tests/ovn.at               | 210
+++---
  tests/system-ovn.at        | 144
++
  utilities/ovn-nbctl.8.xml |  31 --
  utilities/ovn-nbctl.c     |  47 +++--
  17 files changed, 695 insertions(+), 265 deletions(-)

-- 
2.25.4


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



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

[ovs-dev] [PATCH branch-2.13 1/2] Set release date for 2.13.1.

[Ilya Maximets]

Signed-off-by: Ilya Maximets 
---
 NEWS | 11 ++-
 debian/changelog |  2 +-
 2 files changed, 7 insertions(+), 6 deletions(-)

diff --git a/NEWS b/NEWS
index ac7dc670c..fc4304985 100644
--- a/NEWS
+++ b/NEWS
@@ -1,9 +1,10 @@
-v2.13.1 - xx xxx 
+v2.13.1 - 30 Jul 2020
 -
-- DPDK:
-  * OVS validated with DPDK 19.11.2, due to the inclusion of fixes for
-CVE-2020-10722, CVE-2020-10723, CVE-2020-10724, CVE-2020-10725 and
-CVE-2020-10726, this DPDK version is strongly recommended to be used.
+   - Bug fixes
+   - DPDK:
+ * OVS validated with DPDK 19.11.2, due to the inclusion of fixes for
+   CVE-2020-10722, CVE-2020-10723, CVE-2020-10724, CVE-2020-10725 and
+   CVE-2020-10726, this DPDK version is strongly recommended to be used.
 
 v2.13.0 - 14 Feb 2020
 -
diff --git a/debian/changelog b/debian/changelog
index 76df7593e..7dfe9ad85 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -2,7 +2,7 @@ openvswitch (2.13.1-1) unstable; urgency=low
[ Open vSwitch team]
* New upstream version
 
- -- Open vSwitch team   Fri, 14 Feb 2020 13:00:00 -0700
+ -- Open vSwitch team   Thu, 30 Jul 2020 00:25:23 +0200
 
 openvswitch (2.13.0-1) unstable; urgency=low
[ Open vSwitch team]
-- 
2.25.4

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

[ovs-dev] [PATCH branch-2.12 1/2] Set release date for 2.12.1.

[Ilya Maximets]

Signed-off-by: Ilya Maximets 
---
 NEWS | 3 ++-
 debian/changelog | 2 +-
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/NEWS b/NEWS
index d00cc22df..2c7aa9b59 100644
--- a/NEWS
+++ b/NEWS
@@ -1,5 +1,6 @@
-v2.12.1 - xx xxx 
+v2.12.1 - 30 Jul 2020
 -
+   - Bug fixes
- DPDK:
  * OVS validated with DPDK 18.11.9. Due to this being the latest LTS to
be validated and coupled with the inclusion of fixes for
diff --git a/debian/changelog b/debian/changelog
index bb9ea31a0..e5299c5b1 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -2,7 +2,7 @@ openvswitch (2.12.1-1) unstable; urgency=low
[ Open vSwitch team ]
* New upstream version
 
- -- Open vSwitch team   Tue, 03 Sep 2019 14:57:37 -0700
+ -- Open vSwitch team   Thu, 30 Jul 2020 00:25:17 +0200
 
 openvswitch (2.12.0-1) unstable; urgency=low
[ Open vSwitch team ]
-- 
2.25.4

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

[ovs-dev] [PATCH branch-2.13 2/2] Prepare for 2.13.2.

[Ilya Maximets]

Signed-off-by: Ilya Maximets 
---
 NEWS | 3 +++
 configure.ac | 2 +-
 debian/changelog | 6 ++
 3 files changed, 10 insertions(+), 1 deletion(-)

diff --git a/NEWS b/NEWS
index fc4304985..128db0f61 100644
--- a/NEWS
+++ b/NEWS
@@ -1,3 +1,6 @@
+v2.13.2 - xx xxx 
+-
+
 v2.13.1 - 30 Jul 2020
 -
- Bug fixes
diff --git a/configure.ac b/configure.ac
index 55e8b509b..67942bbfb 100644
--- a/configure.ac
+++ b/configure.ac
@@ -13,7 +13,7 @@
 # limitations under the License.
 
 AC_PREREQ(2.63)
-AC_INIT(openvswitch, 2.13.1, b...@openvswitch.org)
+AC_INIT(openvswitch, 2.13.2, b...@openvswitch.org)
 AC_CONFIG_SRCDIR([datapath/datapath.c])
 AC_CONFIG_MACRO_DIR([m4])
 AC_CONFIG_AUX_DIR([build-aux])
diff --git a/debian/changelog b/debian/changelog
index 7dfe9ad85..d803cf10d 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+openvswitch (2.13.2-1) unstable; urgency=low
+   [ Open vSwitch team ]
+   * New upstream version
+
+ -- Open vSwitch team   Thu, 30 Jul 2020 00:25:23 +0200
+
 openvswitch (2.13.1-1) unstable; urgency=low
[ Open vSwitch team]
* New upstream version
-- 
2.25.4

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

[ovs-dev] [PATCH branch-2.11 2/2] Prepare for 2.11.5.

[Ilya Maximets]

Signed-off-by: Ilya Maximets 
---
 NEWS | 3 +++
 configure.ac | 2 +-
 debian/changelog | 6 ++
 3 files changed, 10 insertions(+), 1 deletion(-)

diff --git a/NEWS b/NEWS
index 68224b4fa..87f24b52c 100644
--- a/NEWS
+++ b/NEWS
@@ -1,3 +1,6 @@
+v2.11.5 - xx xxx 
+-
+
 v2.11.4 - 30 Jul 2020
 -
- Bug fixes
diff --git a/configure.ac b/configure.ac
index 8547d094b..e6e2a5d5b 100644
--- a/configure.ac
+++ b/configure.ac
@@ -13,7 +13,7 @@
 # limitations under the License.
 
 AC_PREREQ(2.63)
-AC_INIT(openvswitch, 2.11.4, b...@openvswitch.org)
+AC_INIT(openvswitch, 2.11.5, b...@openvswitch.org)
 AC_CONFIG_SRCDIR([datapath/datapath.c])
 AC_CONFIG_MACRO_DIR([m4])
 AC_CONFIG_AUX_DIR([build-aux])
diff --git a/debian/changelog b/debian/changelog
index fef4ad320..851cca9cb 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+openvswitch (2.11.5-1) unstable; urgency=low
+   [ Open vSwitch team ]
+   * New upstream version
+
+ -- Open vSwitch team   Thu, 30 Jul 2020 00:25:16 +0200
+
 openvswitch (2.11.4-1) unstable; urgency=low
[ Open vSwitch team ]
* New upstream version
-- 
2.25.4

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

[ovs-dev] [PATCH branch-2.10 0/2] Release patches for v2.10.5.

[Ilya Maximets]

Ilya Maximets (2):
  Set release date for 2.10.5.
  Prepare for 2.10.6.

 NEWS | 6 +-
 configure.ac | 2 +-
 debian/changelog | 8 +++-
 3 files changed, 13 insertions(+), 3 deletions(-)

-- 
2.25.4

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

[ovs-dev] [PATCH branch-2.10 2/2] Prepare for 2.10.6.

[Ilya Maximets]

Signed-off-by: Ilya Maximets 
---
 NEWS | 3 +++
 configure.ac | 2 +-
 debian/changelog | 6 ++
 3 files changed, 10 insertions(+), 1 deletion(-)

diff --git a/NEWS b/NEWS
index 14721913e..87665d047 100644
--- a/NEWS
+++ b/NEWS
@@ -1,3 +1,6 @@
+v2.10.6 - xx xxx 
+-
+
 v2.10.5 - 30 Jul 2020
 -
- Bug fixes
diff --git a/configure.ac b/configure.ac
index 9c5e4d868..a6a542f17 100644
--- a/configure.ac
+++ b/configure.ac
@@ -13,7 +13,7 @@
 # limitations under the License.
 
 AC_PREREQ(2.63)
-AC_INIT(openvswitch, 2.10.5, b...@openvswitch.org)
+AC_INIT(openvswitch, 2.10.6, b...@openvswitch.org)
 AC_CONFIG_SRCDIR([datapath/datapath.c])
 AC_CONFIG_MACRO_DIR([m4])
 AC_CONFIG_AUX_DIR([build-aux])
diff --git a/debian/changelog b/debian/changelog
index fb0ecf984..fafc0ca59 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+openvswitch (2.10.6-1) unstable; urgency=low
+   [ Open vSwitch team ]
+   * New upstream version
+
+ -- Open vSwitch team   Thu, 30 Jul 2020 00:25:15 +0200
+
 openvswitch (2.10.5-1) unstable; urgency=low
[ Open vSwitch team ]
* New upstream version
-- 
2.25.4

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

[ovs-dev] [PATCH branch-2.10 1/2] Set release date for 2.10.5.

[Ilya Maximets]

Signed-off-by: Ilya Maximets 
---
 NEWS | 3 ++-
 debian/changelog | 2 +-
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/NEWS b/NEWS
index 8715349ba..14721913e 100644
--- a/NEWS
+++ b/NEWS
@@ -1,5 +1,6 @@
-v2.10.5 - xx xxx 
+v2.10.5 - 30 Jul 2020
 -
+   - Bug fixes
- DPDK
 * OVS validated with DPDK 17.11.10 which is recommended to be used.
 
diff --git a/debian/changelog b/debian/changelog
index 10cae82f5..fb0ecf984 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -2,7 +2,7 @@ openvswitch (2.10.5-1) unstable; urgency=low
[ Open vSwitch team ]
* New upstream version
 
- -- Open vSwitch team   Fri, 06 Sep 2019 14:30:57 -0700
+ -- Open vSwitch team   Thu, 30 Jul 2020 00:25:15 +0200
 
 openvswitch (2.10.4-1) unstable; urgency=low
[ Open vSwitch team ]
-- 
2.25.4

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

[ovs-dev] [PATCH branch-2.11 0/2] Release patches for v2.11.4.

[Ilya Maximets]

Ilya Maximets (2):
  Set release date for 2.11.4.
  Prepare for 2.11.5.

 NEWS | 6 +-
 configure.ac | 2 +-
 debian/changelog | 8 +++-
 3 files changed, 13 insertions(+), 3 deletions(-)

-- 
2.25.4

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

[ovs-dev] [PATCH branch-2.12 0/2] Release patches for v2.12.1.

[Ilya Maximets]

Ilya Maximets (2):
  Set release date for 2.12.1.
  Prepare for 2.12.2.

 NEWS | 6 +-
 configure.ac | 2 +-
 debian/changelog | 8 +++-
 3 files changed, 13 insertions(+), 3 deletions(-)

-- 
2.25.4

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

[ovs-dev] [PATCH branch-2.11 1/2] Set release date for 2.11.4.

[Ilya Maximets]

Signed-off-by: Ilya Maximets 
---
 NEWS | 3 ++-
 debian/changelog | 2 +-
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/NEWS b/NEWS
index cd0c889c1..68224b4fa 100644
--- a/NEWS
+++ b/NEWS
@@ -1,5 +1,6 @@
-v2.11.4 - xx xxx 
+v2.11.4 - 30 Jul 2020
 -
+   - Bug fixes
- DPDK
  * OVS validated with DPDK 18.11.9. Due to this being the latest LTS to
be validated and coupled with the inclusion of fixes for
diff --git a/debian/changelog b/debian/changelog
index 56471d417..fef4ad320 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -2,7 +2,7 @@ openvswitch (2.11.4-1) unstable; urgency=low
[ Open vSwitch team ]
* New upstream version
 
- -- Open vSwitch team   Fri, 06 Sep 2019 14:31:36 -0700
+ -- Open vSwitch team   Thu, 30 Jul 2020 00:25:16 +0200
 
 openvswitch (2.11.3-1) unstable; urgency=low
[ Open vSwitch team ]
-- 
2.25.4

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

[ovs-dev] [PATCH branch-2.13 0/2] Release patches for v2.13.1.

[Ilya Maximets]

Ilya Maximets (2):
  Set release date for 2.13.1.
  Prepare for 2.13.2.

 NEWS | 14 +-
 configure.ac |  2 +-
 debian/changelog |  8 +++-
 3 files changed, 17 insertions(+), 7 deletions(-)

-- 
2.25.4

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

[ovs-dev] [PATCH branch-2.12 2/2] Prepare for 2.12.2.

[Ilya Maximets]

Signed-off-by: Ilya Maximets 
---
 NEWS | 3 +++
 configure.ac | 2 +-
 debian/changelog | 6 ++
 3 files changed, 10 insertions(+), 1 deletion(-)

diff --git a/NEWS b/NEWS
index 2c7aa9b59..459cded4d 100644
--- a/NEWS
+++ b/NEWS
@@ -1,3 +1,6 @@
+v2.12.2 - xx xxx 
+-
+
 v2.12.1 - 30 Jul 2020
 -
- Bug fixes
diff --git a/configure.ac b/configure.ac
index a4322176c..1d6ae4f68 100644
--- a/configure.ac
+++ b/configure.ac
@@ -13,7 +13,7 @@
 # limitations under the License.
 
 AC_PREREQ(2.63)
-AC_INIT(openvswitch, 2.12.1, b...@openvswitch.org)
+AC_INIT(openvswitch, 2.12.2, b...@openvswitch.org)
 AC_CONFIG_SRCDIR([datapath/datapath.c])
 AC_CONFIG_MACRO_DIR([m4])
 AC_CONFIG_AUX_DIR([build-aux])
diff --git a/debian/changelog b/debian/changelog
index e5299c5b1..2d5469cd6 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+openvswitch (2.12.2-1) unstable; urgency=low
+   [ Open vSwitch team ]
+   * New upstream version
+
+ -- Open vSwitch team   Thu, 30 Jul 2020 00:25:17 +0200
+
 openvswitch (2.12.1-1) unstable; urgency=low
[ Open vSwitch team ]
* New upstream version
-- 
2.25.4

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

[ovs-dev] [PATCH branch-2.9 1/2] Set release date for 2.9.7.

[Ilya Maximets]

Signed-off-by: Ilya Maximets 
---
 NEWS | 3 ++-
 debian/changelog | 2 +-
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/NEWS b/NEWS
index a6f1586ac..887dda24b 100644
--- a/NEWS
+++ b/NEWS
@@ -1,5 +1,6 @@
-v2.9.7 - xx xxx 
+v2.9.7 - 30 Jul 2020
 
+   - Bug fixes
- DPDK
 * OVS validated with DPDK 17.11.10 which is recommended to be used.
 
diff --git a/debian/changelog b/debian/changelog
index d0c5afce2..97e629f04 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -2,7 +2,7 @@ openvswitch (2.9.7-1) unstable; urgency=low
[ Open vSwitch team ]
* New upstream version
 
- -- Open vSwitch team   Tue, 03 Sep 2019 15:14:43 -0700
+ -- Open vSwitch team   Thu, 30 Jul 2020 00:25:13 +0200
 
 openvswitch (2.9.6-1) unstable; urgency=low
[ Open vSwitch team ]
-- 
2.25.4

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

[ovs-dev] [PATCH branch-2.9 2/2] Prepare for 2.9.8.

[Ilya Maximets]

Signed-off-by: Ilya Maximets 
---
 NEWS | 3 +++
 configure.ac | 2 +-
 debian/changelog | 6 ++
 3 files changed, 10 insertions(+), 1 deletion(-)

diff --git a/NEWS b/NEWS
index 887dda24b..dacd064cf 100644
--- a/NEWS
+++ b/NEWS
@@ -1,3 +1,6 @@
+v2.9.8 - xx xxx 
+
+
 v2.9.7 - 30 Jul 2020
 
- Bug fixes
diff --git a/configure.ac b/configure.ac
index 4e8591caa..de8734ffd 100644
--- a/configure.ac
+++ b/configure.ac
@@ -13,7 +13,7 @@
 # limitations under the License.
 
 AC_PREREQ(2.63)
-AC_INIT(openvswitch, 2.9.7, b...@openvswitch.org)
+AC_INIT(openvswitch, 2.9.8, b...@openvswitch.org)
 AC_CONFIG_SRCDIR([datapath/datapath.c])
 AC_CONFIG_MACRO_DIR([m4])
 AC_CONFIG_AUX_DIR([build-aux])
diff --git a/debian/changelog b/debian/changelog
index 97e629f04..3f9a5a8b0 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+openvswitch (2.9.8-1) unstable; urgency=low
+   [ Open vSwitch team ]
+   * New upstream version
+
+ -- Open vSwitch team   Thu, 30 Jul 2020 00:25:13 +0200
+
 openvswitch (2.9.7-1) unstable; urgency=low
[ Open vSwitch team ]
* New upstream version
-- 
2.25.4

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

[ovs-dev] [PATCH branch-2.9 0/2] Release patches for v2.9.7.

[Ilya Maximets]

Ilya Maximets (2):
  Set release date for 2.9.7.
  Prepare for 2.9.8.

 NEWS | 6 +-
 configure.ac | 2 +-
 debian/changelog | 8 +++-
 3 files changed, 13 insertions(+), 3 deletions(-)

-- 
2.25.4

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

[ovs-dev] [PATCH branch-2.8 2/2] Prepare for 2.8.10.

[Ilya Maximets]

Signed-off-by: Ilya Maximets 
---
 NEWS | 3 +++
 configure.ac | 2 +-
 debian/changelog | 6 ++
 3 files changed, 10 insertions(+), 1 deletion(-)

diff --git a/NEWS b/NEWS
index 10a15b561..8771a23e0 100644
--- a/NEWS
+++ b/NEWS
@@ -1,3 +1,6 @@
+v2.8.10 - xx xxx 
+-
+
 v2.8.9 - 30 Jul 2020
 
- Bug fixes
diff --git a/configure.ac b/configure.ac
index 1587408c4..6d2e6f558 100644
--- a/configure.ac
+++ b/configure.ac
@@ -13,7 +13,7 @@
 # limitations under the License.
 
 AC_PREREQ(2.63)
-AC_INIT(openvswitch, 2.8.9, b...@openvswitch.org)
+AC_INIT(openvswitch, 2.8.10, b...@openvswitch.org)
 AC_CONFIG_SRCDIR([datapath/datapath.c])
 AC_CONFIG_MACRO_DIR([m4])
 AC_CONFIG_AUX_DIR([build-aux])
diff --git a/debian/changelog b/debian/changelog
index 824ed7d5f..2715a91c6 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+openvswitch (2.8.10-1) unstable; urgency=low
+   [ Open vSwitch team ]
+   * New upstream version
+
+ -- Open vSwitch team   Thu, 30 Jul 2020 00:25:12 +0200
+
 openvswitch (2.8.9-1) unstable; urgency=low
[ Open vSwitch team ]
* New upstream version
-- 
2.25.4

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

[ovs-dev] [PATCH branch-2.6 2/2] Prepare for 2.6.9.

[Ilya Maximets]

Signed-off-by: Ilya Maximets 
---
 NEWS | 3 +++
 configure.ac | 2 +-
 debian/changelog | 6 ++
 3 files changed, 10 insertions(+), 1 deletion(-)

diff --git a/NEWS b/NEWS
index 090ae04cd..e9b00b4bf 100644
--- a/NEWS
+++ b/NEWS
@@ -1,3 +1,6 @@
+v2.6.9 - xx xxx 
+
+
 v2.6.8 - 30 Jul 2020
 
- Bug fixes
diff --git a/configure.ac b/configure.ac
index 72a6de8b5..51f8a119d 100644
--- a/configure.ac
+++ b/configure.ac
@@ -13,7 +13,7 @@
 # limitations under the License.
 
 AC_PREREQ(2.63)
-AC_INIT(openvswitch, 2.6.8, b...@openvswitch.org)
+AC_INIT(openvswitch, 2.6.9, b...@openvswitch.org)
 AC_CONFIG_SRCDIR([datapath/datapath.c])
 AC_CONFIG_MACRO_DIR([m4])
 AC_CONFIG_AUX_DIR([build-aux])
diff --git a/debian/changelog b/debian/changelog
index 3009e1630..188362666 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+openvswitch (2.6.9-1) unstable; urgency=low
+   [ Open vSwitch team ]
+   * New upstream version
+
+ -- Open vSwitch team   Thu, 30 Jul 2020 00:25:10 +0200
+
 openvswitch (2.6.8-1) unstable; urgency=low
[ Open vSwitch team ]
* New upstream version
-- 
2.25.4

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

[ovs-dev] [PATCH branch-2.8 1/2] Set release date for 2.8.9.

[Ilya Maximets]

Signed-off-by: Ilya Maximets 
---
 NEWS | 3 ++-
 debian/changelog | 2 +-
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/NEWS b/NEWS
index 1844d0c22..10a15b561 100644
--- a/NEWS
+++ b/NEWS
@@ -1,5 +1,6 @@
-v2.8.9 - xx xxx 
+v2.8.9 - 30 Jul 2020
 
+   - Bug fixes
 
 v2.8.8 - 06 Sep 2019
 
diff --git a/debian/changelog b/debian/changelog
index e571dccc3..824ed7d5f 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -2,7 +2,7 @@ openvswitch (2.8.9-1) unstable; urgency=low
[ Open vSwitch team ]
* New upstream version
 
- -- Open vSwitch team   Fri, 06 Sep 2019 13:47:26 -0700
+ -- Open vSwitch team   Thu, 30 Jul 2020 00:25:12 +0200
 
 openvswitch (2.8.8-1) unstable; urgency=low
[ Open vSwitch team ]
-- 
2.25.4

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

[ovs-dev] [PATCH branch-2.7 2/2] Prepare for 2.7.12.

[Ilya Maximets]

Signed-off-by: Ilya Maximets 
---
 NEWS | 3 +++
 configure.ac | 2 +-
 debian/changelog | 6 ++
 3 files changed, 10 insertions(+), 1 deletion(-)

diff --git a/NEWS b/NEWS
index dfee36de1..2bf2b03c6 100644
--- a/NEWS
+++ b/NEWS
@@ -1,3 +1,6 @@
+v2.7.12 - xx xxx 
+-
+
 v2.7.11 - 30 Jul 2020
 -
- Bug fixes
diff --git a/configure.ac b/configure.ac
index 65ca63ad2..a2d5faa30 100644
--- a/configure.ac
+++ b/configure.ac
@@ -13,7 +13,7 @@
 # limitations under the License.
 
 AC_PREREQ(2.63)
-AC_INIT(openvswitch, 2.7.11, b...@openvswitch.org)
+AC_INIT(openvswitch, 2.7.12, b...@openvswitch.org)
 AC_CONFIG_SRCDIR([datapath/datapath.c])
 AC_CONFIG_MACRO_DIR([m4])
 AC_CONFIG_AUX_DIR([build-aux])
diff --git a/debian/changelog b/debian/changelog
index 13cb4efaa..4c4fdebf9 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+openvswitch (2.7.12-1) unstable; urgency=low
+   [ Open vSwitch team ]
+   * New upstream version
+
+ -- Open vSwitch team   Thu, 30 Jul 2020 00:25:11 +0200
+
 openvswitch (2.7.11-1) unstable; urgency=low
[ Open vSwitch team ]
* New upstream version
-- 
2.25.4

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

[ovs-dev] [PATCH branch-2.8 0/2] Release patches for v2.8.9.

[Ilya Maximets]

Ilya Maximets (2):
  Set release date for 2.8.9.
  Prepare for 2.8.10.

 NEWS | 6 +-
 configure.ac | 2 +-
 debian/changelog | 8 +++-
 3 files changed, 13 insertions(+), 3 deletions(-)

-- 
2.25.4

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

[ovs-dev] [PATCH branch-2.7 1/2] Set release date for 2.7.11.

[Ilya Maximets]

Signed-off-by: Ilya Maximets 
---
 NEWS | 3 ++-
 debian/changelog | 2 +-
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/NEWS b/NEWS
index 365513542..dfee36de1 100644
--- a/NEWS
+++ b/NEWS
@@ -1,5 +1,6 @@
-v2.7.11 - xx xxx 
+v2.7.11 - 30 Jul 2020
 -
+   - Bug fixes
 
 v2.7.10 - 06 Sep 2019
 -
diff --git a/debian/changelog b/debian/changelog
index d28669ec1..13cb4efaa 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -2,7 +2,7 @@ openvswitch (2.7.11-1) unstable; urgency=low
[ Open vSwitch team ]
* New upstream version
 
- -- Open vSwitch team   Fri, 06 Sep 2019 13:46:13 -0700
+ -- Open vSwitch team   Thu, 30 Jul 2020 00:25:11 +0200
 
 openvswitch (2.7.10-1) unstable; urgency=low
[ Open vSwitch team ]
-- 
2.25.4

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

[ovs-dev] [PATCH branch-2.7 0/2] Release patches for v2.7.11.

[Ilya Maximets]

Ilya Maximets (2):
  Set release date for 2.7.11.
  Prepare for 2.7.12.

 NEWS | 6 +-
 configure.ac | 2 +-
 debian/changelog | 8 +++-
 3 files changed, 13 insertions(+), 3 deletions(-)

-- 
2.25.4

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

[ovs-dev] [PATCH branch-2.5 2/2] Prepare for 2.5.11.

[Ilya Maximets]

Signed-off-by: Ilya Maximets 
---
 NEWS | 3 +++
 configure.ac | 2 +-
 debian/changelog | 6 ++
 3 files changed, 10 insertions(+), 1 deletion(-)

diff --git a/NEWS b/NEWS
index 9c1749fbb..828b5ef65 100644
--- a/NEWS
+++ b/NEWS
@@ -1,3 +1,6 @@
+v2.5.11 - xx xxx 
+-
+
 v2.5.10 - 30 Jul 2020
 -
- Bug fixes
diff --git a/configure.ac b/configure.ac
index ba199fb89..c447b5846 100644
--- a/configure.ac
+++ b/configure.ac
@@ -13,7 +13,7 @@
 # limitations under the License.
 
 AC_PREREQ(2.63)
-AC_INIT(openvswitch, 2.5.10, b...@openvswitch.org)
+AC_INIT(openvswitch, 2.5.11, b...@openvswitch.org)
 AC_CONFIG_SRCDIR([datapath/datapath.c])
 AC_CONFIG_MACRO_DIR([m4])
 AC_CONFIG_AUX_DIR([build-aux])
diff --git a/debian/changelog b/debian/changelog
index 85682687a..bbcaa8975 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+openvswitch (2.5.11-1) unstable; urgency=low
+   [ Open vSwitch team ]
+   * New upstream version
+
+ -- Open vSwitch team   Thu, 30 Jul 2020 00:25:09 +0200
+
 openvswitch (2.5.10-1) unstable; urgency=low
[ Open vSwitch team ]
* New upstream version
-- 
2.25.4

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

[ovs-dev] [PATCH branch-2.6 1/2] Set release date for 2.6.8.

[Ilya Maximets]

Signed-off-by: Ilya Maximets 
---
 NEWS | 3 ++-
 debian/changelog | 2 +-
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/NEWS b/NEWS
index a083ca3fd..090ae04cd 100644
--- a/NEWS
+++ b/NEWS
@@ -1,5 +1,6 @@
-v2.6.8 - xx xxx 
+v2.6.8 - 30 Jul 2020
 
+   - Bug fixes
 
 v2.6.7 - 06 Sep 2019
 
diff --git a/debian/changelog b/debian/changelog
index 9017df1ca..3009e1630 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -2,7 +2,7 @@ openvswitch (2.6.8-1) unstable; urgency=low
[ Open vSwitch team ]
* New upstream version
 
- -- Open vSwitch team   Fri, 06 Sep 2019 13:24:19 -0700
+ -- Open vSwitch team   Thu, 30 Jul 2020 00:25:10 +0200
 
 openvswitch (2.6.7-1) unstable; urgency=low
[ Open vSwitch team ]
-- 
2.25.4

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

[ovs-dev] [PATCH branch-2.5 0/2] Release patches for v2.5.10.

[Ilya Maximets]

Ilya Maximets (2):
  Set release date for 2.5.10.
  Prepare for 2.5.11.

 NEWS | 6 +-
 configure.ac | 2 +-
 debian/changelog | 8 +++-
 3 files changed, 13 insertions(+), 3 deletions(-)

-- 
2.25.4

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

[ovs-dev] [PATCH branch-2.5 1/2] Set release date for 2.5.10.

[Ilya Maximets]

Signed-off-by: Ilya Maximets 
---
 NEWS | 3 ++-
 debian/changelog | 2 +-
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/NEWS b/NEWS
index 999c124e6..9c1749fbb 100644
--- a/NEWS
+++ b/NEWS
@@ -1,5 +1,6 @@
-v2.5.10 - xx xxx 
+v2.5.10 - 30 Jul 2020
 -
+   - Bug fixes
 
 v2.5.9 - 06 Sep 2019
 
diff --git a/debian/changelog b/debian/changelog
index 63a33ff2c..85682687a 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -2,7 +2,7 @@ openvswitch (2.5.10-1) unstable; urgency=low
[ Open vSwitch team ]
* New upstream version
 
- -- Open vSwitch team   Fri, 06 Sep 2019 13:23:47 -0700
+ -- Open vSwitch team   Thu, 30 Jul 2020 00:25:09 +0200
 
 openvswitch (2.5.9-1) unstable; urgency=low
[ Open vSwitch team ]
-- 
2.25.4

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

[ovs-dev] [PATCH branch-2.6 0/2] Release patches for v2.6.8.

[Ilya Maximets]

Ilya Maximets (2):
  Set release date for 2.6.8.
  Prepare for 2.6.9.

 NEWS | 6 +-
 configure.ac | 2 +-
 debian/changelog | 8 +++-
 3 files changed, 13 insertions(+), 3 deletions(-)

-- 
2.25.4

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

Re: [ovs-dev] [PATCH v2] datapath-windows: Update flow key in SET action

[Alin Serdean]

Applied on master. Thank you for the fixes and testing!


Alin.

From: Jinjun Gao
Sent: Wednesday, July 29, 2020 6:29 AM
To: d...@openvswitch.org; Alin 
Serdean; 
kumaran...@vmware.com
Cc: r...@vmware.com; Jinjun 
Gao
Subject: [PATCH v2] datapath-windows: Update flow key in SET action

The flow key is not updated when process OVS_ACTION_ATTR_SET action.
It will impact follow-up actions, such as, conntrack module cannot
find created conntrack entry if passing old flow key to it.

Reported-by: Rui Cao 
Signed-off-by: Jinjun Gao 
---
v2: Separated assignment to happy MSFT SDV tool
---
 datapath-windows/ovsext/Actions.c | 31 ---
 datapath-windows/ovsext/Actions.h |  3 +++
 2 files changed, 27 insertions(+), 7 deletions(-)

diff --git a/datapath-windows/ovsext/Actions.c 
b/datapath-windows/ovsext/Actions.c
index 4a11cea..4f43369 100644
--- a/datapath-windows/ovsext/Actions.c
+++ b/datapath-windows/ovsext/Actions.c
@@ -1259,6 +1259,7 @@ OvsActionMplsPush(OvsForwardingContext *ovsFwdCtx,
  */
 static __inline NDIS_STATUS
 OvsUpdateEthHeader(OvsForwardingContext *ovsFwdCtx,
+   OvsFlowKey *key,
const struct ovs_key_ethernet *ethAttr)
 {
 PNET_BUFFER curNb;
@@ -1285,9 +1286,11 @@ OvsUpdateEthHeader(OvsForwardingContext *ovsFwdCtx,
 }
 ethHdr = (EthHdr *)(bufferStart + NET_BUFFER_CURRENT_MDL_OFFSET(curNb));

-RtlCopyMemory(ethHdr->Destination, ethAttr->eth_dst,
-   sizeof ethHdr->Destination);
-RtlCopyMemory(ethHdr->Source, ethAttr->eth_src, sizeof ethHdr->Source);
+RtlCopyMemory(ethHdr->Destination, ethAttr->eth_dst, ETH_ADDR_LENGTH);
+RtlCopyMemory(ethHdr->Source, ethAttr->eth_src, ETH_ADDR_LENGTH);
+/* Update l2 flow key */
+RtlCopyMemory(key->l2.dlDst, ethAttr->eth_dst, ETH_ADDR_LENGTH);
+RtlCopyMemory(key->l2.dlSrc, ethAttr->eth_src, ETH_ADDR_LENGTH);

 return NDIS_STATUS_SUCCESS;
 }
@@ -1376,6 +1379,7 @@ PUINT8 OvsGetHeaderBySize(OvsForwardingContext *ovsFwdCtx,
  */
 NDIS_STATUS
 OvsUpdateUdpPorts(OvsForwardingContext *ovsFwdCtx,
+  OvsFlowKey *key,
   const struct ovs_key_udp *udpAttr)
 {
 PUINT8 bufferStart;
@@ -1400,15 +1404,19 @@ OvsUpdateUdpPorts(OvsForwardingContext *ovsFwdCtx,
 udpHdr->check = ChecksumUpdate16(udpHdr->check, udpHdr->source,
  udpAttr->udp_src);
 udpHdr->source = udpAttr->udp_src;
+key->ipKey.l4.tpSrc = udpAttr->udp_src;
 }
 if (udpHdr->dest != udpAttr->udp_dst) {
 udpHdr->check = ChecksumUpdate16(udpHdr->check, udpHdr->dest,
  udpAttr->udp_dst);
 udpHdr->dest = udpAttr->udp_dst;
+key->ipKey.l4.tpDst = udpAttr->udp_dst;
 }
 } else {
 udpHdr->source = udpAttr->udp_src;
+key->ipKey.l4.tpSrc = udpAttr->udp_src;
 udpHdr->dest = udpAttr->udp_dst;
+key->ipKey.l4.tpDst = udpAttr->udp_dst;
 }

 return NDIS_STATUS_SUCCESS;
@@ -1423,6 +1431,7 @@ OvsUpdateUdpPorts(OvsForwardingContext *ovsFwdCtx,
  */
 NDIS_STATUS
 OvsUpdateTcpPorts(OvsForwardingContext *ovsFwdCtx,
+  OvsFlowKey *key,
   const struct ovs_key_tcp *tcpAttr)
 {
 PUINT8 bufferStart;
@@ -1447,11 +1456,13 @@ OvsUpdateTcpPorts(OvsForwardingContext *ovsFwdCtx,
 tcpHdr->check = ChecksumUpdate16(tcpHdr->check, tcpHdr->source,
  tcpAttr->tcp_src);
 tcpHdr->source = tcpAttr->tcp_src;
+key->ipKey.l4.tpSrc = tcpAttr->tcp_src;
 }
 if (tcpHdr->dest != tcpAttr->tcp_dst) {
 tcpHdr->check = ChecksumUpdate16(tcpHdr->check, tcpHdr->dest,
  tcpAttr->tcp_dst);
 tcpHdr->dest = tcpAttr->tcp_dst;
+key->ipKey.l4.tpDst = tcpAttr->tcp_dst;
 }

 return NDIS_STATUS_SUCCESS;
@@ -1579,6 +1590,7 @@ OvsUpdateAddressAndPort(OvsForwardingContext *ovsFwdCtx,
  */
 NDIS_STATUS
 OvsUpdateIPv4Header(OvsForwardingContext *ovsFwdCtx,
+OvsFlowKey *key,
 const struct ovs_key_ipv4 *ipAttr)
 {
 PUINT8 bufferStart;
@@ -1632,6 +1644,7 @@ OvsUpdateIPv4Header(OvsForwardingContext *ovsFwdCtx,
 ipAttr->ipv4_src);
 }
 ipHdr->saddr = ipAttr->ipv4_src;
+key->ipKey.nwSrc = ipAttr->ipv4_src;
 }
 if (ipHdr->daddr != ipAttr->ipv4_dst) {
 if (tcpHdr) {
@@ -1647,6 +1660,7 @@ OvsUpdateIPv4Header(OvsForwardingContext *ovsFwdCtx,
 ipAttr->ipv4_dst);
 }
 ipHdr->daddr = ipAttr->ipv4_dst;
+key->ipKey.nwDst = ipAttr->ipv4_dst;
 }
 if (ipHdr->protocol != 

Re: [ovs-dev] [PATCH ovn v2] Avoid nb_cfg update notification flooding

[Han Zhou]

On Wed, Jul 29, 2020 at 2:46 AM Lucas Alvares Gomes 
wrote:
>
> Hi Han,
>
> >
> > Just to follow up. I didn't find any new versions for this patch and it
> > doesn't seem to be merged. Did you send any new versions or do you still
> > plan to work on this?
> >
>
> Thanks for this follow up.
>
> So I am not currently working on it but the work is still in our
> backlog. Many of the problems that we had with the mechanism
> incrementing the "nb_cfg" has been mitigated by some code in the
> OpenStack side as well as this commit for core OVN [0] that disabled
> flow recomputation upon updates to the Chassis' external_ids column
> (we had a few updates to that column every time the nb_cfg was
> bumped).
>
> But, I can try to check if I can get some prioritization and start
> working again on this patch. Is this something that you need as well ?
>
> [0]
https://github.com/ovn-org/ovn/commit/74d90c2223d0a8c123823fb849b4c2de58c296e4
>
> Cheers,
> Lucas

Thanks Lucas for the update.
Yes, I need it for latency analysis in scale test. I can pick it up. I
rebased on master and also fixed the RBAC issue and some minor updates. I
will post it later this week.

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

Re: [ovs-dev] [ovs-discuss] OVN: configuration in Neutron DB?

[Tony Liu]

Hi Lucas,

Is it OK to discuss OpenStack integration here? Otherwise, please let
me know which OpenStack email list we can use.

I am running networking scaling test. The target is 4K isolated private
networks with external/public access via logical routers. The test in
my previous email is to add 256 routers and set them as gateway. When I
use openstack cli to create a router and set it as gateway immediately,
it doesn’t work some times, Neutron complaints that the router is not
found.

for c in `seq 0 1 255`; do
echo "INFO: $op router-$c..."
openstack router $op router-$c
if [ "$op" == "create" ]; then
openstack router set \
--external-gateway public \
--fixed-ip ip-address=10.6.33.$c \
--disable-snat \
router-$c
fi
done

I thought Neutron API call is synchronous, which means when the client
gets the response for a creation request, the object is created. But
OVN part is async. Is that right? That’s why I was asking reading is
from Neutron DB or OVN DB. If the reading is from Neutron DB, I don’t
understand why the router can not be found when client sets it?
Any thought here?

I changed test script to create all 256 routers first, then set them.
It works fine. It kind of proves that it’s not guaranteed that the
object is ready after receiving the response. I don’t believe this is
expected.

Now, I am adding subnets to router, 16 subnets to 1 router. It’s 4096
networks on 256 routers. It’s quit slow and I am getting some errors.

INFO: Add subnet-1-0 to router-1...
BadRequestException: 400: Client Error for url: 
http://10.6.20.200:9696/v2.0/routers/3d9bff46-4eba-4621-b7c4-3c3062ab8d6e/add_router_interface,
 Bad router request: Router already has a port on subnet 
9d8d1f2d-a401-4ad9-9a72-0d530fba2085.
INFO: Add subnet-1-16 to router-1...
INFO: Add subnet-1-32 to router-1...
ConflictException: 409: Client Error for url: 
http://10.6.20.200:9696/v2.0/routers/3d9bff46-4eba-4621-b7c4-3c3062ab8d6e/add_router_interface,
 IP address 192.168.1.33 already allocated in subnet 
e44dee36-0ee4-4c23-91cf-1ac5b9ee07e0
INFO: Add subnet-1-48 to router-1...
INFO: Add subnet-1-64 to router-1...
HttpException: 500: Server Error for url: 
http://10.6.20.200:9696/v2.0/routers/3d9bff46-4eba-4621-b7c4-3c3062ab8d6e/add_router_interface,
 Request Failed: internal server error while processing your request.

I am not sure if that’s because I add subnets to one router back to back.
I will try another way to add subnet to avoid such back to back requests
to the same router. Will see if that helps.


Thanks!

Tony

From: Lucas Alvares Gomes
Sent: Wednesday, July 29, 2020 2:22 AM
To: Numan Siddique
Cc: Tony Liu; 
ovs-dev@openvswitch.org; Lucas Alvares Gomes 
Martins; 
ovs-disc...@openvswitch.org
Subject: Re: [ovs-dev] [ovs-discuss] OVN: configuration in Neutron DB?

Hi,

On Wed, Jul 29, 2020 at 7:42 AM Numan Siddique  wrote:
>
> Adding Daniel and Lucas. Maybe you can also include opendev ML to get
> appropriate responses from the OpenStack side.
>
> Please see below for few comments.
>
>
> On Wed, Jul 29, 2020 at 12:02 PM Tony Liu  wrote:
>
> > Quick update. I changed the script to create 256 routers first, then set
> > each of them as gateway.
> > There is no create and set back to back. It seems working fine now.
> >
> > It would be good someone can clarify my questions. It seems that it's
> > not guaranteed that the
> > object is ready when client get OK response of creation request. Is this
> > expected?
> >
> >
> > Thanks!
> >
> > Tony
> >
> > --
> > *From:* dev  on behalf of Tony Liu <
> > tonyliu0...@hotmail.com>
> > *Sent:* July 28, 2020 10:37 PM
> > *To:* ovs-disc...@openvswitch.org ;
> > ovs-dev@openvswitch.org 
> > *Subject:* [ovs-dev] OVN: configuration in Neutron DB?
> >
> > Hi,
> >
> > In case of integration with OpenStack, for example, when a client requests
> > to create a network,
> > is this network configuration saved in both Neutron DB and OVN DB, or OVN
> > DB only?
> >
>
> The neutron API first saves in the neutron db and the neutron OVN mechanism
> driver will talk
> to the Northbound ovsdb-server and create corresponding OVN logical
> resources.
>

Both as numans said, it's first created in the Neutron database and
then the OVN plugin is invoked to create that resource in the OVN NB
database. We usually use the "name" column in the OVN NB DB to store
the correspondent Neutron UUID, if the resource has no "name" column
we then use the external_ids columns to do it.

In your example, a Neutron network corresponds to a Logical_Switch in OVN:

stack@lucas-devstack-2:~/neutron$ openstack network create test
| id| 702c4ccd-2f9e-43c8-99a8-4b07a509e105 |
...

Re: [ovs-dev] [PATCH ovn 7/7] ovn-northd.c: Support optionally disabling neighbor learning from ARP request/NS.

[Numan Siddique]

On Thu, Jul 23, 2020 at 10:57 AM Han Zhou  wrote:

> Support a new logical router option "always_learn_from_arp_request" that
> controls
> behavior when handling ARP requests or IPv4 ND-NS packets.
>
> "true" - Always learn the MAC/IP binding and add a new MAC_Binding entry
> (default behavior)
>
> "false" - If there is a MAC_binding for that IP and the MAC is different,
> or,
> if TPA of ARP request belongs to any router port on this router, then
> update/add that MAC/IP binding. Otherwise, don't update/add entries.
>
> Reported-by: Girish Moodalbail 
> Reported-at:
> https://mail.openvswitch.org/pipermail/ovs-discuss/2020-May/049995.html
> Signed-off-by: Han Zhou 
>

Hi Han,

I just gave a quick look. I'll review properly tomorrow.

I just have a few small comments now. I think it's good to add a few tests
in ovn-northd.at
to make sure that ovn-northd programs the flows as expected.


Thanks
Numan

---
>  northd/ovn-northd.8.xml | 109
> 
>  northd/ovn-northd.c |  96 +++---
>  ovn-nb.xml  |  27 
>  tests/ovn.at|  18 
>  4 files changed, 217 insertions(+), 33 deletions(-)
>
> diff --git a/northd/ovn-northd.8.xml b/northd/ovn-northd.8.xml
> index 9f2c70f..30936ab 100644
> --- a/northd/ovn-northd.8.xml
> +++ b/northd/ovn-northd.8.xml
> @@ -1537,58 +1537,126 @@ output;
>  
>For each router port P that owns IP address
> A,
>which belongs to subnet S with prefix length
> L,
> -  a priority-100 flow is added which matches
> -  inport == P 
> -  arp.spa == S/L  arp.op ==
> 1
> -  (ARP request) with the
> -  following actions:
> +  if the option always_learn_from_arp_request is
> +  true for this router, a priority-100 flow is added
> which
> +  matches inport == P  arp.spa ==
> +  S/L  arp.op == 1 (ARP
> request)
> +  with the following actions:
> +
> +
> +
> +reg9[2] = lookup_arp(inport, arp.spa, arp.sha);
> +next;
> +
> +
> +
> +  If the option always_learn_from_arp_request is
> +  false, the following two flows are added.
> +
> +
> +
> +  A priority-110 flow is added which matches inport ==
> +  P  arp.spa == S/L
> +   arp.tpa == A  arp.op == 1
> +  (ARP request) with the following actions:
>  
>
>  
>  reg9[2] = lookup_arp(inport, arp.spa, arp.sha);
> +reg9[3] = 1;
> +next;
> +
> +
> +
> +  A priority-100 flow is added which matches inport ==
> +  P  arp.spa == S/L
> +   arp.op == 1 (ARP request) with the following
> +  actions:
> +
> +
> +
> +reg9[2] = lookup_arp(inport, arp.spa, arp.sha);
> +reg9[3] = lookup_arp_ip(inport, arp.spa);
>  next;
>  
>
>  
>If the logical router port P is a distributed gateway
>router port, additional match
> -  is_chassis_resident(cr-P) is added so
> that
> -  the resident gateway chassis handles the neighbor lookup.
> +  is_chassis_resident(cr-P) is added for
> all
> +  these flows.
>  
>
>
>
>  
>A priority-100 flow which matches on ARP reply packets and
> applies
> -  the actions:
> +  the actions if the option
> always_learn_from_arp_request
> +  is true:
>  
>
>  
>  reg9[2] = lookup_arp(inport, arp.spa, arp.sha);
>  next;
>  
> +
> +
> +  If the option always_learn_from_arp_request
> +  is false, the above actions will be:
> +
> +
> +
> +reg9[2] = lookup_arp(inport, arp.spa, arp.sha);
> +reg9[3] = 1;
> +next;
> +
> +
>
>
>
>  
>A priority-100 flow which matches on IPv6 Neighbor Discovery
> -  advertisement packet and applies the actions:
> +  advertisement packet and applies the actions if the option
> +  always_learn_from_arp_request is true:
>  
>
>  
>  reg9[2] = lookup_nd(inport, nd.target, nd.tll);
>  next;
>  
> +
> +
> +  If the option always_learn_from_arp_request
> +  is false, the above actions will be:
> +
> +
> +
> +reg9[2] = lookup_nd(inport, nd.target, nd.tll);
> +reg9[3] = 1;
> +next;
> +
>
>
>
>  
>A priority-100 flow which matches on IPv6 Neighbor Discovery
> -  solicitation packet and applies the actions:
> +  solicitation packet and applies the actions if the option
> +  always_learn_from_arp_request is true:
> +
> +
> +
> +reg9[2] = lookup_nd(inport, ip6.src, nd.sll);
> +next;
> +
> +
> +
> +  If the option always_learn_from_arp_request
> +  is false, the above actions will be:
>  
>
>

Re: [ovs-dev] [PATCH ovn 6/7] ovn-northd.c: Remove the use of the REGBIT_SKIP_LOOKUP_NEIGHBOR bit.

[Numan Siddique]

On Thu, Jul 23, 2020 at 10:57 AM Han Zhou  wrote:

> In LR ingress stage LOOKUP_NEIGHBOR and LEARN_NEIGHBOR, the flag
> REGBIT_SKIP_LOOKUP_NEIGHBOR was used to indicate if mac-binding
> lookup can be skipped. This patch avoid using the bit by combining
> it with the REGBIT_LOOKUP_NEIGHBOR_RESULT bit, and assigning 1
> to REGBIT_LOOKUP_NEIGHBOR_RESULT serves same purpose of skipping
> the lookup. There will be a new bit needed in a future patch, and
> this change can avoid using too many bits unnecessarily.
>
> Signed-off-by: Han Zhou 
>

Acked-by: Numan Siddique 

Thanks
Numan


> ---
>  northd/ovn-northd.8.xml | 11 ---
>  northd/ovn-northd.c |  6 ++
>  2 files changed, 6 insertions(+), 11 deletions(-)
>
> diff --git a/northd/ovn-northd.8.xml b/northd/ovn-northd.8.xml
> index 741c928..9f2c70f 100644
> --- a/northd/ovn-northd.8.xml
> +++ b/northd/ovn-northd.8.xml
> @@ -1595,7 +1595,7 @@ next;
>
>
>  A priority-0 fallback flow that matches all packets and applies
> -the action reg9[3] = 1; next;
> +the action reg9[2] = 1; next;
>  advancing the packet to the next table.
>
>  
> @@ -1610,17 +1610,14 @@ next;
>
>  
>reg9[2] will be 1 if the
> lookup_arp/lookup_nd
> -  in the previous table was successful.
> -
> -
> -
> -  reg9[3] will be 1 if there was no need to do the
> lookup.
> +  in the previous table was successful, or if there was no need to do
> the
> +  lookup.
>  
>
>  
>
>  A priority-100 flow with the match
> -reg9[2] == 1 || reg9[3] == 1 and advances the packet
> +reg9[2] == 1 and advances the packet
>  to the next table as there is no need to learn the neighbor.
>
>
> diff --git a/northd/ovn-northd.c b/northd/ovn-northd.c
> index 4e11a25..425f522 100644
> --- a/northd/ovn-northd.c
> +++ b/northd/ovn-northd.c
> @@ -221,7 +221,6 @@ enum ovn_stage {
>  /* Register to store the result of check_pkt_larger action. */
>  #define REGBIT_PKT_LARGER"reg9[1]"
>  #define REGBIT_LOOKUP_NEIGHBOR_RESULT "reg9[2]"
> -#define REGBIT_SKIP_LOOKUP_NEIGHBOR "reg9[3]"
>
>  /* Register to store the eth address associated to a router port for
> packets
>   * received in S_ROUTER_IN_ADMISSION.
> @@ -8275,14 +8274,13 @@ build_lrouter_flows(struct hmap *datapaths, struct
> hmap *ports,
>"lookup_nd(inport, ip6.src, nd.sll); next;");
>
>  /* For other packet types, we can skip neighbor learning.
> - * So set REGBIT_SKIP_LOOKUP_NEIGHBOR to 1. */
> + * So set REGBIT_LOOKUP_NEIGHBOR_RESULT to 1. */
>  ovn_lflow_add(lflows, od, S_ROUTER_IN_LOOKUP_NEIGHBOR, 0, "1",
> -  REGBIT_SKIP_LOOKUP_NEIGHBOR" = 1; next;");
> +  REGBIT_LOOKUP_NEIGHBOR_RESULT" = 1; next;");
>
>  /* Flows for LEARN_NEIGHBOR. */
>  /* Skip Neighbor learning if not required. */
>  ovn_lflow_add(lflows, od, S_ROUTER_IN_LEARN_NEIGHBOR, 100,
> -  REGBIT_SKIP_LOOKUP_NEIGHBOR" == 1 || "
>REGBIT_LOOKUP_NEIGHBOR_RESULT" == 1", "next;");
>
>  ovn_lflow_add(lflows, od, S_ROUTER_IN_LEARN_NEIGHBOR, 90,
> --
> 2.1.0
>
> ___
> dev mailing list
> d...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-dev
>
>
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH ovn 5/7] ovn-northd.8.xml: Fix reg9 bits documentation.

[Numan Siddique]

On Thu, Jul 23, 2020 at 10:57 AM Han Zhou  wrote:

> Update the reg9 bits according to current implementation.
>
> Fixes: 2dc7869436de ("ovn-northd: Address scale issues with DNAT flows.")
> Signed-off-by: Han Zhou 
>

Acked-by: Numan Siddique 

Thanks
Numan


> ---
>  northd/ovn-northd.8.xml | 16 
>  1 file changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/northd/ovn-northd.8.xml b/northd/ovn-northd.8.xml
> index 9b1bcec..741c928 100644
> --- a/northd/ovn-northd.8.xml
> +++ b/northd/ovn-northd.8.xml
> @@ -1545,7 +1545,7 @@ output;
>  
>
>  
> -reg9[4] = lookup_arp(inport, arp.spa, arp.sha);
> +reg9[2] = lookup_arp(inport, arp.spa, arp.sha);
>  next;
>  
>
> @@ -1564,7 +1564,7 @@ next;
>  
>
>  
> -reg9[4] = lookup_arp(inport, arp.spa, arp.sha);
> +reg9[2] = lookup_arp(inport, arp.spa, arp.sha);
>  next;
>  
>
> @@ -1576,7 +1576,7 @@ next;
>  
>
>  
> -reg9[4] = lookup_nd(inport, nd.target, nd.tll);
> +reg9[2] = lookup_nd(inport, nd.target, nd.tll);
>  next;
>  
>
> @@ -1588,14 +1588,14 @@ next;
>  
>
>  
> -reg9[4] = lookup_nd(inport, ip6.src, nd.sll);
> +reg9[2] = lookup_nd(inport, ip6.src, nd.sll);
>  next;
>  
>
>
>
>  A priority-0 fallback flow that matches all packets and applies
> -the action reg9[5] = 1; next;
> +the action reg9[3] = 1; next;
>  advancing the packet to the next table.
>
>  
> @@ -1609,18 +1609,18 @@ next;
>  
>
>  
> -  reg9[4] will be 1 if the
> lookup_arp/lookup_nd
> +  reg9[2] will be 1 if the
> lookup_arp/lookup_nd
>in the previous table was successful.
>  
>
>  
> -  reg9[5] will be 1 if there was no need to do the
> lookup.
> +  reg9[3] will be 1 if there was no need to do the
> lookup.
>  
>
>  
>
>  A priority-100 flow with the match
> -reg9[4] == 1 || reg9[5] == 1 and advances the packet
> +reg9[2] == 1 || reg9[3] == 1 and advances the packet
>  to the next table as there is no need to learn the neighbor.
>
>
> --
> 2.1.0
>
> ___
> dev mailing list
> d...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-dev
>
>
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH ovn 3/7] actions: Rename xxx_lookup_mac to xxx_lookup_mac_bind.

[Numan Siddique]

On Thu, Jul 23, 2020 at 10:57 AM Han Zhou  wrote:

> For the functions related to lookup_arp/lookup_nd, renaming them to
> avoid confusion, because those functions checks both mac and ip in
> mac-bindings. This patch renames them so that a future patch can
> add a function that only looks up by ip without confusing names.
>
> This patch also removes the unnecessary OVS_UNUSED for the function
> execute_lookup_mac() in ovn-trace.c.
>
> Signed-off-by: Han Zhou 
>

Acked-by: Numan Siddique 

Thanks
Numan


> ---
>  lib/actions.c | 21 +++--
>  utilities/ovn-trace.c | 13 +++--
>  2 files changed, 18 insertions(+), 16 deletions(-)
>
> diff --git a/lib/actions.c b/lib/actions.c
> index e14907e..82463fa 100644
> --- a/lib/actions.c
> +++ b/lib/actions.c
> @@ -1867,8 +1867,9 @@ ovnact_put_mac_bind_free(struct ovnact_put_mac_bind
> *put_mac OVS_UNUSED)
>  {
>  }
>
> -static void format_lookup_mac(const struct ovnact_lookup_mac_bind
> *lookup_mac,
> -  struct ds *s, const char *name)
> +static void format_lookup_mac_bind(
> +const struct ovnact_lookup_mac_bind *lookup_mac,
> +struct ds *s, const char *name)
>  {
>  expr_field_format(_mac->dst, s);
>  ds_put_format(s, " = %s(", name);
> @@ -1884,21 +1885,21 @@ static void
>  format_LOOKUP_ARP(const struct ovnact_lookup_mac_bind *lookup_mac,
>   struct ds *s)
>  {
> -format_lookup_mac(lookup_mac, s, "lookup_arp");
> +format_lookup_mac_bind(lookup_mac, s, "lookup_arp");
>  }
>
>  static void
>  format_LOOKUP_ND(const struct ovnact_lookup_mac_bind *lookup_mac,
>  struct ds *s)
>  {
> -format_lookup_mac(lookup_mac, s, "lookup_nd");
> +format_lookup_mac_bind(lookup_mac, s, "lookup_nd");
>  }
>
>  static void
> -encode_lookup_mac(const struct ovnact_lookup_mac_bind *lookup_mac,
> -  enum mf_field_id ip_field,
> -  const struct ovnact_encode_params *ep,
> -  struct ofpbuf *ofpacts)
> +encode_lookup_mac_bind(const struct ovnact_lookup_mac_bind *lookup_mac,
> +   enum mf_field_id ip_field,
> +   const struct ovnact_encode_params *ep,
> +   struct ofpbuf *ofpacts)
>  {
>  const struct arg args[] = {
>  { expr_resolve_field(_mac->port), MFF_LOG_INPORT },
> @@ -1928,7 +1929,7 @@ encode_LOOKUP_ARP(const struct
> ovnact_lookup_mac_bind *lookup_mac,
>const struct ovnact_encode_params *ep,
>struct ofpbuf *ofpacts)
>  {
> -encode_lookup_mac(lookup_mac, MFF_REG0, ep, ofpacts);
> +encode_lookup_mac_bind(lookup_mac, MFF_REG0, ep, ofpacts);
>  }
>
>  static void
> @@ -1936,7 +1937,7 @@ encode_LOOKUP_ND(const struct ovnact_lookup_mac_bind
> *lookup_mac,
>  const struct ovnact_encode_params *ep,
>  struct ofpbuf *ofpacts)
>  {
> -encode_lookup_mac(lookup_mac, MFF_XXREG0, ep, ofpacts);
> +encode_lookup_mac_bind(lookup_mac, MFF_XXREG0, ep, ofpacts);
>  }
>
>  static void
> diff --git a/utilities/ovn-trace.c b/utilities/ovn-trace.c
> index de75088..2c432ac 100644
> --- a/utilities/ovn-trace.c
> +++ b/utilities/ovn-trace.c
> @@ -1746,10 +1746,10 @@ execute_get_mac_bind(const struct
> ovnact_get_mac_bind *bind,
>  }
>
>  static void
> -execute_lookup_mac(const struct ovnact_lookup_mac_bind *bind OVS_UNUSED,
> -   const struct ovntrace_datapath *dp OVS_UNUSED,
> -   struct flow *uflow OVS_UNUSED,
> -   struct ovs_list *super OVS_UNUSED)
> +execute_lookup_mac_bind(const struct ovnact_lookup_mac_bind *bind,
> +const struct ovntrace_datapath *dp,
> +struct flow *uflow,
> +struct ovs_list *super)
>  {
>  /* Get logical port number.*/
>  struct mf_subfield port_sf = expr_resolve_field(>port);
> @@ -2214,11 +2214,12 @@ trace_actions(const struct ovnact *ovnacts, size_t
> ovnacts_len,
>  break;
>
>  case OVNACT_LOOKUP_ARP:
> -execute_lookup_mac(ovnact_get_LOOKUP_ARP(a), dp, uflow,
> super);
> +execute_lookup_mac_bind(ovnact_get_LOOKUP_ARP(a), dp, uflow,
> +super);
>  break;
>
>  case OVNACT_LOOKUP_ND:
> -execute_lookup_mac(ovnact_get_LOOKUP_ND(a), dp, uflow, super);
> +execute_lookup_mac_bind(ovnact_get_LOOKUP_ND(a), dp, uflow,
> super);
>  break;
>
>  case OVNACT_PUT_DHCPV4_OPTS:
> --
> 2.1.0
>
> ___
> dev mailing list
> d...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-dev
>
>
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH ovn 2/7] tests: Fix get_arp/get_nd tests mac-binding table id.

[Numan Siddique]

On Thu, Jul 23, 2020 at 10:57 AM Han Zhou  wrote:

> The table id used in test is not the same as the one used in
> real implementation. Although it doesn't affect correctness, it
> may cause confusion when people are studying test cases.
>
> Signed-off-by: Han Zhou 
>

Acked-by: Numan Siddique 

Thanks
Numan


> ---
>  tests/ovn.at |  8 
>  tests/test-ovn.c | 11 ++-
>  2 files changed, 10 insertions(+), 9 deletions(-)
>
> diff --git a/tests/ovn.at b/tests/ovn.at
> index e19efaf..b06642b 100644
> --- a/tests/ovn.at
> +++ b/tests/ovn.at
> @@ -1181,10 +1181,10 @@ arp { };
>
>  # get_arp
>  get_arp(outport, ip4.dst);
> -encodes as
> push:NXM_NX_REG0[],push:NXM_OF_IP_DST[],pop:NXM_NX_REG0[],set_field:00:00:00:00:00:00->eth_dst,resubmit(,65),pop:NXM_NX_REG0[]
> +encodes as
> push:NXM_NX_REG0[],push:NXM_OF_IP_DST[],pop:NXM_NX_REG0[],set_field:00:00:00:00:00:00->eth_dst,resubmit(,66),pop:NXM_NX_REG0[]
>  has prereqs eth.type == 0x800
>  get_arp(inport, reg0);
> -encodes as
> push:NXM_NX_REG15[],push:NXM_NX_REG0[],push:NXM_NX_XXREG0[96..127],push:NXM_NX_REG14[],pop:NXM_NX_REG15[],pop:NXM_NX_REG0[],set_field:00:00:00:00:00:00->eth_dst,resubmit(,65),pop:NXM_NX_REG0[],pop:NXM_NX_REG15[]
> +encodes as
> push:NXM_NX_REG15[],push:NXM_NX_REG0[],push:NXM_NX_XXREG0[96..127],push:NXM_NX_REG14[],pop:NXM_NX_REG15[],pop:NXM_NX_REG0[],set_field:00:00:00:00:00:00->eth_dst,resubmit(,66),pop:NXM_NX_REG0[],pop:NXM_NX_REG15[]
>
>  get_arp;
>  Syntax error at `;' expecting `('.
> @@ -1299,10 +1299,10 @@ nd_na_router { eth.src = 12:34:56:78:9a:bc; nd.tll
> = 12:34:56:78:9a:bc; outport
>
>  # get_nd
>  get_nd(outport, ip6.dst);
> -encodes as
> push:NXM_NX_XXREG0[],push:NXM_NX_IPV6_DST[],pop:NXM_NX_XXREG0[],set_field:00:00:00:00:00:00->eth_dst,resubmit(,65),pop:NXM_NX_XXREG0[]
> +encodes as
> push:NXM_NX_XXREG0[],push:NXM_NX_IPV6_DST[],pop:NXM_NX_XXREG0[],set_field:00:00:00:00:00:00->eth_dst,resubmit(,66),pop:NXM_NX_XXREG0[]
>  has prereqs eth.type == 0x86dd
>  get_nd(inport, xxreg0);
> -encodes as
> push:NXM_NX_REG15[],push:NXM_NX_REG14[],pop:NXM_NX_REG15[],set_field:00:00:00:00:00:00->eth_dst,resubmit(,65),pop:NXM_NX_REG15[]
> +encodes as
> push:NXM_NX_REG15[],push:NXM_NX_REG14[],pop:NXM_NX_REG15[],set_field:00:00:00:00:00:00->eth_dst,resubmit(,66),pop:NXM_NX_REG15[]
>  get_nd;
>  Syntax error at `;' expecting `('.
>  get_nd();
> diff --git a/tests/test-ovn.c b/tests/test-ovn.c
> index c3bfd20..ba62828 100644
> --- a/tests/test-ovn.c
> +++ b/tests/test-ovn.c
> @@ -39,6 +39,7 @@
>  #include "openvswitch/shash.h"
>  #include "simap.h"
>  #include "util.h"
> +#include "controller/lflow.h"
>
>  /* --relops: Bitmap of the relational operators to test, in exhaustive
> test. */
>  static unsigned int test_relops;
> @@ -1333,11 +1334,11 @@ test_parse_actions(struct ovs_cmdl_context *ctx
> OVS_UNUSED)
>  .meter_table = _table,
>
>  .pipeline = OVNACT_P_INGRESS,
> -.ingress_ptable = 8,
> -.egress_ptable = 40,
> -.output_ptable = 64,
> -.mac_bind_ptable = 65,
> -.mac_lookup_ptable = 67,
> +.ingress_ptable = OFTABLE_LOG_INGRESS_PIPELINE,
> +.egress_ptable = OFTABLE_LOG_EGRESS_PIPELINE,
> +.output_ptable = OFTABLE_SAVE_INPORT,
> +.mac_bind_ptable = OFTABLE_MAC_BINDING,
> +.mac_lookup_ptable = OFTABLE_MAC_LOOKUP,
>  };
>  struct ofpbuf ofpacts;
>  ofpbuf_init(, 0);
> --
> 2.1.0
>
> ___
> dev mailing list
> d...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-dev
>
>
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH ovn 1/7] ovn-northd: Support optionally avoid static neighbor flows in routers.

[Numan Siddique]

On Thu, Jul 23, 2020 at 10:57 AM Han Zhou  wrote:

> Support option:dynamic_neigh_routers for logical routers, so that in
> particular use cases static neighbor flows are not prepopulated IP
> addresses belonging to neighbor router ports, to avoid flow exploding
> problem reported for ovn-kubernetes large scale setup.
>
> Reported-by: Girish Moodalbail 
> Reported-at:
> https://mail.openvswitch.org/pipermail/ovs-discuss/2020-May/049995.html
> Signed-off-by: Han Zhou 
> ---
>

Hi Han,

The patch LGTM. Can you please add few tests in ovn-northd.at and make sure
that the
lflows are not programmed by ovn-northd when  options:dynamic_neigh_routers
is set to true.

Thanks
Numan

 northd/ovn-northd.8.xml |  5 -
>  northd/ovn-northd.c |  6 ++
>  ovn-nb.xml  | 13 +
>  3 files changed, 23 insertions(+), 1 deletion(-)
>
> diff --git a/northd/ovn-northd.8.xml b/northd/ovn-northd.8.xml
> index eb2514f..9b1bcec 100644
> --- a/northd/ovn-northd.8.xml
> +++ b/northd/ovn-northd.8.xml
> @@ -2701,7 +2701,10 @@ outport = P;
>Logical_Switch_Port table.  For router ports
>connected to other logical routers, MAC bindings can be known
>statically from the mac and networks
> -  column in the Logical_Router_Port table.
> +  column in the Logical_Router_Port table.  (Note:
> the
> +  flow is NOT installed for the IP addresses that belong to a
> neighbor
> +  logical router port if the current router has the
> +  options:dynamic_neigh_routers set to
> true)
>  
>
>  
> diff --git a/northd/ovn-northd.c b/northd/ovn-northd.c
> index 1921982..4e11a25 100644
> --- a/northd/ovn-northd.c
> +++ b/northd/ovn-northd.c
> @@ -10202,6 +10202,12 @@ build_lrouter_flows(struct hmap *datapaths,
> struct hmap *ports,
>  continue;
>  }
>
> +if (peer->od->nbr &&
> +smap_get_bool(>od->nbr->options,
> +  "dynamic_neigh_routers", false)) {
> +continue;
> +}
> +
>  for (size_t i = 0; i < op->od->n_router_ports; i++) {
>  const char *router_port_name = smap_get(
>
>  >od->router_ports[i]->nbsp->options,
> diff --git a/ovn-nb.xml b/ovn-nb.xml
> index db5908c..e8450aa 100644
> --- a/ovn-nb.xml
> +++ b/ovn-nb.xml
> @@ -1846,6 +1846,19 @@
>connected to the logical router. Default: False.
>  
>
> +  
> +
> +  If set to true, the router will resolve neighbor
> +  routers' MAC addresses only by dynamic ARP/ND, instead of
> +  prepopulating static mappings for all neighbor routers in the
> ARP/ND
> +  Resolution stage.  This reduces number of flows, but requires
> ARP/ND
> +  messages to resolve the IP-MAC bindings when needed.  It is
> +  false by default.  It is recommended to set to
> +  true when a large number of logical routers are
> +  connected to the same logical switch but most of them never
> need to
> +  send traffic between each other.
> +
> +  
>  
>
>  
> --
> 2.1.0
>
> ___
> dev mailing list
> d...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-dev
>
>
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] Your help

[Mrs. Elizabeth Smith]

May the peace of God be with you and your family.I know it will be a
great surprise reading from me today but consider this a divine
intervention as a pastor explained to my understanding. My name is
Mrs. Elizabeth Smith .G, a widow from Oklahoma USA and am writing you
from my sick bed because i have been fighting cancer and the doctors
says i have only few weeks left. I want to entrust my money ($8.5
million USD) to your care for charity purposes to help the less
privileged as my late husbands relatives want me dead so that they
will claim all my late husband and i worked for.

I will tell you more about myself and what you need to do with the
money once your receive it.Please write me soon as my health is pretty
bad and my doctors says i will be moved to the intensive care unit
anytime soon.Have a blessed day and please do pray for me.God bless
you.

Yours Mrs. Elizabeth Smith .G
Email: ( owor...@yahoo.com)
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH v3] odp-util: Fix clearing match mask if set action is partially unnecessary.

[Adrian Moreno]

Verified that v3 also solves the issue reported.

Tested-by: Adrián Moreno 

On 7/29/20 12:37 PM, Eli Britstein wrote:
> Thanks!
> 
> Acked-by: Eli Britstein 
> 
> On 7/29/2020 12:13 PM, Ilya Maximets wrote:
>> While committing set() actions, commit() could wildcard all the fields
>> that are same in match key and in the set action.  This leads to
>> situation where mask after commit could actually contain less bits
>> than it was before.  And if set action was partially committed, all
>> the fields that were the same will be cleared out from the matching key
>> resulting in the incorrect (too wide) flow.
>>
>> For example, for the flow that matches on both src and dst mac
>> addresses, if the dst mac is the same and only src should be changed
>> by the set() action, destination address will be wildcarded in the
>> match key and will never be matched, i.e. flows with any destination
>> mac will match, which is not correct.
>>
>> Setting OF rule:
>>
>>   in_port=1,dl_src=50:54:00:00:00:09
>> actions=mod_dl_dst(50:54:00:00:00:0a),output(2)
>>
>> Sending following packets on port 1:
>>
>>    1. eth(src=50:54:00:00:00:09,dst=50:54:00:00:00:0a),eth_type(0x0800)
>>    2. eth(src=50:54:00:00:00:09,dst=50:54:00:00:00:0c),eth_type(0x0800)
>>    3. eth(src=50:54:00:00:00:0b,dst=50:54:00:00:00:0c),eth_type(0x0800)
>>
>> Resulted datapath flows:
>>    eth(dst=50:54:00:00:00:0c),<...>, 
>> actions:set(eth(dst=50:54:00:00:00:0a)),2
>>    eth(src=50:54:00:00:00:09,dst=50:54:00:00:00:0a),<...>, actions:2
>>
>> The first flow  doesn't have any match on source MAC address and the
>> third packet successfully matched on it while it must be dropped.
>>
>> Fix that by updating the match mask with only the new bits set by
>> commit(), but keeping those that were cleared (OR operation).
>>
>> With fix applied, resulted correct flows are:
>>    eth(src=50:54:00:00:00:09,dst=50:54:00:00:00:0a),<...>, actions:2
>>    eth(src=50:54:00:00:00:09,dst=50:54:00:00:00:0c),<...>,
>>  
>> actions:set(eth(dst=50:54:00:00:00:0a)),2
>>    eth(src=50:54:00:00:00:0b),<...>, actions:drop
>>
>> The code before commit dbf4a92800d0 was not able to reduce the mask,
>> it was only possible to expand it to exact match, so it was OK to
>> update original matching mask with the new value in all cases.
>>
>> Fixes: dbf4a92800d0 ("odp-util: Do not rewrite fields with the same values as
>> matched")
>> Reported-at:
>> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugzilla.redhat.com%2Fshow_bug.cgi%3Fid%3D1854376data=02%7C01%7Celibr%40mellanox.com%7C7d70b87d6084436b6ff608d8339fb47b%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C637316108313661481sdata=pa3tutGAU3%2BRuRy8y2rjb7AdBouIZrbX4iAE87YXrTY%3Dreserved=0
>>
>> Signed-off-by: Ilya Maximets 
>> ---
>>
>> Version 3:
>>    - Implemented more accurate solution with OR-ing of the original
>>  and resulted masks to avoid any dependencies from the internals
>>  of commit() function.
>>
>> Version 2:
>>    - Added simple unit test for this issue.
>>    - Added 'Tested-by' tag.
>>    - Refined comments.
>>
>>
>>   lib/odp-util.c    | 67 ---
>>   lib/util.c    | 13 +
>>   lib/util.h    |  1 +
>>   tests/ofproto-dpif.at | 23 +++
>>   4 files changed, 88 insertions(+), 16 deletions(-)
>>
>> diff --git a/lib/odp-util.c b/lib/odp-util.c
>> index 011db9ebb..e54a78b43 100644
>> --- a/lib/odp-util.c
>> +++ b/lib/odp-util.c
>> @@ -7701,6 +7701,28 @@ struct offsetof_sizeof {
>>   int size;
>>   };
>>   +
>> +/* Performs bitwise OR over the fields in 'dst_' and 'src_' specified in
>> + * 'offsetof_sizeof_arr' array.  Result is stored in 'dst_'. */
>> +static void
>> +or_masks(void *dst_, const void *src_,
>> + struct offsetof_sizeof *offsetof_sizeof_arr)
>> +{
>> +    int field, size, offset;
>> +    const uint8_t *src = src_;
>> +    uint8_t *dst = dst_;
>> +
>> +    for (field = 0; ; field++) {
>> +    size   = offsetof_sizeof_arr[field].size;
>> +    offset = offsetof_sizeof_arr[field].offset;
>> +
>> +    if (!size) {
>> +    return;
>> +    }
>> +    or_bytes(dst + offset, src + offset, size);
>> +    }
>> +}
>> +
>>   /* Compares each of the fields in 'key0' and 'key1'.  The fields are 
>> specified
>>    * in 'offsetof_sizeof_arr', which is an array terminated by a 0-size 
>> field.
>>    * Returns true if all of the fields are equal, false if at least one 
>> differs.
>> @@ -7779,9 +7801,10 @@ commit_set_ether_action(const struct flow *flow, 
>> struct
>> flow *base_flow,
>>   struct flow_wildcards *wc,
>>   bool use_masked)
>>   {
>> -    struct ovs_key_ethernet key, base, mask;
>> +    struct ovs_key_ethernet key, base, mask, orig_mask;
>>   struct offsetof_sizeof ovs_key_ethernet_offsetof_sizeof_arr[] =
>>   OVS_KEY_ETHERNET_OFFSETOF_SIZEOF_ARR;
>> +
>>   if 

Re: [ovs-dev] [PATCH ovn v3 0/5] Add ECMP symmetric replies

[Numan Siddique]

On Wed, Jul 29, 2020 at 1:54 AM Mark Michelson  wrote:

> In some cases, it is important that traffic that arrived over an ECMP
> route has its replies sent out over that same route. This series of
> commits adds some prerequisite changes in order to facilitate using
> conntrack labels to store information about the incoming traffic. The
> final commit adds the new feature, storing the source MAC and incoming
> logical router port for new incoming connections over an ECMP route. The
> feature is only used if a specific option is set, and it may only be
> used in gateway routers.
>
>
Acked-by: Numan Siddique  for the entire series.

Thanks
Numan


> ---
> v3 -> v4
> * Rebased to current master
> * Fixed failing conntrack fields test
> * Bumped ovn-nb minor version.
> v2 -> v3
> * Added this cover letter
> * Added writeability scope commit to series
> * Added assignment writeability alteration commit to series
> * Added test to ovn.at to ensure flows are only present on gateway
>   routers
> * Changed the bits used in the ct_label. Previous commits used bits
>   0-63. This commit changes it to use bits 32-95.
> v1 -> v2
> * Fixed test failures
> ---
> Mark Michelson (5):
>   Add IP address normalization to ovn-utils.
>   Don't check for writeability of rhs during assignment.
>   Add expression writeability scopes.
>   Used nested actions in ct_commit
>   Add ECMP symmetric replies.
>
>  include/ovn/actions.h |   9 +-
>  include/ovn/expr.h|  53 +++---
>  lib/actions.c | 154 
>  lib/expr.c|  35 ---
>  lib/logical-fields.c  |  15 ++-
>  lib/ovn-util.c|  39 +++
>  lib/ovn-util.h|   4 +
>  northd/ovn-northd.8.xml   |  49 +++--
>  northd/ovn-northd.c   | 131 
>  ovn-architecture.7.xml|   7 +-
>  ovn-nb.ovsschema  |   5 +-
>  ovn-nb.xml|  16 +++
>  ovn-sb.xml|  11 +-
>  tests/ovn.at  | 210 +++---
>  tests/system-ovn.at   | 144 ++
>  utilities/ovn-nbctl.8.xml |  31 --
>  utilities/ovn-nbctl.c |  47 +++--
>  17 files changed, 695 insertions(+), 265 deletions(-)
>
> --
> 2.25.4
>
> ___
> dev mailing list
> d...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-dev
>
>
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] Altium - Proposal

[Kelsey Cooper via dev]

Hi,

 
Would you like to send in your Business Proposals/Newsletter to key decision 
Makers from companies currently using Altium Software?

 
Titles Like:  IT Decision Makers, C-level, Managers and other job titles as per 
your requirement. 

 
Kindly let me know the Job Titles & Geography that you wish to target, so that 
I can get back with the samples, counts and more details for your review. 

 
We cater other Industry contacts such as: Manufacturing, Construction, 
Education, Retail, Healthcare, Energy, Utilities & Waste Treatment, 
Transportation, etc. 

 
Looking forward to your response.

 
Regards,

Kelsey Cooper - Marketing Executive

 
Stay safe.

Reply back “Pass” for no further emails.

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

[ovs-dev] [PATCH net-next v3 2/2] net: openvswitch: make masks cache size configurable

[Eelco Chaudron]

This patch makes the masks cache size configurable, or with
a size of 0, disable it.

Reviewed-by: Paolo Abeni 
Signed-off-by: Eelco Chaudron 
---
Changes in v3:
 - Use is_power_of_2() function
 - Use array_size() function
 - Fix remaining sparse errors

Changes in v2:
 - Fix sparse warnings
 - Fix netlink policy items reported by Florian Westphal

 include/uapi/linux/openvswitch.h |1 
 net/openvswitch/datapath.c   |   14 +
 net/openvswitch/flow_table.c |   97 +-
 net/openvswitch/flow_table.h |   10 
 4 files changed, 108 insertions(+), 14 deletions(-)

diff --git a/include/uapi/linux/openvswitch.h b/include/uapi/linux/openvswitch.h
index 7cb76e5ca7cf..8300cc29dec8 100644
--- a/include/uapi/linux/openvswitch.h
+++ b/include/uapi/linux/openvswitch.h
@@ -86,6 +86,7 @@ enum ovs_datapath_attr {
OVS_DP_ATTR_MEGAFLOW_STATS, /* struct ovs_dp_megaflow_stats */
OVS_DP_ATTR_USER_FEATURES,  /* OVS_DP_F_*  */
OVS_DP_ATTR_PAD,
+   OVS_DP_ATTR_MASKS_CACHE_SIZE,
__OVS_DP_ATTR_MAX
 };
 
diff --git a/net/openvswitch/datapath.c b/net/openvswitch/datapath.c
index a54df1fe3ec4..114b2ddb8037 100644
--- a/net/openvswitch/datapath.c
+++ b/net/openvswitch/datapath.c
@@ -1498,6 +1498,7 @@ static size_t ovs_dp_cmd_msg_size(void)
msgsize += nla_total_size_64bit(sizeof(struct ovs_dp_stats));
msgsize += nla_total_size_64bit(sizeof(struct ovs_dp_megaflow_stats));
msgsize += nla_total_size(sizeof(u32)); /* OVS_DP_ATTR_USER_FEATURES */
+   msgsize += nla_total_size(sizeof(u32)); /* OVS_DP_ATTR_MASKS_CACHE_SIZE 
*/
 
return msgsize;
 }
@@ -1535,6 +1536,10 @@ static int ovs_dp_cmd_fill_info(struct datapath *dp, 
struct sk_buff *skb,
if (nla_put_u32(skb, OVS_DP_ATTR_USER_FEATURES, dp->user_features))
goto nla_put_failure;
 
+   if (nla_put_u32(skb, OVS_DP_ATTR_MASKS_CACHE_SIZE,
+   ovs_flow_tbl_masks_cache_size(>table)))
+   goto nla_put_failure;
+
genlmsg_end(skb, ovs_header);
return 0;
 
@@ -1599,6 +1604,13 @@ static int ovs_dp_change(struct datapath *dp, struct 
nlattr *a[])
 #endif
}
 
+   if (a[OVS_DP_ATTR_MASKS_CACHE_SIZE]) {
+   u32 cache_size;
+
+   cache_size = nla_get_u32(a[OVS_DP_ATTR_MASKS_CACHE_SIZE]);
+   ovs_flow_tbl_masks_cache_resize(>table, cache_size);
+   }
+
dp->user_features = user_features;
 
if (dp->user_features & OVS_DP_F_TC_RECIRC_SHARING)
@@ -1894,6 +1906,8 @@ static const struct nla_policy 
datapath_policy[OVS_DP_ATTR_MAX + 1] = {
[OVS_DP_ATTR_NAME] = { .type = NLA_NUL_STRING, .len = IFNAMSIZ - 1 },
[OVS_DP_ATTR_UPCALL_PID] = { .type = NLA_U32 },
[OVS_DP_ATTR_USER_FEATURES] = { .type = NLA_U32 },
+   [OVS_DP_ATTR_MASKS_CACHE_SIZE] =  NLA_POLICY_RANGE(NLA_U32, 0,
+   PCPU_MIN_UNIT_SIZE / sizeof(struct mask_cache_entry)),
 };
 
 static const struct genl_ops dp_datapath_genl_ops[] = {
diff --git a/net/openvswitch/flow_table.c b/net/openvswitch/flow_table.c
index a5912ea05352..5280aeeef628 100644
--- a/net/openvswitch/flow_table.c
+++ b/net/openvswitch/flow_table.c
@@ -38,8 +38,8 @@
 #define MASK_ARRAY_SIZE_MIN16
 #define REHASH_INTERVAL(10 * 60 * HZ)
 
+#define MC_DEFAULT_HASH_ENTRIES256
 #define MC_HASH_SHIFT  8
-#define MC_HASH_ENTRIES(1u << MC_HASH_SHIFT)
 #define MC_HASH_SEGS   ((sizeof(uint32_t) * 8) / MC_HASH_SHIFT)
 
 static struct kmem_cache *flow_cache;
@@ -341,15 +341,75 @@ static void flow_mask_remove(struct flow_table *tbl, 
struct sw_flow_mask *mask)
}
 }
 
+static void __mask_cache_destroy(struct mask_cache *mc)
+{
+   if (mc->mask_cache)
+   free_percpu(mc->mask_cache);
+   kfree(mc);
+}
+
+static void mask_cache_rcu_cb(struct rcu_head *rcu)
+{
+   struct mask_cache *mc = container_of(rcu, struct mask_cache, rcu);
+
+   __mask_cache_destroy(mc);
+}
+
+static struct mask_cache *tbl_mask_cache_alloc(u32 size)
+{
+   struct mask_cache_entry __percpu *cache = NULL;
+   struct mask_cache *new;
+
+   /* Only allow size to be 0, or a power of 2, and does not exceed
+* percpu allocation size.
+*/
+   if ((!is_power_of_2(size) && size != 0) ||
+   (size * sizeof(struct mask_cache_entry)) > PCPU_MIN_UNIT_SIZE)
+   return NULL;
+
+   new = kzalloc(sizeof(*new), GFP_KERNEL);
+   if (!new)
+   return NULL;
+
+   new->cache_size = size;
+   if (new->cache_size > 0) {
+   cache = __alloc_percpu(array_size(sizeof(struct 
mask_cache_entry),
+ new->cache_size),
+  __alignof__(struct mask_cache_entry));
+   if (!cache) {
+   kfree(new);
+   return NULL;
+   }
+   }
+

[ovs-dev] [PATCH net-next v3 1/2] net: openvswitch: add masks cache hit counter

[Eelco Chaudron]

Add a counter that counts the number of masks cache hits, and
export it through the megaflow netlink statistics.

Reviewed-by: Paolo Abeni 
Reviewed-by: Tonghao Zhang 
Signed-off-by: Eelco Chaudron 
---
 include/uapi/linux/openvswitch.h |2 +-
 net/openvswitch/datapath.c   |5 -
 net/openvswitch/datapath.h   |3 +++
 net/openvswitch/flow_table.c |   19 ++-
 net/openvswitch/flow_table.h |3 ++-
 5 files changed, 24 insertions(+), 8 deletions(-)

diff --git a/include/uapi/linux/openvswitch.h b/include/uapi/linux/openvswitch.h
index 9b14519e74d9..7cb76e5ca7cf 100644
--- a/include/uapi/linux/openvswitch.h
+++ b/include/uapi/linux/openvswitch.h
@@ -102,8 +102,8 @@ struct ovs_dp_megaflow_stats {
__u64 n_mask_hit;/* Number of masks used for flow lookups. */
__u32 n_masks;   /* Number of masks for the datapath. */
__u32 pad0;  /* Pad for future expension. */
+   __u64 n_cache_hit;   /* Number of cache matches for flow lookups. */
__u64 pad1;  /* Pad for future expension. */
-   __u64 pad2;  /* Pad for future expension. */
 };
 
 struct ovs_vport_stats {
diff --git a/net/openvswitch/datapath.c b/net/openvswitch/datapath.c
index 95805f0e27bd..a54df1fe3ec4 100644
--- a/net/openvswitch/datapath.c
+++ b/net/openvswitch/datapath.c
@@ -225,13 +225,14 @@ void ovs_dp_process_packet(struct sk_buff *skb, struct 
sw_flow_key *key)
struct dp_stats_percpu *stats;
u64 *stats_counter;
u32 n_mask_hit;
+   u32 n_cache_hit;
int error;
 
stats = this_cpu_ptr(dp->stats_percpu);
 
/* Look up flow. */
flow = ovs_flow_tbl_lookup_stats(>table, key, skb_get_hash(skb),
-_mask_hit);
+_mask_hit, _cache_hit);
if (unlikely(!flow)) {
struct dp_upcall_info upcall;
 
@@ -262,6 +263,7 @@ void ovs_dp_process_packet(struct sk_buff *skb, struct 
sw_flow_key *key)
u64_stats_update_begin(>syncp);
(*stats_counter)++;
stats->n_mask_hit += n_mask_hit;
+   stats->n_cache_hit += n_cache_hit;
u64_stats_update_end(>syncp);
 }
 
@@ -699,6 +701,7 @@ static void get_dp_stats(const struct datapath *dp, struct 
ovs_dp_stats *stats,
stats->n_missed += local_stats.n_missed;
stats->n_lost += local_stats.n_lost;
mega_stats->n_mask_hit += local_stats.n_mask_hit;
+   mega_stats->n_cache_hit += local_stats.n_cache_hit;
}
 }
 
diff --git a/net/openvswitch/datapath.h b/net/openvswitch/datapath.h
index 697a2354194b..86d78613edb4 100644
--- a/net/openvswitch/datapath.h
+++ b/net/openvswitch/datapath.h
@@ -38,12 +38,15 @@
  * @n_mask_hit: Number of masks looked up for flow match.
  *   @n_mask_hit / (@n_hit + @n_missed)  will be the average masks looked
  *   up per packet.
+ * @n_cache_hit: The number of received packets that had their mask found using
+ * the mask cache.
  */
 struct dp_stats_percpu {
u64 n_hit;
u64 n_missed;
u64 n_lost;
u64 n_mask_hit;
+   u64 n_cache_hit;
struct u64_stats_sync syncp;
 };
 
diff --git a/net/openvswitch/flow_table.c b/net/openvswitch/flow_table.c
index af22c9ee28dd..a5912ea05352 100644
--- a/net/openvswitch/flow_table.c
+++ b/net/openvswitch/flow_table.c
@@ -667,6 +667,7 @@ static struct sw_flow *flow_lookup(struct flow_table *tbl,
   struct mask_array *ma,
   const struct sw_flow_key *key,
   u32 *n_mask_hit,
+  u32 *n_cache_hit,
   u32 *index)
 {
u64 *usage_counters = this_cpu_ptr(ma->masks_usage_cntr);
@@ -682,6 +683,7 @@ static struct sw_flow *flow_lookup(struct flow_table *tbl,
u64_stats_update_begin(>syncp);
usage_counters[*index]++;
u64_stats_update_end(>syncp);
+   (*n_cache_hit)++;
return flow;
}
}
@@ -719,7 +721,8 @@ static struct sw_flow *flow_lookup(struct flow_table *tbl,
 struct sw_flow *ovs_flow_tbl_lookup_stats(struct flow_table *tbl,
  const struct sw_flow_key *key,
  u32 skb_hash,
- u32 *n_mask_hit)
+ u32 *n_mask_hit,
+ u32 *n_cache_hit)
 {
struct mask_array *ma = rcu_dereference(tbl->mask_array);
struct table_instance *ti = rcu_dereference(tbl->ti);
@@ -729,10 +732,13 @@ struct sw_flow *ovs_flow_tbl_lookup_stats(struct 
flow_table *tbl,
int seg;
 
*n_mask_hit = 0;
+   *n_cache_hit = 0;
 

[ovs-dev] [PATCH net-next v3 0/2] net: openvswitch: masks cache enhancements

[Eelco Chaudron]

This patchset adds two enhancements to the Open vSwitch masks cache.

Signed-off-by: Eelco Chaudron 

Changes in v3 [patch 2/2 only]:
 - Use is_power_of_2() function
 - Use array_size() function
 - Fix remaining sparse errors

Changes in v2 [patch 2/2 only]:
 - Fix sparse warnings
 - Fix netlink policy items reported by Florian Westphal

Eelco Chaudron (2):
  net: openvswitch: add masks cache hit counter
  net: openvswitch: make masks cache size configurable


 include/uapi/linux/openvswitch.h |3 +
 net/openvswitch/datapath.c   |   19 ++
 net/openvswitch/datapath.h   |3 +
 net/openvswitch/flow_table.c |  116 --
 net/openvswitch/flow_table.h |   13 
 5 files changed, 132 insertions(+), 22 deletions(-)

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

[ovs-dev] [PATCH v2 2/3] dpif-netdev/avx512: add -fPIC flag to enable shared builds

[Harry van Haaren]

In certain scenarios with OVS built with --enable-shared and
DPDK enabled as shared build too, Position Independant Code
is required to link the avx512.a file into the relocatable .so
that it must be linked into.

Signed-off-by: Harry van Haaren 

---

v3:
- Note this patch fixes a potential build issue that is only exposed
  with future DPDK Meson integration, and not an issue today. Ensuring
  OVS 2.14 release is compatible with DPDK Meson builds will ease the
  future porting to meson, so is worth including now.
---
 lib/automake.mk | 1 +
 1 file changed, 1 insertion(+)

diff --git a/lib/automake.mk b/lib/automake.mk
index 218dc7313..380a67228 100644
--- a/lib/automake.mk
+++ b/lib/automake.mk
@@ -34,6 +34,7 @@ lib_libopenvswitchavx512_la_CFLAGS = \
-mavx512bw \
-mavx512dq \
-mbmi2 \
+   -fPIC \
$(AM_CFLAGS)
 lib_libopenvswitchavx512_la_SOURCES = \
lib/dpif-netdev-lookup-avx512-gather.c
-- 
2.17.1

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

[ovs-dev] [PATCH v2 3/3] configure: explicitly disable avx512 if bintuils check fails

[Harry van Haaren]

This commit explicitly disables avx512f if the binutils assembler
check fails to correctly assemble its input.

Without this fix, there is a possibility that users can see undefined
behaviour when compiling with -march=native on a CPU which supports
avx512 and with a buggy binutils version (v2.30 and 2.31), without a
backported fix, if the compiler's vectorizing optimizations convert
scalar code to avx512 instructions.

Signed-off-by: Harry van Haaren 

---

Note that the compiler autovectorization with binutils bug could be
present in previous releases, and was not introduced with the 2.14
dpcls avx512 optimizations. The explict adding of dpcls avx512 opts
added the binutils checks to easily modify CFLAGS to fix the issue.

---
 m4/openvswitch.m4 | 4 
 1 file changed, 4 insertions(+)

diff --git a/m4/openvswitch.m4 b/m4/openvswitch.m4
index 7c9a507e5..6fe79297e 100644
--- a/m4/openvswitch.m4
+++ b/m4/openvswitch.m4
@@ -426,8 +426,12 @@ AC_DEFUN([OVS_CHECK_BINUTILS_AVX512],
  CFLAGS="$CFLAGS -DHAVE_LD_AVX512_GOOD"
else
  ovs_cv_binutils_avx512_good=no
+ dnl Explicitly disallow avx512f to stop compiler auto-vectorizing
+ dnl and causing zmm usage with buggy binutils versions.
+ CFLAGS="$CFLAGS -mno-avx512f"
fi
  else
+   dnl non x86_64 architectures don't have avx512, so not affected
ovs_cv_binutils_avx512_good=no
  fi])
  rm $OBJFILE
-- 
2.17.1

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

[ovs-dev] [PATCH v2 1/3] dpif-netdev/avx512: avoid compiling avx512 code if binutils check fails

[Harry van Haaren]

This commit avoids compiling and linking of avx512 code into the
vswitch_la library if the binutils check fails. This avoids compiling
code into OVS that will not be executed due to binutils issue.

Signed-off-by: Harry van Haaren 

---

v3:
- Reword commit title & description
---
 lib/automake.mk | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/lib/automake.mk b/lib/automake.mk
index 920c958e3..218dc7313 100644
--- a/lib/automake.mk
+++ b/lib/automake.mk
@@ -22,6 +22,7 @@ lib_libopenvswitch_la_LDFLAGS = \
 $(AM_LDFLAGS)
 
 if HAVE_AVX512F
+if HAVE_LD_AVX512_GOOD
 # Build library of avx512 code with CPU ISA CFLAGS enabled. This allows the
 # compiler to use the ISA features required for the ISA optimized code-paths.
 # Use LDFLAGS to compile only static library of this code, as it should be
@@ -39,6 +40,7 @@ lib_libopenvswitchavx512_la_SOURCES = \
 lib_libopenvswitchavx512_la_LDFLAGS = \
-static
 endif
+endif
 
 # Build core vswitch libraries as before
 lib_libopenvswitch_la_SOURCES = \
-- 
2.17.1

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

Re: [ovs-dev] [PATCH v3] odp-util: Fix clearing match mask if set action is partially unnecessary.

[Eli Britstein]

Thanks!

Acked-by: Eli Britstein 

On 7/29/2020 12:13 PM, Ilya Maximets wrote:

While committing set() actions, commit() could wildcard all the fields
that are same in match key and in the set action.  This leads to
situation where mask after commit could actually contain less bits
than it was before.  And if set action was partially committed, all
the fields that were the same will be cleared out from the matching key
resulting in the incorrect (too wide) flow.

For example, for the flow that matches on both src and dst mac
addresses, if the dst mac is the same and only src should be changed
by the set() action, destination address will be wildcarded in the
match key and will never be matched, i.e. flows with any destination
mac will match, which is not correct.

Setting OF rule:

  in_port=1,dl_src=50:54:00:00:00:09 
actions=mod_dl_dst(50:54:00:00:00:0a),output(2)

Sending following packets on port 1:

   1. eth(src=50:54:00:00:00:09,dst=50:54:00:00:00:0a),eth_type(0x0800)
   2. eth(src=50:54:00:00:00:09,dst=50:54:00:00:00:0c),eth_type(0x0800)
   3. eth(src=50:54:00:00:00:0b,dst=50:54:00:00:00:0c),eth_type(0x0800)

Resulted datapath flows:
   eth(dst=50:54:00:00:00:0c),<...>, actions:set(eth(dst=50:54:00:00:00:0a)),2
   eth(src=50:54:00:00:00:09,dst=50:54:00:00:00:0a),<...>, actions:2

The first flow  doesn't have any match on source MAC address and the
third packet successfully matched on it while it must be dropped.

Fix that by updating the match mask with only the new bits set by
commit(), but keeping those that were cleared (OR operation).

With fix applied, resulted correct flows are:
   eth(src=50:54:00:00:00:09,dst=50:54:00:00:00:0a),<...>, actions:2
   eth(src=50:54:00:00:00:09,dst=50:54:00:00:00:0c),<...>,
 actions:set(eth(dst=50:54:00:00:00:0a)),2
   eth(src=50:54:00:00:00:0b),<...>, actions:drop

The code before commit dbf4a92800d0 was not able to reduce the mask,
it was only possible to expand it to exact match, so it was OK to
update original matching mask with the new value in all cases.

Fixes: dbf4a92800d0 ("odp-util: Do not rewrite fields with the same values as 
matched")
Reported-at: 
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugzilla.redhat.com%2Fshow_bug.cgi%3Fid%3D1854376data=02%7C01%7Celibr%40mellanox.com%7C7d70b87d6084436b6ff608d8339fb47b%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C637316108313661481sdata=pa3tutGAU3%2BRuRy8y2rjb7AdBouIZrbX4iAE87YXrTY%3Dreserved=0
Signed-off-by: Ilya Maximets 
---

Version 3:
   - Implemented more accurate solution with OR-ing of the original
 and resulted masks to avoid any dependencies from the internals
 of commit() function.

Version 2:
   - Added simple unit test for this issue.
   - Added 'Tested-by' tag.
   - Refined comments.


  lib/odp-util.c| 67 ---
  lib/util.c| 13 +
  lib/util.h|  1 +
  tests/ofproto-dpif.at | 23 +++
  4 files changed, 88 insertions(+), 16 deletions(-)

diff --git a/lib/odp-util.c b/lib/odp-util.c
index 011db9ebb..e54a78b43 100644
--- a/lib/odp-util.c
+++ b/lib/odp-util.c
@@ -7701,6 +7701,28 @@ struct offsetof_sizeof {
  int size;
  };
  
+

+/* Performs bitwise OR over the fields in 'dst_' and 'src_' specified in
+ * 'offsetof_sizeof_arr' array.  Result is stored in 'dst_'. */
+static void
+or_masks(void *dst_, const void *src_,
+ struct offsetof_sizeof *offsetof_sizeof_arr)
+{
+int field, size, offset;
+const uint8_t *src = src_;
+uint8_t *dst = dst_;
+
+for (field = 0; ; field++) {
+size   = offsetof_sizeof_arr[field].size;
+offset = offsetof_sizeof_arr[field].offset;
+
+if (!size) {
+return;
+}
+or_bytes(dst + offset, src + offset, size);
+}
+}
+
  /* Compares each of the fields in 'key0' and 'key1'.  The fields are specified
   * in 'offsetof_sizeof_arr', which is an array terminated by a 0-size field.
   * Returns true if all of the fields are equal, false if at least one differs.
@@ -7779,9 +7801,10 @@ commit_set_ether_action(const struct flow *flow, struct 
flow *base_flow,
  struct flow_wildcards *wc,
  bool use_masked)
  {
-struct ovs_key_ethernet key, base, mask;
+struct ovs_key_ethernet key, base, mask, orig_mask;
  struct offsetof_sizeof ovs_key_ethernet_offsetof_sizeof_arr[] =
  OVS_KEY_ETHERNET_OFFSETOF_SIZEOF_ARR;
+
  if (flow->packet_type != htonl(PT_ETH)) {
  return;
  }
@@ -7789,11 +7812,13 @@ commit_set_ether_action(const struct flow *flow, struct 
flow *base_flow,
  get_ethernet_key(flow, );
  get_ethernet_key(base_flow, );
  get_ethernet_key(>masks, );
+memcpy(_mask, , sizeof mask);
  
  if (commit(OVS_KEY_ATTR_ETHERNET, use_masked,

 , , , sizeof key,
 ovs_key_ethernet_offsetof_sizeof_arr, odp_actions)) {
  

Re: [ovs-dev] [PATCH ovn v2] Avoid nb_cfg update notification flooding

[Lucas Alvares Gomes]

Hi Han,

>
> Just to follow up. I didn't find any new versions for this patch and it
> doesn't seem to be merged. Did you send any new versions or do you still
> plan to work on this?
>

Thanks for this follow up.

So I am not currently working on it but the work is still in our
backlog. Many of the problems that we had with the mechanism
incrementing the "nb_cfg" has been mitigated by some code in the
OpenStack side as well as this commit for core OVN [0] that disabled
flow recomputation upon updates to the Chassis' external_ids column
(we had a few updates to that column every time the nb_cfg was
bumped).

But, I can try to check if I can get some prioritization and start
working again on this patch. Is this something that you need as well ?

[0] 
https://github.com/ovn-org/ovn/commit/74d90c2223d0a8c123823fb849b4c2de58c296e4

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

Re: [ovs-dev] [PATCH v2] odp-util: Fix clearing match mask if set action is partially unnecessary.

[Ilya Maximets]

On 7/29/20 6:55 AM, Eli Britstein wrote:
> 
> On 7/28/2020 7:32 PM, Ilya Maximets wrote:
>> On 7/28/20 4:16 PM, Eli Britstein wrote:
>>> it is not "wildcarded". "wildcarded" means it had a match and it was 
>>> removed. the case here it was only not "expanded".
>>>
 It actually had a match on a filed and that match was removed from
 the original flow while committing set() action.  That is the bug that
 this patch intended to fix.  See the example below.  There was a match
 on source MAC, but it was removed by commit_set_ether_action().
>>> Right. My mistake before.
>> match key and will never be matched, i.e. flows with any destination
>>
>> I'm a bit warried about this solution since we're not clearing out all 
>> the
>> masks, so memory sanitizers might bite us on that in case where will be 
>> some
>> holes in the datastructures even though we're ORing them, but not 
>> actually
>> using these uninitialized bytes.  To not use the unconditional OR we will
>> need to introduce new functions like 'or_ethernet_mask()' and this will 
>> grow
>> the code size, which doesn't look very pretty.
>>
>> What do you think?
>>> That was my thought too when I did that work. For that, I introduced the 
>>> generic 'struct offsetof_sizeof' array, and wildcarding the mask code is 
>>> mutual for all attributes (ETH, IPv4,...). Maybe (I haven't thought it 
>>> through) we can leverage the generic "commit" function that already gets 
>>> that array to do the "ORs". This way we will do only for the fields and not 
>>> tough the "holes".
>> Yes, that a good point.  What about incremental change like this
>> (incremental to the previous diff I sent):
>>
>> ---
>> diff --git a/lib/odp-util.c b/lib/odp-util.c
>> index 364a6fbe1..e54a78b43 100644
>> --- a/lib/odp-util.c
>> +++ b/lib/odp-util.c
>> @@ -7701,6 +7701,28 @@ struct offsetof_sizeof {
>>   int size;
>>   };
>>   +
>> +/* Performs bitwise OR over the fields in 'dst_' and 'src_' specified in
>> + * 'offsetof_sizeof_arr' array.  Result is stored in 'dst_'. */
>> +static void
>> +or_masks(void *dst_, const void *src_,
>> + struct offsetof_sizeof *offsetof_sizeof_arr)
>> +{
>> +    int field, size, offset;
>> +    const uint8_t *src = src_;
>> +    uint8_t *dst = dst_;
>> +
>> +    for (field = 0; ; field++) {
>> +    size   = offsetof_sizeof_arr[field].size;
>> +    offset = offsetof_sizeof_arr[field].offset;
>> +
>> +    if (!size) {
>> +    return;
>> +    }
>> +    or_bytes(dst + offset, src + offset, size);
>> +    }
>> +}
>> +
>>   /* Compares each of the fields in 'key0' and 'key1'.  The fields are 
>> specified
>>    * in 'offsetof_sizeof_arr', which is an array terminated by a 0-size 
>> field.
>>    * Returns true if all of the fields are equal, false if at least one 
>> differs.
>> @@ -7796,7 +7818,7 @@ commit_set_ether_action(const struct flow *flow, 
>> struct flow *base_flow,
>>  , , , sizeof key,
>>  ovs_key_ethernet_offsetof_sizeof_arr, odp_actions)) {
>>   put_ethernet_key(, base_flow);
>> -    or_bytes(, _mask, sizeof mask);
>> +    or_masks(, _mask, ovs_key_ethernet_offsetof_sizeof_arr);
>>   put_ethernet_key(, >masks);
>>   }
>>   }
>> ---
>>
>> And the same for all other callers of or_bytes().
>>
>> What do you think?
> Seems OK. Can you please post v3?

Sure.  Sent.

>>
>> Best regards, Ilya Maximets.

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

Re: [ovs-dev] [ovs-discuss] OVN: configuration in Neutron DB?

[Lucas Alvares Gomes]

Hi,

On Wed, Jul 29, 2020 at 7:42 AM Numan Siddique  wrote:
>
> Adding Daniel and Lucas. Maybe you can also include opendev ML to get
> appropriate responses from the OpenStack side.
>
> Please see below for few comments.
>
>
> On Wed, Jul 29, 2020 at 12:02 PM Tony Liu  wrote:
>
> > Quick update. I changed the script to create 256 routers first, then set
> > each of them as gateway.
> > There is no create and set back to back. It seems working fine now.
> >
> > It would be good someone can clarify my questions. It seems that it's
> > not guaranteed that the
> > object is ready when client get OK response of creation request. Is this
> > expected?
> >
> >
> > Thanks!
> >
> > Tony
> >
> > --
> > *From:* dev  on behalf of Tony Liu <
> > tonyliu0...@hotmail.com>
> > *Sent:* July 28, 2020 10:37 PM
> > *To:* ovs-disc...@openvswitch.org ;
> > ovs-dev@openvswitch.org 
> > *Subject:* [ovs-dev] OVN: configuration in Neutron DB?
> >
> > Hi,
> >
> > In case of integration with OpenStack, for example, when a client requests
> > to create a network,
> > is this network configuration saved in both Neutron DB and OVN DB, or OVN
> > DB only?
> >
>
> The neutron API first saves in the neutron db and the neutron OVN mechanism
> driver will talk
> to the Northbound ovsdb-server and create corresponding OVN logical
> resources.
>

Both as numans said, it's first created in the Neutron database and
then the OVN plugin is invoked to create that resource in the OVN NB
database. We usually use the "name" column in the OVN NB DB to store
the correspondent Neutron UUID, if the resource has no "name" column
we then use the external_ids columns to do it.

In your example, a Neutron network corresponds to a Logical_Switch in OVN:

stack@lucas-devstack-2:~/neutron$ openstack network create test
| id| 702c4ccd-2f9e-43c8-99a8-4b07a509e105 |
...

stack@lucas-devstack-2:~/neutron$ ovn-nbctl list logical_switch
external_ids: {"neutron:mtu"="1442",
"neutron:network_name"=test, "neutron:revision_number"="1"}
name: neutron-702c4ccd-2f9e-43c8-99a8-4b07a509e105\
...

So the correspondent Logical Switch in OVN is named as "neutron-"

>
> > Also, when a client gets a network from Neutron API, is the configuration
> > read from Neutron DB
> > or OVN DB?
> >
>
> I think its read from the neutron DB.
>

That's right, it reads from the Neutron database.

>
>
> >
> > Other than coding, is there any doc about how Neutron OVN ML2 driver works?
> >
>
> You can refer here -
> https://docs.openstack.org/neutron/latest/admin/ovn/refarch/refarch.html
>

Yeah that's the part of the documentation we have that matches with
your questions, let us know if you have more questions and perhaps we
can enhance that document with the answers.


>
> >
> > I have this script to create 256 routers and set each of them as gateway.
> > router()
> > {
> > local op=$1
> >
> > for c in `seq 0 1 255`; do
> > echo "INFO: $op router-$c..."
> > openstack router $op router-$c
> > if [ "$op" == "create" ]; then
> > openstack router set \
> > --external-gateway public \
> > --fixed-ip ip-address=10.6.33.$c \
> > --disable-snat \
> > router-$c
> > fi
> > done
> > }
> > I see lots failures from Neutron log when get/show a router. It seems like
> > that, when setting a router,
> > the router is not completely ready yet. Is it possible?
> >
> > After running that script, I see some logical routers in ovn-nb-db don't
> > have gw_port_id. And there
> > are some duplications. Here is an example. Each of them has unique UUID.
> >
> > external_ids: {"neutron:gw_port_id"="",
> > "neutron:revision_number"="1", "neutron:router_name"=router-255}
> > external_ids: {"neutron:gw_port_id"="",
> > "neutron:revision_number"="1", "neutron:router_name"=router-232}
> > external_ids: {"neutron:gw_port_id"="",
> > "neutron:revision_number"="0", "neutron:router_name"=router-158}
> > external_ids: {"neutron:gw_port_id"="",
> > "neutron:revision_number"="0", "neutron:router_name"=router-158}
> > external_ids:
> > {"neutron:gw_port_id"="e52dda53-c914-4ea7-840b-8632a5770680",
> > "neutron:revision_number"="2", "neutron:router_name"=router-158}
> >
> > I enabled nb-db debug logging and searched, eg. router-158, it only shows
> > in a jsonrpc reply message
> > including 3 router-158, as the above.
> >
> > Any clues?
> >
> >
> Maybe Daniel/Lucas can comment.
>
> Thanks
> Numan
>
>
> >
> > Thanks!
> >
> > Tony
> >
> >
> >
> > ___
> > dev mailing list
> > d...@openvswitch.org
> > https://mail.openvswitch.org/mailman/listinfo/ovs-dev
> > ___
> > discuss mailing list
> > disc...@openvswitch.org
> > https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
> >
> 

[ovs-dev] [PATCH v3] odp-util: Fix clearing match mask if set action is partially unnecessary.

[Ilya Maximets]

While committing set() actions, commit() could wildcard all the fields
that are same in match key and in the set action.  This leads to
situation where mask after commit could actually contain less bits
than it was before.  And if set action was partially committed, all
the fields that were the same will be cleared out from the matching key
resulting in the incorrect (too wide) flow.

For example, for the flow that matches on both src and dst mac
addresses, if the dst mac is the same and only src should be changed
by the set() action, destination address will be wildcarded in the
match key and will never be matched, i.e. flows with any destination
mac will match, which is not correct.

Setting OF rule:

 in_port=1,dl_src=50:54:00:00:00:09 
actions=mod_dl_dst(50:54:00:00:00:0a),output(2)

Sending following packets on port 1:

  1. eth(src=50:54:00:00:00:09,dst=50:54:00:00:00:0a),eth_type(0x0800)
  2. eth(src=50:54:00:00:00:09,dst=50:54:00:00:00:0c),eth_type(0x0800)
  3. eth(src=50:54:00:00:00:0b,dst=50:54:00:00:00:0c),eth_type(0x0800)

Resulted datapath flows:
  eth(dst=50:54:00:00:00:0c),<...>, actions:set(eth(dst=50:54:00:00:00:0a)),2
  eth(src=50:54:00:00:00:09,dst=50:54:00:00:00:0a),<...>, actions:2

The first flow  doesn't have any match on source MAC address and the
third packet successfully matched on it while it must be dropped.

Fix that by updating the match mask with only the new bits set by
commit(), but keeping those that were cleared (OR operation).

With fix applied, resulted correct flows are:
  eth(src=50:54:00:00:00:09,dst=50:54:00:00:00:0a),<...>, actions:2
  eth(src=50:54:00:00:00:09,dst=50:54:00:00:00:0c),<...>,
actions:set(eth(dst=50:54:00:00:00:0a)),2
  eth(src=50:54:00:00:00:0b),<...>, actions:drop

The code before commit dbf4a92800d0 was not able to reduce the mask,
it was only possible to expand it to exact match, so it was OK to
update original matching mask with the new value in all cases.

Fixes: dbf4a92800d0 ("odp-util: Do not rewrite fields with the same values as 
matched")
Reported-at: https://bugzilla.redhat.com/show_bug.cgi?id=1854376
Signed-off-by: Ilya Maximets 
---

Version 3:
  - Implemented more accurate solution with OR-ing of the original
and resulted masks to avoid any dependencies from the internals
of commit() function.

Version 2:
  - Added simple unit test for this issue.
  - Added 'Tested-by' tag.
  - Refined comments.


 lib/odp-util.c| 67 ---
 lib/util.c| 13 +
 lib/util.h|  1 +
 tests/ofproto-dpif.at | 23 +++
 4 files changed, 88 insertions(+), 16 deletions(-)

diff --git a/lib/odp-util.c b/lib/odp-util.c
index 011db9ebb..e54a78b43 100644
--- a/lib/odp-util.c
+++ b/lib/odp-util.c
@@ -7701,6 +7701,28 @@ struct offsetof_sizeof {
 int size;
 };
 
+
+/* Performs bitwise OR over the fields in 'dst_' and 'src_' specified in
+ * 'offsetof_sizeof_arr' array.  Result is stored in 'dst_'. */
+static void
+or_masks(void *dst_, const void *src_,
+ struct offsetof_sizeof *offsetof_sizeof_arr)
+{
+int field, size, offset;
+const uint8_t *src = src_;
+uint8_t *dst = dst_;
+
+for (field = 0; ; field++) {
+size   = offsetof_sizeof_arr[field].size;
+offset = offsetof_sizeof_arr[field].offset;
+
+if (!size) {
+return;
+}
+or_bytes(dst + offset, src + offset, size);
+}
+}
+
 /* Compares each of the fields in 'key0' and 'key1'.  The fields are specified
  * in 'offsetof_sizeof_arr', which is an array terminated by a 0-size field.
  * Returns true if all of the fields are equal, false if at least one differs.
@@ -7779,9 +7801,10 @@ commit_set_ether_action(const struct flow *flow, struct 
flow *base_flow,
 struct flow_wildcards *wc,
 bool use_masked)
 {
-struct ovs_key_ethernet key, base, mask;
+struct ovs_key_ethernet key, base, mask, orig_mask;
 struct offsetof_sizeof ovs_key_ethernet_offsetof_sizeof_arr[] =
 OVS_KEY_ETHERNET_OFFSETOF_SIZEOF_ARR;
+
 if (flow->packet_type != htonl(PT_ETH)) {
 return;
 }
@@ -7789,11 +7812,13 @@ commit_set_ether_action(const struct flow *flow, struct 
flow *base_flow,
 get_ethernet_key(flow, );
 get_ethernet_key(base_flow, );
 get_ethernet_key(>masks, );
+memcpy(_mask, , sizeof mask);
 
 if (commit(OVS_KEY_ATTR_ETHERNET, use_masked,
, , , sizeof key,
ovs_key_ethernet_offsetof_sizeof_arr, odp_actions)) {
 put_ethernet_key(, base_flow);
+or_masks(, _mask, ovs_key_ethernet_offsetof_sizeof_arr);
 put_ethernet_key(, >masks);
 }
 }
@@ -7917,7 +7942,7 @@ commit_set_ipv4_action(const struct flow *flow, struct 
flow *base_flow,
struct ofpbuf *odp_actions, struct flow_wildcards *wc,
bool use_masked)
 {
-struct ovs_key_ipv4 key, 

Re: [ovs-dev] [ovs-discuss] OVN: configuration in Neutron DB?

[Tony Liu]

Thanks Numan!

Tony

From: Numan Siddique 
Sent: July 28, 2020 11:41 PM
To: Tony Liu 
Cc: ovs-disc...@openvswitch.org ; 
ovs-dev@openvswitch.org ; Daniel Alvarez Sanchez 
; Lucas Alvares Gomes Martins 
Subject: Re: [ovs-discuss] OVN: configuration in Neutron DB?


Adding Daniel and Lucas. Maybe you can also include opendev ML to get 
appropriate responses from the OpenStack side.

Please see below for few comments.


On Wed, Jul 29, 2020 at 12:02 PM Tony Liu 
mailto:tonyliu0...@hotmail.com>> wrote:
Quick update. I changed the script to create 256 routers first, then set each 
of them as gateway.
There is no create and set back to back. It seems working fine now.

It would be good someone can clarify my questions. It seems that it's not 
guaranteed that the
object is ready when client get OK response of creation request. Is this 
expected?


Thanks!

Tony


From: dev 
mailto:ovs-dev-boun...@openvswitch.org>> on 
behalf of Tony Liu mailto:tonyliu0...@hotmail.com>>
Sent: July 28, 2020 10:37 PM
To: ovs-disc...@openvswitch.org 
mailto:ovs-disc...@openvswitch.org>>; 
ovs-dev@openvswitch.org 
mailto:ovs-dev@openvswitch.org>>
Subject: [ovs-dev] OVN: configuration in Neutron DB?

Hi,

In case of integration with OpenStack, for example, when a client requests to 
create a network,
is this network configuration saved in both Neutron DB and OVN DB, or OVN DB 
only?

The neutron API first saves in the neutron db and the neutron OVN mechanism 
driver will talk
to the Northbound ovsdb-server and create corresponding OVN logical resources.

Also, when a client gets a network from Neutron API, is the configuration read 
from Neutron DB
or OVN DB?

I think its read from the neutron DB.



Other than coding, is there any doc about how Neutron OVN ML2 driver works?

You can refer here - 
https://docs.openstack.org/neutron/latest/admin/ovn/refarch/refarch.html



I have this script to create 256 routers and set each of them as gateway.
router()
{
local op=$1

for c in `seq 0 1 255`; do
echo "INFO: $op router-$c..."
openstack router $op router-$c
if [ "$op" == "create" ]; then
openstack router set \
--external-gateway public \
--fixed-ip ip-address=10.6.33.$c \
--disable-snat \
router-$c
fi
done
}
I see lots failures from Neutron log when get/show a router. It seems like 
that, when setting a router,
the router is not completely ready yet. Is it possible?

After running that script, I see some logical routers in ovn-nb-db don't have 
gw_port_id. And there
are some duplications. Here is an example. Each of them has unique UUID.

external_ids: {"neutron:gw_port_id"="", "neutron:revision_number"="1", 
"neutron:router_name"=router-255}
external_ids: {"neutron:gw_port_id"="", "neutron:revision_number"="1", 
"neutron:router_name"=router-232}
external_ids: {"neutron:gw_port_id"="", "neutron:revision_number"="0", 
"neutron:router_name"=router-158}
external_ids: {"neutron:gw_port_id"="", "neutron:revision_number"="0", 
"neutron:router_name"=router-158}
external_ids: 
{"neutron:gw_port_id"="e52dda53-c914-4ea7-840b-8632a5770680", 
"neutron:revision_number"="2", "neutron:router_name"=router-158}

I enabled nb-db debug logging and searched, eg. router-158, it only shows in a 
jsonrpc reply message
including 3 router-158, as the above.

Any clues?


Maybe Daniel/Lucas can comment.

Thanks
Numan


Thanks!

Tony



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

Re: [ovs-dev] [ovs-discuss] OVN: configuration in Neutron DB?

[Numan Siddique]

Adding Daniel and Lucas. Maybe you can also include opendev ML to get
appropriate responses from the OpenStack side.

Please see below for few comments.


On Wed, Jul 29, 2020 at 12:02 PM Tony Liu  wrote:

> Quick update. I changed the script to create 256 routers first, then set
> each of them as gateway.
> There is no create and set back to back. It seems working fine now.
>
> It would be good someone can clarify my questions. It seems that it's
> not guaranteed that the
> object is ready when client get OK response of creation request. Is this
> expected?
>
>
> Thanks!
>
> Tony
>
> --
> *From:* dev  on behalf of Tony Liu <
> tonyliu0...@hotmail.com>
> *Sent:* July 28, 2020 10:37 PM
> *To:* ovs-disc...@openvswitch.org ;
> ovs-dev@openvswitch.org 
> *Subject:* [ovs-dev] OVN: configuration in Neutron DB?
>
> Hi,
>
> In case of integration with OpenStack, for example, when a client requests
> to create a network,
> is this network configuration saved in both Neutron DB and OVN DB, or OVN
> DB only?
>

The neutron API first saves in the neutron db and the neutron OVN mechanism
driver will talk
to the Northbound ovsdb-server and create corresponding OVN logical
resources.


> Also, when a client gets a network from Neutron API, is the configuration
> read from Neutron DB
> or OVN DB?
>

I think its read from the neutron DB.



>
> Other than coding, is there any doc about how Neutron OVN ML2 driver works?
>

You can refer here -
https://docs.openstack.org/neutron/latest/admin/ovn/refarch/refarch.html



>
> I have this script to create 256 routers and set each of them as gateway.
> router()
> {
> local op=$1
>
> for c in `seq 0 1 255`; do
> echo "INFO: $op router-$c..."
> openstack router $op router-$c
> if [ "$op" == "create" ]; then
> openstack router set \
> --external-gateway public \
> --fixed-ip ip-address=10.6.33.$c \
> --disable-snat \
> router-$c
> fi
> done
> }
> I see lots failures from Neutron log when get/show a router. It seems like
> that, when setting a router,
> the router is not completely ready yet. Is it possible?
>
> After running that script, I see some logical routers in ovn-nb-db don't
> have gw_port_id. And there
> are some duplications. Here is an example. Each of them has unique UUID.
>
> external_ids: {"neutron:gw_port_id"="",
> "neutron:revision_number"="1", "neutron:router_name"=router-255}
> external_ids: {"neutron:gw_port_id"="",
> "neutron:revision_number"="1", "neutron:router_name"=router-232}
> external_ids: {"neutron:gw_port_id"="",
> "neutron:revision_number"="0", "neutron:router_name"=router-158}
> external_ids: {"neutron:gw_port_id"="",
> "neutron:revision_number"="0", "neutron:router_name"=router-158}
> external_ids:
> {"neutron:gw_port_id"="e52dda53-c914-4ea7-840b-8632a5770680",
> "neutron:revision_number"="2", "neutron:router_name"=router-158}
>
> I enabled nb-db debug logging and searched, eg. router-158, it only shows
> in a jsonrpc reply message
> including 3 router-158, as the above.
>
> Any clues?
>
>
Maybe Daniel/Lucas can comment.

Thanks
Numan


>
> Thanks!
>
> Tony
>
>
>
> ___
> dev mailing list
> d...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-dev
> ___
> discuss mailing list
> disc...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
>
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] OVN: configuration in Neutron DB?

[Tony Liu]

Quick update. I changed the script to create 256 routers first, then set each 
of them as gateway.
There is no create and set back to back. It seems working fine now.

It would be good someone can clarify my questions. It seems that it's not 
guaranteed that the
object is ready when client get OK response of creation request. Is this 
expected?


Thanks!

Tony


From: dev  on behalf of Tony Liu 

Sent: July 28, 2020 10:37 PM
To: ovs-disc...@openvswitch.org ; 
ovs-dev@openvswitch.org 
Subject: [ovs-dev] OVN: configuration in Neutron DB?

Hi,

In case of integration with OpenStack, for example, when a client requests to 
create a network,
is this network configuration saved in both Neutron DB and OVN DB, or OVN DB 
only?
Also, when a client gets a network from Neutron API, is the configuration read 
from Neutron DB
or OVN DB?

Other than coding, is there any doc about how Neutron OVN ML2 driver works?

I have this script to create 256 routers and set each of them as gateway.
router()
{
local op=$1

for c in `seq 0 1 255`; do
echo "INFO: $op router-$c..."
openstack router $op router-$c
if [ "$op" == "create" ]; then
openstack router set \
--external-gateway public \
--fixed-ip ip-address=10.6.33.$c \
--disable-snat \
router-$c
fi
done
}
I see lots failures from Neutron log when get/show a router. It seems like 
that, when setting a router,
the router is not completely ready yet. Is it possible?

After running that script, I see some logical routers in ovn-nb-db don't have 
gw_port_id. And there
are some duplications. Here is an example. Each of them has unique UUID.

external_ids: {"neutron:gw_port_id"="", "neutron:revision_number"="1", 
"neutron:router_name"=router-255}
external_ids: {"neutron:gw_port_id"="", "neutron:revision_number"="1", 
"neutron:router_name"=router-232}
external_ids: {"neutron:gw_port_id"="", "neutron:revision_number"="0", 
"neutron:router_name"=router-158}
external_ids: {"neutron:gw_port_id"="", "neutron:revision_number"="0", 
"neutron:router_name"=router-158}
external_ids: 
{"neutron:gw_port_id"="e52dda53-c914-4ea7-840b-8632a5770680", 
"neutron:revision_number"="2", "neutron:router_name"=router-158}

I enabled nb-db debug logging and searched, eg. router-158, it only shows in a 
jsonrpc reply message
including 3 router-158, as the above.

Any clues?


Thanks!

Tony



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

[ovs-dev] OVN: configuration in Neutron DB?

[Tony Liu]

Hi,

In case of integration with OpenStack, for example, when a client requests to 
create a network,
is this network configuration saved in both Neutron DB and OVN DB, or OVN DB 
only?
Also, when a client gets a network from Neutron API, is the configuration read 
from Neutron DB
or OVN DB?

Other than coding, is there any doc about how Neutron OVN ML2 driver works?

I have this script to create 256 routers and set each of them as gateway.
router()
{
local op=$1

for c in `seq 0 1 255`; do
echo "INFO: $op router-$c..."
openstack router $op router-$c
if [ "$op" == "create" ]; then
openstack router set \
--external-gateway public \
--fixed-ip ip-address=10.6.33.$c \
--disable-snat \
router-$c
fi
done
}
I see lots failures from Neutron log when get/show a router. It seems like 
that, when setting a router,
the router is not completely ready yet. Is it possible?

After running that script, I see some logical routers in ovn-nb-db don't have 
gw_port_id. And there
are some duplications. Here is an example. Each of them has unique UUID.

external_ids: {"neutron:gw_port_id"="", "neutron:revision_number"="1", 
"neutron:router_name"=router-255}
external_ids: {"neutron:gw_port_id"="", "neutron:revision_number"="1", 
"neutron:router_name"=router-232}
external_ids: {"neutron:gw_port_id"="", "neutron:revision_number"="0", 
"neutron:router_name"=router-158}
external_ids: {"neutron:gw_port_id"="", "neutron:revision_number"="0", 
"neutron:router_name"=router-158}
external_ids: 
{"neutron:gw_port_id"="e52dda53-c914-4ea7-840b-8632a5770680", 
"neutron:revision_number"="2", "neutron:router_name"=router-158}

I enabled nb-db debug logging and searched, eg. router-158, it only shows in a 
jsonrpc reply message
including 3 router-158, as the above.

Any clues?


Thanks!

Tony



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