Re: [ovs-dev] [PATCH ovn v1] Add support for centralize routing for distributed gw ports.

[Roberto Bartzen Acosta via dev]

Em qui., 25 de jul. de 2024 às 11:12, Numan Siddique 
escreveu:

> On Tue, Jul 9, 2024 at 7:25 PM  wrote:
> >
> > From: Numan Siddique 
> >
> > Consider a deployment with the below logical resources:
> >
> > 1. A bridged logical switch 'public' with a port - P1 and a localnet
> >port ln-public.
> > 2. A logical router 'R'
> > 3. Logical switch 'public' connected to R via logical switch/router port
> >peers (public-R and R-public).
> > 4. R-public is distributed gateway port with its network as
> 172.16.0.0/24
> > 5. NATs (dnat_and_snat) configured in 'R'.
> > 6. And a few overlay logical switches S1, S2 to R.
> >
> > Any traffic from logical port - P1 of public logical switch destined to
> > S1 or S2's logical ports goes out of the source chassis
> > (where P1 resides) via the localnet port and reaches the gateway chassis
> > which handles the routing.
> >
> > There are couple of traffic flow scenarios which doesn't work if the
> > logical switch 'public' doesn't have a localnet port.
> >
> > 1. Traffic from port - P1 destined to logical switches S1 or S2 gets
> >dropped in the source chassis.  The packet enters the router R's
> >pipeline, but it gets dropped in the 'lr_in_admission' stage since
> >the logical flow to allow traffic destined to the distributed gateway
> >port MAC is installed only on the gateway chassis.
> >
> > 2. NAT doesn't work as expected.
> >
> > In order to suppose this use case (of a logical switch not having a
> > localnet port, but has a distributed gateway port and NATs), this patch
> > supports the option 'centralize_routing', which can be configured on
> > the distributed gateway port (R-public in the example above).
> > If this option is set, then routing is centralized on the gateway
> > chassis for the traffic destined to the R-public's networks
> > (172.16.0.0/24 for the above example).  Traffic from P1 will be
> > tunnelled to the gateway chassis.
> >
> > ovn-northd creates a chassisresident port (cr-public-R) for the
> > logical switch port - public-R, along with cr-R-public inorder to
> > centralize the traffic.
> >
> > This feature gets enabled for the distributed gateway port R-public if
> >   - The above option is set to true in the R-public's options column.
> >   - The logical switch 'public' doesn't have any localnet ports.
> >   - And R-public is the only distributed gateway port of R.
> >
> > Distributed NAT (i.e if external_mac and router_port is set) is
> > not supported and instead the router port mac is used for such traffic
> > and centralized on the gateway chassis.
> >
> > Reported-at: https://issues.redhat.com/browse/FDP-364
> > Signed-off-by: Numan Siddique 
> > ---
> >  NEWS  |   2 +
> >  controller/physical.c |   4 +
> >  northd/northd.c   | 257 +++
> >  northd/northd.h   |   1 +
> >  ovn-nb.xml|  34 +++
> >  tests/multinode-macros.at |   2 +-
> >  tests/multinode.at| 177 +
> >  tests/ovn-northd.at   | 516 +-
> >  tests/ovn.at  |   8 +-
> >  9 files changed, 951 insertions(+), 50 deletions(-)
> >
> > diff --git a/NEWS b/NEWS
> > index 3e392ff08b..472445a188 100644
> > --- a/NEWS
> > +++ b/NEWS
> > @@ -38,6 +38,8 @@ Post v24.03.0
> >  ability to disable "VXLAN mode" to extend available tunnel IDs
> space for
> >  datapaths from 4095 to 16711680.  For more details see man
> ovn-nb(5) for
> >  mentioned option.
> > +  - Added Overlay provider network support to a logical switch if
> > +the config "overlay_provider_network" is set to true.
>
> Please ignore this modification to NEWS.  It's wrong.  I'll fix it in
> the next version.
>
> Numan
>
> >
> >  OVN v24.03.0 - 01 Mar 2024
> >  --
> > diff --git a/controller/physical.c b/controller/physical.c
> > index 22756810fd..e3a316989a 100644
> > --- a/controller/physical.c
> > +++ b/controller/physical.c
> > @@ -1608,6 +1608,10 @@ consider_port_binding(struct ovsdb_idl_index
> *sbrec_port_binding_by_name,
> >  ct_zones);
> >  put_zones_ofpacts(_ids, ofpacts_p);
> >
> > +/* Clear the MFF_INPORT.  Its possible that the same packet
> may
> > + * go out from the same tunnel inport. */
> > +put_load(ofp_to_u16(OFPP_NONE), MFF_IN_PORT, 0, 16,
> ofpacts_p);
> > +
> >  /* Resubmit to table 41. */
> >  put_resubmit(OFTABLE_CHECK_LOOPBACK, ofpacts_p);
> >  }
> > diff --git a/northd/northd.c b/northd/northd.c
> > index 6898daa00d..9b52d5a3c0 100644
> > --- a/northd/northd.c
> > +++ b/northd/northd.c
> > @@ -2099,6 +2099,55 @@ parse_lsp_addrs(struct ovn_port *op)
> >  }
> >  }
> >
> > +static struct ovn_port *
> > +create_cr_port(struct ovn_port *op, struct hmap *ports,
> > +   struct ovs_list *both_dbs, struct ovs_list *nb_only)
> > +{
> > +char *redirect_name = 

[ovs-dev] [PATCH ovn v4] northd: Fix logical router load-balancer nat rules when using DGP.

[Roberto Bartzen Acosta via dev]

This commit fixes the build_distr_lrouter_nat_flows_for_lb function to
include one NAT stateless flow entry for each DGP in use. Since we have
added support to create multiple gateway ports per logical router, it's
necessary to include in the LR nat rules pipeline a specific entry for each
attached DGP. Otherwise, the ingress traffic is only redirected when the
incoming LRP matches the chassis_resident field.

Considering that DNAT rules for DGPs were implemented with the need to
configure the DGP-related gateway-port column, the load-balancer NAT rule
configuration can use a similar idea. In this case, we don't know the LRP
responsible for the incoming traffic, and therefore we need to automatically
apply a stateless NAT rule to the load-balancer on all DGPs to allow inbound
traffic.

After applying this patch, the incoming and/or outgoing traffic can pass
through any chassis where the DGP resides without having problems with CT
state.

Reported-at: https://bugs.launchpad.net/ubuntu/+source/ovn/+bug/2054322
Fixes: 15348b7b806f ("ovn-northd: Multiple distributed gateway port support.")
Signed-off-by: Roberto Bartzen Acosta 
---
 northd/en-lr-stateful.c |  12 ---
 northd/northd.c |  96 -
 tests/ovn-northd.at | 222 
 3 files changed, 293 insertions(+), 37 deletions(-)

diff --git a/northd/en-lr-stateful.c b/northd/en-lr-stateful.c
index baf1bd2f8..f09691af6 100644
--- a/northd/en-lr-stateful.c
+++ b/northd/en-lr-stateful.c
@@ -516,18 +516,6 @@ lr_stateful_record_create(struct lr_stateful_table *table,
 
 table->array[od->index] = lr_stateful_rec;
 
-/* Load balancers are not supported (yet) if a logical router has multiple
- * distributed gateway port.  Log a warning. */
-if (lr_stateful_rec->has_lb_vip && lr_has_multiple_gw_ports(od)) {
-static struct vlog_rate_limit rl = VLOG_RATE_LIMIT_INIT(1, 1);
-VLOG_WARN_RL(, "Load-balancers are configured on logical "
- "router %s, which has %"PRIuSIZE" distributed "
- "gateway ports. Load-balancer is not supported "
- "yet when there is more than one distributed "
- "gateway port on the router.",
- od->nbr->name, od->n_l3dgw_ports);
-}
-
 return lr_stateful_rec;
 }
 
diff --git a/northd/northd.c b/northd/northd.c
index 6898daa00..853d58f29 100644
--- a/northd/northd.c
+++ b/northd/northd.c
@@ -11026,31 +11026,30 @@ static void
 build_distr_lrouter_nat_flows_for_lb(struct lrouter_nat_lb_flows_ctx *ctx,
  enum lrouter_nat_lb_flow_type type,
  struct ovn_datapath *od,
- struct lflow_ref *lflow_ref)
+ struct lflow_ref *lflow_ref,
+ struct ovn_port *dgp)
 {
-struct ovn_port *dgp = od->l3dgw_ports[0];
-
-const char *undnat_action;
-
-switch (type) {
-case LROUTER_NAT_LB_FLOW_FORCE_SNAT:
-undnat_action = "flags.force_snat_for_lb = 1; next;";
-break;
-case LROUTER_NAT_LB_FLOW_SKIP_SNAT:
-undnat_action = "flags.skip_snat_for_lb = 1; next;";
-break;
-case LROUTER_NAT_LB_FLOW_NORMAL:
-case LROUTER_NAT_LB_FLOW_MAX:
-undnat_action = lrouter_use_common_zone(od)
-? "ct_dnat_in_czone;"
-: "ct_dnat;";
-break;
-}
+struct ds dnat_action = DS_EMPTY_INITIALIZER;
 
 /* Store the match lengths, so we can reuse the ds buffer. */
 size_t new_match_len = ctx->new_match->length;
 size_t undnat_match_len = ctx->undnat_match->length;
 
+/* Create stateless LB NAT rules when using DGPs.
+ * dnat_action: Add the LB backend IPs as a destination action of the
+ *  lr_in_dnat NAT rule with cumulative effect because any
+ *  backend dst IP used in the action list will redirect the
+ *  packet to the ct_lb pipeline.
+ */
+if (od->n_l3dgw_ports > 1) {
+for (size_t i = 0; i < ctx->lb_vip->n_backends; i++) {
+struct ovn_lb_backend *backend = >lb_vip->backends[i];
+bool ipv6 = !IN6_IS_ADDR_V4MAPPED(>ip);
+ds_put_format(_action, "%s.dst=%s;", ipv6 ? "ip6" : "ip4",
+  backend->ip_str);
+}
+}
+ds_put_format(_action, "%s", ctx->new_action[type]);
 
 const char *meter = NULL;
 
@@ -11060,20 +11059,47 @@ build_distr_lrouter_nat_flows_for_lb(struct 
lrouter_nat_lb_flows_ctx *ctx,
 
 if (ctx->lb_vip->n_backends || !ctx->lb_vip->empty_backend_rej) {
 ds_put_format(ctx->new_match, " && is_chassis_resident(%s)",
-  od->l3dgw_ports[0]->cr_port->json_key);
+  dgp->cr_port->json_key);
 }
 
 ovn_lflow_add_with_hint__(ctx->lflows, od, S_ROUTER_IN_DNAT, ctx->prio,
-   

[ovs-dev] [PATCH ovn v3] northd: Fix logical router load-balancer nat rules when using DGP.

[Roberto Bartzen Acosta via dev]

This commit fixes the build_distr_lrouter_nat_flows_for_lb function to
include one NAT stateless flow entry for each DGP in use. Since we have
added support to create multiple gateway ports per logical router, it's
necessary to include in the LR nat rules pipeline a specific entry for each
attached DGP. Otherwise, the ingress traffic is only redirected when the
incoming LRP matches the chassis_resident field.

Considering that DNAT rules for DGPs were implemented with the need to
configure the DGP-related gateway-port column, the load-balancer NAT rule
configuration can use a similar idea. In this case, we don't know the LRP
responsible for the incoming traffic, and therefore we need to automatically
apply a stateless NAT rule to the load-balancer on all DGPs to allow inbound
traffic.

After applying this patch, the incoming and/or outgoing traffic can pass
through any chassis where the DGP resides without having problems with CT
state.

Reported-at: https://bugs.launchpad.net/ubuntu/+source/ovn/+bug/2054322
Fixes: 15348b7b806f ("ovn-northd: Multiple distributed gateway port support.")
Signed-off-by: Roberto Bartzen Acosta 
---
 northd/en-lr-stateful.c |  12 -
 northd/northd.c |  96 +-
 tests/ovn-northd.at | 111 
 3 files changed, 182 insertions(+), 37 deletions(-)

diff --git a/northd/en-lr-stateful.c b/northd/en-lr-stateful.c
index baf1bd2f8..f09691af6 100644
--- a/northd/en-lr-stateful.c
+++ b/northd/en-lr-stateful.c
@@ -516,18 +516,6 @@ lr_stateful_record_create(struct lr_stateful_table *table,
 
 table->array[od->index] = lr_stateful_rec;
 
-/* Load balancers are not supported (yet) if a logical router has multiple
- * distributed gateway port.  Log a warning. */
-if (lr_stateful_rec->has_lb_vip && lr_has_multiple_gw_ports(od)) {
-static struct vlog_rate_limit rl = VLOG_RATE_LIMIT_INIT(1, 1);
-VLOG_WARN_RL(, "Load-balancers are configured on logical "
- "router %s, which has %"PRIuSIZE" distributed "
- "gateway ports. Load-balancer is not supported "
- "yet when there is more than one distributed "
- "gateway port on the router.",
- od->nbr->name, od->n_l3dgw_ports);
-}
-
 return lr_stateful_rec;
 }
 
diff --git a/northd/northd.c b/northd/northd.c
index 6898daa00..853d58f29 100644
--- a/northd/northd.c
+++ b/northd/northd.c
@@ -11026,31 +11026,30 @@ static void
 build_distr_lrouter_nat_flows_for_lb(struct lrouter_nat_lb_flows_ctx *ctx,
  enum lrouter_nat_lb_flow_type type,
  struct ovn_datapath *od,
- struct lflow_ref *lflow_ref)
+ struct lflow_ref *lflow_ref,
+ struct ovn_port *dgp)
 {
-struct ovn_port *dgp = od->l3dgw_ports[0];
-
-const char *undnat_action;
-
-switch (type) {
-case LROUTER_NAT_LB_FLOW_FORCE_SNAT:
-undnat_action = "flags.force_snat_for_lb = 1; next;";
-break;
-case LROUTER_NAT_LB_FLOW_SKIP_SNAT:
-undnat_action = "flags.skip_snat_for_lb = 1; next;";
-break;
-case LROUTER_NAT_LB_FLOW_NORMAL:
-case LROUTER_NAT_LB_FLOW_MAX:
-undnat_action = lrouter_use_common_zone(od)
-? "ct_dnat_in_czone;"
-: "ct_dnat;";
-break;
-}
+struct ds dnat_action = DS_EMPTY_INITIALIZER;
 
 /* Store the match lengths, so we can reuse the ds buffer. */
 size_t new_match_len = ctx->new_match->length;
 size_t undnat_match_len = ctx->undnat_match->length;
 
+/* Create stateless LB NAT rules when using DGPs.
+ * dnat_action: Add the LB backend IPs as a destination action of the
+ *  lr_in_dnat NAT rule with cumulative effect because any
+ *  backend dst IP used in the action list will redirect the
+ *  packet to the ct_lb pipeline.
+ */
+if (od->n_l3dgw_ports > 1) {
+for (size_t i = 0; i < ctx->lb_vip->n_backends; i++) {
+struct ovn_lb_backend *backend = >lb_vip->backends[i];
+bool ipv6 = !IN6_IS_ADDR_V4MAPPED(>ip);
+ds_put_format(_action, "%s.dst=%s;", ipv6 ? "ip6" : "ip4",
+  backend->ip_str);
+}
+}
+ds_put_format(_action, "%s", ctx->new_action[type]);
 
 const char *meter = NULL;
 
@@ -11060,20 +11059,47 @@ build_distr_lrouter_nat_flows_for_lb(struct 
lrouter_nat_lb_flows_ctx *ctx,
 
 if (ctx->lb_vip->n_backends || !ctx->lb_vip->empty_backend_rej) {
 ds_put_format(ctx->new_match, " && is_chassis_resident(%s)",
-  od->l3dgw_ports[0]->cr_port->json_key);
+  dgp->cr_port->json_key);
 }
 
 ovn_lflow_add_with_hint__(ctx->lflows, od, S_ROUTER_IN_DNAT, ctx->prio,
-

Re: [ovs-dev] |fail| pw1959493 [PATCH ovn v2] northd: Fix logical router load-balancer nat rules when using DGP.

[Roberto Bartzen Acosta via dev]

Em ter., 23 de jul. de 2024 às 09:38, Aaron Conole 
escreveu:

> Roberto Bartzen Acosta  writes:
>
> > Hey Aaron,
>
> Hi Roberto,
>
> > How are you doing?
> > How can I see the real reason for this error? the log message "echo '***
> ERROR: 255 ***'"
> > after the "podman cp" doesn't say much to me, sorry.
> > It seems to me that this has no relation to my patch. Can you help me
> understand the
> > problem so I can fix it?
>
> Sure thing - in the link below there is a pointer to a build URL:
>
> https://github.com/ovsrobot/ovn/actions/runs/9897498819
>
>
> And just looking at the logs, for example:
>
> main: clean up vswitch
> 8559
> ../../../tests/ovn.at:36697: test -e $OVS_RUNDIR/ovs-vswitchd.pid
> 8560
> ../../../tests/ovn.at:36697: ovs-appctl --timeout=10 -t ovs-vswitchd exit
> --cleanup
> 8561
> ovn.at:36697: waiting while kill -0 $TMPPID 2>/dev/null...
> 8562
> ovn.at:36697: wait succeeded quickly
> 8563
> ../../../tests/ovn.at:36697: test -e $OVS_RUNDIR/ovsdb-server.pid
> 8564
> ../../../tests/ovn.at:36697: ovs-appctl --timeout=10 -t ovsdb-server exit
> 8565
> ovn.at:36697: waiting while kill -0 $TMPPID 2>/dev/null...
> 8566
> ovn.at:36697: wait succeeded quickly
> 8567
> Undefined Behavior Sanitizer or Address Sanitizer reported errors in:
> sanitizers.126090
> 8568
>
> 8569
> =
> 8570
> ==126090==ERROR: LeakSanitizer: detected memory leaks
> 8571
>
> 8572
> Direct leak of 108 byte(s) in 3 object(s) allocated from:
> 8573
> #0 0x55b195ca1110 in realloc
> (/workspace/ovn-tmp/ovn-24.03.90/_build/sub/northd/ovn-northd+0x377110)
> (BuildId: 2796c1a70d6ad795706de27129fa1f63838eb036)
> 8574
> #1 0x55b196100888 in xrealloc__ /workspace/ovn-tmp/ovs/lib/util.c:150:9
> 8575
> #2 0x55b196100888 in xrealloc /workspace/ovn-tmp/ovs/lib/util.c:182:12
> 8576
> #3 0x55b1960a4801 in ds_reserve
> /workspace/ovn-tmp/ovs/lib/dynamic-string.c:63:22
> 8577
> #4 0x55b1960a4801 in ds_put_format_valist
> /workspace/ovn-tmp/ovs/lib/dynamic-string.c:164:9
> 8578
> #5 0x55b1960a474a in ds_put_format
> /workspace/ovn-tmp/ovs/lib/dynamic-string.c:142:5
> 8579
> #6 0x55b195d98baf in build_distr_lrouter_nat_flows_for_lb
> /workspace/ovn-tmp/ovn-24.03.90/_build/sub/../../northd/northd.c:11079:5
> 8580
> #7 0x55b195d98baf in build_lrouter_nat_flows_for_lb
> /workspace/ovn-tmp/ovn-24.03.90/_build/sub/../../northd/northd.c:11302:17
> 8581
> #8 0x55b195d18f26 in build_lrouter_flows_for_lb
> /workspace/ovn-tmp/ovn-24.03.90/_build/sub/../../northd/northd.c:11440:9
> 8582
> #9 0x55b195cfb804 in build_lflows_thread
> /workspace/ovn-tmp/ovn-24.03.90/_build/sub/../../northd/northd.c:16150:21
> 8583
> #10 0x55b1960d88ce in ovsthread_wrapper
> /workspace/ovn-tmp/ovs/lib/ovs-thread.c:423:12
> 8584
> #11 0x55b195c9e7dc in asan_thread_start(void*) asan_interceptors.cpp.o
> 8585
>
> 8586
> Direct leak of 36 byte(s) in 1 object(s) allocated from:
> 8587
> #0 0x55b195ca1110 in realloc
> (/workspace/ovn-tmp/ovn-24.03.90/_build/sub/northd/ovn-northd+0x377110)
> (BuildId: 2796c1a70d6ad795706de27129fa1f63838eb036)
> 8588
> #1 0x55b196100888 in xrealloc__ /workspace/ovn-tmp/ovs/lib/util.c:150:9
> 8589
> #2 0x55b196100888 in xrealloc /workspace/ovn-tmp/ovs/lib/util.c:182:12
> 8590
> #3 0x55b1960a4801 in ds_reserve
> /workspace/ovn-tmp/ovs/lib/dynamic-string.c:63:22
> 8591
> #4 0x55b1960a4801 in ds_put_format_valist
> /workspace/ovn-tmp/ovs/lib/dynamic-string.c:164:9
> 8592
> #5 0x55b1960a474a in ds_put_format
> /workspace/ovn-tmp/ovs/lib/dynamic-string.c:142:5
> 8593
> #6 0x55b195d98baf in build_distr_lrouter_nat_flows_for_lb
> /workspace/ovn-tmp/ovn-24.03.90/_build/sub/../../northd/northd.c:11079:5
> 8594
> #7 0x55b195d98baf in build_lrouter_nat_flows_for_lb
> /workspace/ovn-tmp/ovn-24.03.90/_build/sub/../../northd/northd.c:11302:17
> 8595
> #8 0x55b195d18f26 in build_lrouter_flows_for_lb
> /workspace/ovn-tmp/ovn-24.03.90/_build/sub/../../northd/northd.c:11440:9
> 8596
> #9 0x55b195d16a60 in lflow_handle_northd_lb_changes
> /workspace/ovn-tmp/ovn-24.03.90/_build/sub/../../northd/northd.c:16793:9
> 8597
> #10 0x55b195dced9a in lflow_northd_handler
> /workspace/ovn-tmp/ovn-24.03.90/_build/sub/../../northd/en-lflow.c:144:10
> 8598
> #11 0x55b195e48bef in engine_compute
> /workspace/ovn-tmp/ovn-24.03.90/_build/sub/../../lib/inc-proc-eng.c:437:28
> 8599
> #12 0x55b195e48bef in engine_run_node
> /workspace/ovn-tmp/ovn-24.03.90/_build/sub/../../lib/inc-proc-eng.c:499:14
> 8600
> #13 0x55b195e48bef in engine_run
> /workspace/ovn-tmp/ovn-24.03.90/_build/sub/../../lib/inc-proc-eng.c:524:9
> 8601
> #14 0x55b195e05da5 in inc_proc_northd_run
> /workspace/ovn-tmp/ovn-24.03.90/_build/sub/../../northd/inc-proc-northd.c:414:5
> 8602
> #15 0x55b195dc1bbc in main
> /workspace/ovn-tmp/ovn-24.03.90/_build/sub/../../northd/ovn-northd.c:970:32
> 8603
> #16 0x7fa4617251c9  

Re: [ovs-dev] [PATCH ovn] northd: Fix logical router load-balancer nat rules when using DGP.

[Roberto Bartzen Acosta via dev]

Em qui., 30 de mai. de 2024 às 11:57, Roberto Bartzen Acosta <
roberto.aco...@luizalabs.com> escreveu:

>
>
> Em qui., 2 de mai. de 2024 às 10:11, Numan Siddique 
> escreveu:
>
>> On Fri, Mar 22, 2024 at 7:51 AM Roberto Bartzen Acosta
>>  wrote:
>> >
>> > Hi Mark,
>> >
>> > Thanks for your feedback.
>> >
>> > Em seg., 18 de mar. de 2024 às 11:53, Mark Michelson <
>> mmich...@redhat.com>
>> > escreveu:
>> >
>> > > Hi Roberto,
>> > >
>> > > I have some concerns about this patch. Let's use the test case you
>> added
>> > > as an example network. Let's bind the vms and DGPs to hypervisors:
>> > >
>> > > * vm1 and lr1-ts1 are bound to hypervisor hv1
>> > > * vm2 and lr1-ts2 are bound to hypervisor hv2
>> > >
>> > > Now imagine a packet arrives on lr1-ts1. The packet gets load balanced
>> > > and sent to vm2. In this case, since lr1-ts1 is on hv1, the
>> ct_lb_mark()
>> > > action runs there, creating a conntrack entry on hv1. However, the
>> > > packet eventually is tunneled to hv2 so that it can be output to vm2.
>> > >
>> > > Now vm2 replies to the packet. Is there anything that ensures that the
>> > > reply from vm2 gets sent to hv1 for the egress pipeline of lr1? If so,
>> > > then this should work fine since the packet will be unDNATted as
>> > > expected on hv1. However, if the packet runs all of lr1's pipelines on
>> > > hv2, then there is no conntrack entry present, and the attempt to
>> unDNAT
>> > > will not succeed. The packet will either be dropped because of invalid
>> > > CT, or the packet will have an incorrect source IP and port. Either
>> way,
>> > > this isn't what is desired.
>>
>
Hi @Mark Michelson  , I solved the problem that you
have pointed out about CT with multiple chassis hosting the DGP in v2 of
this path. Can you please take a look and provide some feedback?

Thanks,
Roberto



> > >
>> >
>> > yep, you're right! that makes sense.
>> > If the packet comes back with a chassis that does not have the related
>> LB
>> > contrack entry corresponding to the initial request, this will trigger a
>> > miss in the pipeline.
>> >
>> > I tried to disable ct tracking for lb by configuring the parameter on
>> the
>> > router, but I still wasn't successful. E.g.:
>> > options:lb_force_snat_ip="172.16.200.201"
>> >
>> > Even changing the lb_force snat ip on the router, or creating a SNAT
>> > "stateless" rule, I still see this action in the output pipeline in the
>> > highest priority table (table=1).
>> >
>> >   table=1 (lr_out_undnat  ), priority=120  , match=(ip4 &&
>> ((ip4.src ==
>> > 10.195.185.2 && tcp.src == 8000) || (ip4.src == 10.195.185.3 && tcp.src
>> ==
>> > 8000) || (ip4.src == 10.195.185.4 && tcp.src == 8000) || (ip4.src ==
>> > 10.195.185.5 && tcp.src == 8000) || (ip4.src == 10.195.185.6 && tcp.src
>> ==
>> > 8000)) && outport == "incus-net40-lr-lrp-01" &&
>> > is_chassis_resident("cr-incus-net40-lr-lrp-01")),
>> action=(ct_dnat_in_czone;)
>> >   table=1 (lr_out_undnat  ), priority=120  , match=(ip4 &&
>> ((ip4.src ==
>> > 10.195.185.2 && tcp.src == 8000) || (ip4.src == 10.195.185.3 && tcp.src
>> ==
>> > 8000) || (ip4.src == 10.195.185.4 && tcp.src == 8000) || (ip4.src ==
>> > 10.195.185.5 && tcp.src == 8000) || (ip4.src == 10.195.185.6 && tcp.src
>> ==
>> > 8000)) && outport == "incus-net40-lr-lrp-02" &&
>> > is_chassis_resident("cr-incus-net40-lr-lrp-02")),
>> action=(ct_dnat_in_czone;)
>> >   table=1 (lr_out_undnat  ), priority=120  , match=(ip4 &&
>> ((ip4.src ==
>> > 10.195.185.2 && tcp.src == 8000) || (ip4.src == 10.195.185.3 && tcp.src
>> ==
>> > 8000) || (ip4.src == 10.195.185.4 && tcp.src == 8000) || (ip4.src ==
>> > 10.195.185.5 && tcp.src == 8000) || (ip4.src == 10.195.185.6 && tcp.src
>> ==
>> > 8000)) && outport == "incus-net40-lr-lrp-03" &&
>> > is_chassis_resident("cr-incus-net40-lr-lrp-03")),
>> action=(ct_dnat_in_czone;)
>> >   table=1 (lr_out_undnat  ), priority=120  , match=(ip4 &&
>> ((ip4.src ==
>> > 10.195.185.2 && tcp.src == 8000) || (ip4.src == 10.195.185.3 && tcp.src
>> ==
>> > 8000) || (ip4.src == 10.195.185.4 && tcp.src == 8000) || (ip4.src ==
>> > 10.195.185.5 && tcp.src == 8000) || (ip4.src == 10.195.185.6 && tcp.src
>> ==
>> > 8000)) && outport == "incus-net40-lr-lrp-04" &&
>> > is_chassis_resident("cr-incus-net40-lr-lrp-04")),
>> action=(ct_dnat_in_czone;)
>> >   table=1 (lr_out_undnat  ), priority=120  , match=(ip4 &&
>> ((ip4.src ==
>> > 10.195.185.2 && tcp.src == 8000) || (ip4.src == 10.195.185.3 && tcp.src
>> ==
>> > 8000) || (ip4.src == 10.195.185.4 && tcp.src == 8000) || (ip4.src ==
>> > 10.195.185.5 && tcp.src == 8000) || (ip4.src == 10.195.185.6 && tcp.src
>> ==
>> > 8000)) && outport == "incus-net40-lr-lrp-ext" &&
>> > is_chassis_resident("cr-incus-net40-lr-lrp-ext")),
>> > action=(ct_dnat_in_czone;)
>> >
>> >
>> > Considering that the return when using multiple DGPs is probably
>> associated
>> > with ECMP, any idea on how to change the rules so that the LB output
>> rules
>> > are 'stateless' (not ct dependent) in this 

[ovs-dev] [PATCH ovn v2] northd: Fix logical router load-balancer nat rules when using DGP.

[Roberto Bartzen Acosta via dev]

This commit fixes the build_distr_lrouter_nat_flows_for_lb function to
include one NAT stateless flow entry for each DGP in use. Since we have
added support to create multiple gateway ports per logical router, it's
necessary to include in the LR nat rules pipeline a specific entry for each
attached DGP. Otherwise, the ingress traffic is only redirected when the
incoming LRP matches the chassis_resident field.

Considering that DNAT rules for DGPs were implemented with the need to
configure the DGP-related gateway-port column, the load-balancer NAT rule
configuration can use a similar idea. In this case, we don't know the LRP
responsible for the incoming traffic, and therefore we need to automatically
apply a stateless NAT rule to the load-balancer on all DGPs to allow inbound
traffic.

After applying this patch, the incoming and/or outgoing traffic can pass
through any chassis where the DGP resides without having problems with CT
state.

Fixes: 15348b7b806f ("ovn-northd: Multiple distributed gateway port support.")
Signed-off-by: Roberto Bartzen Acosta 
---
 northd/en-lr-stateful.c |  12 -
 northd/northd.c |  67 ++--
 tests/ovn-northd.at | 111 
 3 files changed, 163 insertions(+), 27 deletions(-)

diff --git a/northd/en-lr-stateful.c b/northd/en-lr-stateful.c
index baf1bd2f8..f09691af6 100644
--- a/northd/en-lr-stateful.c
+++ b/northd/en-lr-stateful.c
@@ -516,18 +516,6 @@ lr_stateful_record_create(struct lr_stateful_table *table,
 
 table->array[od->index] = lr_stateful_rec;
 
-/* Load balancers are not supported (yet) if a logical router has multiple
- * distributed gateway port.  Log a warning. */
-if (lr_stateful_rec->has_lb_vip && lr_has_multiple_gw_ports(od)) {
-static struct vlog_rate_limit rl = VLOG_RATE_LIMIT_INIT(1, 1);
-VLOG_WARN_RL(, "Load-balancers are configured on logical "
- "router %s, which has %"PRIuSIZE" distributed "
- "gateway ports. Load-balancer is not supported "
- "yet when there is more than one distributed "
- "gateway port on the router.",
- od->nbr->name, od->n_l3dgw_ports);
-}
-
 return lr_stateful_rec;
 }
 
diff --git a/northd/northd.c b/northd/northd.c
index 6898daa00..9d22698c9 100644
--- a/northd/northd.c
+++ b/northd/northd.c
@@ -11026,24 +11026,25 @@ static void
 build_distr_lrouter_nat_flows_for_lb(struct lrouter_nat_lb_flows_ctx *ctx,
  enum lrouter_nat_lb_flow_type type,
  struct ovn_datapath *od,
- struct lflow_ref *lflow_ref)
+ struct lflow_ref *lflow_ref,
+ struct ovn_port *dgp)
 {
-struct ovn_port *dgp = od->l3dgw_ports[0];
-
-const char *undnat_action;
+struct ds undnat_action = DS_EMPTY_INITIALIZER;
+struct ds dnat_action = DS_EMPTY_INITIALIZER;
+struct ds snat_action = DS_EMPTY_INITIALIZER;
 
 switch (type) {
 case LROUTER_NAT_LB_FLOW_FORCE_SNAT:
-undnat_action = "flags.force_snat_for_lb = 1; next;";
+ds_put_format(_action, "flags.force_snat_for_lb = 1; next;");
 break;
 case LROUTER_NAT_LB_FLOW_SKIP_SNAT:
-undnat_action = "flags.skip_snat_for_lb = 1; next;";
+ds_put_format(_action, "flags.skip_snat_for_lb = 1; next;");
 break;
 case LROUTER_NAT_LB_FLOW_NORMAL:
 case LROUTER_NAT_LB_FLOW_MAX:
-undnat_action = lrouter_use_common_zone(od)
-? "ct_dnat_in_czone;"
-: "ct_dnat;";
+ds_put_format(_action, "%s",
+  lrouter_use_common_zone(od) ? "ct_dnat_in_czone;"
+  : "ct_dnat;");
 break;
 }
 
@@ -11051,6 +11052,31 @@ build_distr_lrouter_nat_flows_for_lb(struct 
lrouter_nat_lb_flows_ctx *ctx,
 size_t new_match_len = ctx->new_match->length;
 size_t undnat_match_len = ctx->undnat_match->length;
 
+/* Change the logic to create LB NAT rules when we are using DGPs.
+ * 1. Remove the ct action from the lr_out_undenat NAT rule.
+ * 2. Add the LB backend IPs as a destination action of the lr_in_dnat
+ *NAT rule with cumulative effect because any backend dst IP used in
+ *the action list will redirect the packet to the ct_lb pipeline.
+ * 3. Add a new lr_out_snat NAT rule with the LB VIP as source IP
+ *action to perform the NAT stateless pipeline completely.
+ */
+if (od->n_l3dgw_ports > 1) {
+ds_clear(_action);
+ds_put_format(_action, "next;");
+
+for (size_t i = 0; i < ctx->lb_vip->n_backends; i++) {
+struct ovn_lb_backend *backend = >lb_vip->backends[i];
+bool ipv6 = !IN6_IS_ADDR_V4MAPPED(>ip);
+ds_put_format(_action, "%s.dst=%s;", ipv6 ? "ip6" : "ip4",
+ 

[ovs-dev] [PATCH ovn v5] ovn-ic: Fix global blacklist filter for IPv6 addresses.

[Roberto Bartzen Acosta via dev]

This commit fixes the prefix filter function as the return condition for
IPv6 addresses is disabling the advertisement of all learned prefixes
regardless of the match with the blacklist or not.

Reported-at: https://bugs.launchpad.net/ubuntu/+source/ovn/+bug/2046804
Fixes: 57b347c55168 ("ovn-ic: Route advertisement.")
Signed-off-by: Roberto Bartzen Acosta 
---
 ic/ovn-ic.c | 15 +---
 tests/ovn-ic.at | 99 +
 2 files changed, 108 insertions(+), 6 deletions(-)

diff --git a/ic/ovn-ic.c b/ic/ovn-ic.c
index 6f8f5734d..bc9aea057 100644
--- a/ic/ovn-ic.c
+++ b/ic/ovn-ic.c
@@ -1064,12 +1064,15 @@ prefix_is_black_listed(const struct smap *nb_options,
 continue;
 }
 } else {
-struct in6_addr mask = ipv6_create_mask(bl_plen);
-for (int i = 0; i < 16 && mask.s6_addr[i] != 0; i++) {
-if ((prefix->s6_addr[i] & mask.s6_addr[i])
-!= (bl_prefix.s6_addr[i] & mask.s6_addr[i])) {
-continue;
-}
+struct in6_addr mask = ipv6_create_mask(plen);
+/* First calculate the difference between bl_prefix and prefix, so
+ * use the bl mask to ensure prefixes are correctly validated.
+ * e.g.: 2005:1734:5678::/50 is a subnet of 2005:1234::/21 */
+struct in6_addr m_prefixes = ipv6_addr_bitand(prefix, _prefix);
+struct in6_addr m_prefix = ipv6_addr_bitand(_prefixes, );
+struct in6_addr m_bl_prefix = ipv6_addr_bitand(_prefix, );
+if (!ipv6_addr_equals(_prefix, _bl_prefix)) {
+continue;
 }
 }
 matched = true;
diff --git a/tests/ovn-ic.at b/tests/ovn-ic.at
index d4c436f84..6eb81e158 100644
--- a/tests/ovn-ic.at
+++ b/tests/ovn-ic.at
@@ -1274,3 +1274,102 @@ OVN_CLEANUP_IC([az1], [az2])
 
 AT_CLEANUP
 ])
+
+OVN_FOR_EACH_NORTHD([
+AT_SETUP([ovn-ic -- route sync -- IPv6 blacklist filter])
+AT_KEYWORDS([IPv6-route-sync-blacklist])
+
+ovn_init_ic_db
+check ovn-ic-nbctl ts-add ts1
+
+for i in 1 2; do
+ovn_start az$i
+ovn_as az$i
+
+# Enable route learning at AZ level
+check ovn-nbctl set nb_global . options:ic-route-learn=true
+# Enable route advertising at AZ level
+check ovn-nbctl set nb_global . options:ic-route-adv=true
+# Enable blacklist single filter for IPv6
+check ovn-nbctl set nb_global . options:ic-route-blacklist=" \
+2003:db8:1::/64,2004:::/32,2005:1234::/21"
+
+OVS_WAIT_UNTIL([ovn-nbctl show | grep ts1])
+
+# Create LRP and connect to TS
+check ovn-nbctl lr-add lr$i
+check ovn-nbctl lrp-add lr$i lrp-lr$i-ts1 aa:aa:aa:aa:aa:0$i \
+2001:db8:1::$i/64
+check ovn-nbctl lsp-add ts1 lsp-ts1-lr$i \
+-- lsp-set-addresses lsp-ts1-lr$i router \
+-- lsp-set-type lsp-ts1-lr$i router \
+-- lsp-set-options lsp-ts1-lr$i router-port=lrp-lr$i-ts1
+
+check ovn-nbctl lrp-add lr$i lrp-lr$i-p$i 00:00:00:00:00:0$i \
+2002:db8:1::$i/64
+
+# Create blacklisted LRPs and connect to TS
+check ovn-nbctl lrp-add lr$i lrp-lr$i-p-ext$i \
+11:11:11:11:11:1$i 2003:db8:1::$i/64
+
+check ovn-nbctl lrp-add lr$i lrp-lr$i-p-ext2$i \
+22:22:22:22:22:2$i 2004::bbb::$i/48
+
+# filtered by 2005:1234::/21 - (2005:1000: - 2005:17ff:)
+check ovn-nbctl lrp-add lr$i lrp-lr$i-p-ext3$i \
+33:33:33:33:33:3$i 2005:1734:5678::$i/50
+
+# additional not filtered prefix -> different subnet bits
+check ovn-nbctl lrp-add lr$i lrp-lr$i-p-ext4$i \
+44:44:44:44:44:4$i 2005:1834:5678::$i/50
+done
+
+for i in 1 2; do
+OVS_WAIT_UNTIL([ovn_as az$i ovn-nbctl lr-route-list lr$i | grep learned])
+done
+
+AT_CHECK([ovn_as az1 ovn-nbctl lr-route-list lr1 |
+awk '/learned/{print $1, $2}' ], [0], [dnl
+2002:db8:1::/64 2001:db8:1::2
+2005:1834:5678::/50 2001:db8:1::2
+])
+
+for i in 1 2; do
+ovn_as az$i
+
+# Drop blacklist
+check ovn-nbctl remove nb_global . options ic-route-blacklist
+done
+
+OVS_WAIT_FOR_OUTPUT([ovn_as az1 ovn-nbctl lr-route-list lr1 |
+awk '/learned/{print $1, $2}' | sort ], [0], [dnl
+2002:db8:1::/64 2001:db8:1::2
+2003:db8:1::/64 2001:db8:1::2
+2004::bbb::/48 2001:db8:1::2
+2005:1734:5678::/50 2001:db8:1::2
+2005:1834:5678::/50 2001:db8:1::2
+])
+
+for i in 1 2; do
+ovn_as az$i
+
+check ovn-nbctl set nb_global . \
+options:ic-route-blacklist="2003:db8:1::/64,2004:db8:1::/64"
+
+# Create an 'extra' blacklisted LRP and connect to TS
+check ovn-nbctl lrp-add lr$i lrp-lr$i-p-ext5$i \
+55:55:55:55:55:5$i 2004:db8:1::$i/64
+done
+
+OVS_WAIT_FOR_OUTPUT([ovn_as az1 ovn-nbctl lr-route-list lr1 |
+awk '/learned/{print $1, $2}' | sort ], [0], [dnl
+2002:db8:1::/64 2001:db8:1::2
+2004::bbb::/48 2001:db8:1::2
+2005:1734:5678::/50 2001:db8:1::2
+2005:1834:5678::/50 2001:db8:1::2
+])
+

Re: [ovs-dev] [PATCH ovn v4] ovn-ic: Fix global blacklist filter for IPv6 addresses.

[Roberto Bartzen Acosta via dev]

Hi Dumitru, thanks for the feedback!
I will change the test file and send a new patch as you suggested, thanks.

Em sex., 9 de fev. de 2024 às 06:47, Dumitru Ceara 
escreveu:

> Hi Roberto,
>
> Thanks for the fix!  I have a few minor comments though.
>
>
> On 2/5/24 10:01, Ales Musil wrote:
> > On Mon, Feb 5, 2024 at 2:02 AM Roberto Bartzen Acosta via dev <
> > ovs-dev@openvswitch.org> wrote:
> >
> >> This commit fixes the prefix filter function as the return condition for
> >> IPv6 addresses is disabling the advertisement of all learned prefixes
> >> regardless of the match with the blacklist or not.
>
> Please use shorter lines in the commit message.
>
> >>
> >> Reported-at: https://bugs.launchpad.net/ubuntu/+source/ovn/+bug/2046804
> >> Fixes: 57b347c55168 ("ovn-ic: Route advertisement.")
> >> Signed-off-by: Roberto Bartzen Acosta 
>
> Should we update the .mailmap file too?  The AUTHORS file has you listed
> with your gmail address.  Anyway, that can be a separate patch or I can
> just add a commit when applying this fix.
>

Sure, go ahead with updating the .mailmap if it's not a problem for you.
Thanks


>
> >> --->>  ic/ovn-ic.c |  15 +---
> >>  tests/ovn-ic.at | 100 
> >>  2 files changed, 109 insertions(+), 6 deletions(-)
> >>
> >> diff --git a/ic/ovn-ic.c b/ic/ovn-ic.c
> >> index 6f8f5734d..bc9aea057 100644
> >> --- a/ic/ovn-ic.c
> >> +++ b/ic/ovn-ic.c
> >> @@ -1064,12 +1064,15 @@ prefix_is_black_listed(const struct smap
> >> *nb_options,
> >>  continue;
> >>  }
> >>  } else {
> >> -struct in6_addr mask = ipv6_create_mask(bl_plen);
> >> -for (int i = 0; i < 16 && mask.s6_addr[i] != 0; i++) {
> >> -if ((prefix->s6_addr[i] & mask.s6_addr[i])
> >> -!= (bl_prefix.s6_addr[i] & mask.s6_addr[i])) {
> >> -continue;
> >> -}
> >> +struct in6_addr mask = ipv6_create_mask(plen);
> >> +/* First calculate the difference between bl_prefix and
> >> prefix, so
> >> + * use the bl mask to ensure prefixes are correctly
> validated.
> >> + * e.g.: 2005:1734:5678::/50 is a subnet of 2005:1234::/21
> */
> >> +struct in6_addr m_prefixes = ipv6_addr_bitand(prefix,
> >> _prefix);
> >> +struct in6_addr m_prefix = ipv6_addr_bitand(_prefixes,
> >> );
> >> +struct in6_addr m_bl_prefix = ipv6_addr_bitand(_prefix,
> >> );
> >> +if (!ipv6_addr_equals(_prefix, _bl_prefix)) {
> >> +continue;
> >>  }
> >>  }
> >>  matched = true;
> >> diff --git a/tests/ovn-ic.at b/tests/ovn-ic.at
> >> index d4c436f84..1f9df71e9 100644
> >> --- a/tests/ovn-ic.at
> >> +++ b/tests/ovn-ic.at
> >> @@ -1274,3 +1274,103 @@ OVN_CLEANUP_IC([az1], [az2])
> >>
> >>  AT_CLEANUP
> >>  ])
> >> +
> >> +OVN_FOR_EACH_NORTHD([
> >> +AT_SETUP([ovn-ic -- route sync -- IPv6 blacklist filter])
> >> +AT_KEYWORDS([IPv6-route-sync-blacklist])
> >> +
> >> +ovn_init_ic_db
> >> +ovn-ic-nbctl ts-add ts1
> >> +
> >> +for i in 1 2; do
> >> +ovn_start az$i
> >> +ovn_as az$i
> >> +
> >> +# Enable route learning at AZ level
> >> +ovn-nbctl set nb_global . options:ic-route-learn=true
> >> +# Enable route advertising at AZ level
> >> +ovn-nbctl set nb_global . options:ic-route-adv=true
> >> +# Enable blacklist single filter for IPv6
> >> +ovn-nbctl set nb_global .
> >> options:ic-route-blacklist="2003:db8:1::/64,\
> >> +2004:::/32,2005:1234::/21"
> >> +
> >> +OVS_WAIT_UNTIL([ovn-nbctl show | grep ts1])
> >> +
> >> +# Create LRP and connect to TS
> >> +ovn-nbctl lr-add lr$i
> >> +ovn-nbctl lrp-add lr$i lrp-lr$i-ts1 aa:aa:aa:aa:aa:0$i
> >> 2001:db8:1::$i/64
> >> +ovn-nbctl lsp-add ts1 lsp-ts1-lr$i \
> >> +-- lsp-set-addresses lsp-ts1-lr$i router \
> >> +-- lsp-set-type lsp-ts1-lr$i router \
> >> +-- lsp-set-options lsp-ts1-lr$i router-port=lrp-lr$i-ts1
> >> +
> >> +ovn-nbctl lrp-add lr$i lrp-lr$i-p$

[ovs-dev] [PATCH ovs v4] Documentation: Adding note about using the jemalloc library.

[Roberto Bartzen Acosta via dev]

Updating the reference documentation with the inclusion of possible building
problems with libjemalloc and solution suggestions.

Reported-at: https://bugs.launchpad.net/ubuntu/+source/openvswitch/+bug/2015748
Signed-off-by: Roberto Bartzen Acosta 
---
 Documentation/intro/install/general.rst | 16 
 1 file changed, 16 insertions(+)

diff --git a/Documentation/intro/install/general.rst 
b/Documentation/intro/install/general.rst
index ab6209482..986913a91 100644
--- a/Documentation/intro/install/general.rst
+++ b/Documentation/intro/install/general.rst
@@ -308,6 +308,22 @@ you wish to link with jemalloc add it to LIBS::
 
 $ ./configure LIBS=-ljemalloc
 
+.. note::
+  Linking Open vSwitch with the jemalloc shared library may not work as
+  expected in certain operating system development environments. You can
+  override the automatic compiler decision to avoid possible linker issues by
+  passing ``-fno-lto`` or ``-fno-builtin`` flag since the jemalloc override
+  standard built-in memory allocation functions such as malloc, calloc, etc.
+  Both options can solve possible jemalloc linker issues with pros and cons for
+  each case, feel free to choose the path that appears best to you. Disabling
+  LTO flag example::
+
+  $ ./configure LIBS=-ljemalloc CFLAGS="-g -O2 -fno-lto"
+
+  Disabling built-in flag example::
+
+  ./configure LIBS=-ljemalloc CFLAGS="-g -O2 -fno-builtin"
+
 Example usage::
 $ # Clone OVS repo
 $cd /home/foo/ovs
-- 
2.25.1


-- 




_'Esta mensagem é direcionada apenas para os endereços constantes no 
cabeçalho inicial. Se você não está listado nos endereços constantes no 
cabeçalho, pedimos-lhe que desconsidere completamente o conteúdo dessa 
mensagem e cuja cópia, encaminhamento e/ou execução das ações citadas estão 
imediatamente anuladas e proibidas'._


* **'Apesar do Magazine Luiza tomar 
todas as precauções razoáveis para assegurar que nenhum vírus esteja 
presente nesse e-mail, a empresa não poderá aceitar a responsabilidade por 
quaisquer perdas ou danos causados por esse e-mail ou por seus anexos'.*



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

Re: [ovs-dev] [PATCH ovs v3] Documentation: Adding note about using the jemalloc library.

[Roberto Bartzen Acosta via dev]

Thanks for the review Eelco,

Em seg., 5 de fev. de 2024 às 04:32, Eelco Chaudron 
escreveu:

>
>
> On 5 Feb 2024, at 2:24, Roberto Bartzen Acosta via dev wrote:
>
> > Updating the reference documentation with the inclusion of possible
> building
> > problems with libjemalloc and solution suggestions.
> >
> > Reported-at:
> https://bugs.launchpad.net/ubuntu/+source/openvswitch/+bug/2015748
> > Signed-off-by: Roberto Bartzen Acosta 
> > ---
> >  Documentation/intro/install/general.rst | 16 
> >  1 file changed, 16 insertions(+)
> >
> > diff --git a/Documentation/intro/install/general.rst
> b/Documentation/intro/install/general.rst
> > index ab6209482..eeb55075c 100644
> > --- a/Documentation/intro/install/general.rst
> > +++ b/Documentation/intro/install/general.rst
> > @@ -308,6 +308,22 @@ you wish to link with jemalloc add it to LIBS::
> >
> >  $ ./configure LIBS=-ljemalloc
> >
> > +.. note::
> > +  Linking Open vSwitch with the jemalloc shared library may not work as
> > +  expected in certain operating system development environments. You can
> > +  override the automatic compiler decision to avoid possible linker
> issues by
> > +  passing ``-fno-lto`` or ``-fno-builtin`` flag since the jemalloc
> override
> > +  standard built-in memory allocation functions such as malloc, calloc,
> etc.
> > +  Both options can solve possible jemalloc linker issues with pros and
> cons for
> > +  each case, feel free to choose the path that appears best to you.
> Disabling
> > +  LTO flag example::
> > +
> > +  $ ./configure LIBS=-ljemalloc CFLAGS=-fno-lto
> > +
> > +  Disabling built-in flag example::
> > +
> > +  ./configure LIBS=-ljemalloc CFLAGS=-fno-builtin
>
> Should we also include the default CFLAGS? As this option overrides all
> CFLAGS, so now we also remove the default “-g -O2” options.
>

Sure, I took a look at the configuration examples and others also pass the
"-g -O2" in CFLAGS as your suggestion. So, I will change this and send a
new patch version.
Thanks,
Roberto


>
> > +
> >  Example usage::
> >  $ # Clone OVS repo
> >  $cd /home/foo/ovs
> > --
> > 2.25.1
> >
> >
> > --
> >
> >
> >
> >
> > _'Esta mensagem é direcionada apenas para os endereços constantes no
> > cabeçalho inicial. Se você não está listado nos endereços constantes no
> > cabeçalho, pedimos-lhe que desconsidere completamente o conteúdo dessa
> > mensagem e cuja cópia, encaminhamento e/ou execução das ações citadas
> estão
> > imediatamente anuladas e proibidas'._
> >
> >
> > * **'Apesar do Magazine Luiza tomar
> > todas as precauções razoáveis para assegurar que nenhum vírus esteja
> > presente nesse e-mail, a empresa não poderá aceitar a responsabilidade
> por
> > quaisquer perdas ou danos causados por esse e-mail ou por seus anexos'.*
> >
> >
> >
> > ___
> > dev mailing list
> > d...@openvswitch.org
> > https://mail.openvswitch.org/mailman/listinfo/ovs-dev
>
>

-- 




_‘Esta mensagem é direcionada apenas para os endereços constantes no 
cabeçalho inicial. Se você não está listado nos endereços constantes no 
cabeçalho, pedimos-lhe que desconsidere completamente o conteúdo dessa 
mensagem e cuja cópia, encaminhamento e/ou execução das ações citadas estão 
imediatamente anuladas e proibidas’._


* **‘Apesar do Magazine Luiza tomar 
todas as precauções razoáveis para assegurar que nenhum vírus esteja 
presente nesse e-mail, a empresa não poderá aceitar a responsabilidade por 
quaisquer perdas ou danos causados por esse e-mail ou por seus anexos’.*



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

[ovs-dev] [PATCH ovs v3] Documentation: Adding note about using the jemalloc library.

[Roberto Bartzen Acosta via dev]

Updating the reference documentation with the inclusion of possible building
problems with libjemalloc and solution suggestions.

Reported-at: https://bugs.launchpad.net/ubuntu/+source/openvswitch/+bug/2015748
Signed-off-by: Roberto Bartzen Acosta 
---
 Documentation/intro/install/general.rst | 16 
 1 file changed, 16 insertions(+)

diff --git a/Documentation/intro/install/general.rst 
b/Documentation/intro/install/general.rst
index ab6209482..eeb55075c 100644
--- a/Documentation/intro/install/general.rst
+++ b/Documentation/intro/install/general.rst
@@ -308,6 +308,22 @@ you wish to link with jemalloc add it to LIBS::
 
 $ ./configure LIBS=-ljemalloc
 
+.. note::
+  Linking Open vSwitch with the jemalloc shared library may not work as
+  expected in certain operating system development environments. You can
+  override the automatic compiler decision to avoid possible linker issues by
+  passing ``-fno-lto`` or ``-fno-builtin`` flag since the jemalloc override
+  standard built-in memory allocation functions such as malloc, calloc, etc.
+  Both options can solve possible jemalloc linker issues with pros and cons for
+  each case, feel free to choose the path that appears best to you. Disabling
+  LTO flag example::
+
+  $ ./configure LIBS=-ljemalloc CFLAGS=-fno-lto
+
+  Disabling built-in flag example::
+
+  ./configure LIBS=-ljemalloc CFLAGS=-fno-builtin
+
 Example usage::
 $ # Clone OVS repo
 $cd /home/foo/ovs
-- 
2.25.1


-- 




_'Esta mensagem é direcionada apenas para os endereços constantes no 
cabeçalho inicial. Se você não está listado nos endereços constantes no 
cabeçalho, pedimos-lhe que desconsidere completamente o conteúdo dessa 
mensagem e cuja cópia, encaminhamento e/ou execução das ações citadas estão 
imediatamente anuladas e proibidas'._


* **'Apesar do Magazine Luiza tomar 
todas as precauções razoáveis para assegurar que nenhum vírus esteja 
presente nesse e-mail, a empresa não poderá aceitar a responsabilidade por 
quaisquer perdas ou danos causados por esse e-mail ou por seus anexos'.*



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

[ovs-dev] [PATCH ovn v4] ovn-ic: Fix global blacklist filter for IPv6 addresses.

[Roberto Bartzen Acosta via dev]

This commit fixes the prefix filter function as the return condition for IPv6 
addresses is disabling the advertisement of all learned prefixes regardless of 
the match with the blacklist or not.

Reported-at: https://bugs.launchpad.net/ubuntu/+source/ovn/+bug/2046804
Fixes: 57b347c55168 ("ovn-ic: Route advertisement.")
Signed-off-by: Roberto Bartzen Acosta 
---
 ic/ovn-ic.c |  15 +---
 tests/ovn-ic.at | 100 
 2 files changed, 109 insertions(+), 6 deletions(-)

diff --git a/ic/ovn-ic.c b/ic/ovn-ic.c
index 6f8f5734d..bc9aea057 100644
--- a/ic/ovn-ic.c
+++ b/ic/ovn-ic.c
@@ -1064,12 +1064,15 @@ prefix_is_black_listed(const struct smap *nb_options,
 continue;
 }
 } else {
-struct in6_addr mask = ipv6_create_mask(bl_plen);
-for (int i = 0; i < 16 && mask.s6_addr[i] != 0; i++) {
-if ((prefix->s6_addr[i] & mask.s6_addr[i])
-!= (bl_prefix.s6_addr[i] & mask.s6_addr[i])) {
-continue;
-}
+struct in6_addr mask = ipv6_create_mask(plen);
+/* First calculate the difference between bl_prefix and prefix, so
+ * use the bl mask to ensure prefixes are correctly validated.
+ * e.g.: 2005:1734:5678::/50 is a subnet of 2005:1234::/21 */
+struct in6_addr m_prefixes = ipv6_addr_bitand(prefix, _prefix);
+struct in6_addr m_prefix = ipv6_addr_bitand(_prefixes, );
+struct in6_addr m_bl_prefix = ipv6_addr_bitand(_prefix, );
+if (!ipv6_addr_equals(_prefix, _bl_prefix)) {
+continue;
 }
 }
 matched = true;
diff --git a/tests/ovn-ic.at b/tests/ovn-ic.at
index d4c436f84..1f9df71e9 100644
--- a/tests/ovn-ic.at
+++ b/tests/ovn-ic.at
@@ -1274,3 +1274,103 @@ OVN_CLEANUP_IC([az1], [az2])
 
 AT_CLEANUP
 ])
+
+OVN_FOR_EACH_NORTHD([
+AT_SETUP([ovn-ic -- route sync -- IPv6 blacklist filter])
+AT_KEYWORDS([IPv6-route-sync-blacklist])
+
+ovn_init_ic_db
+ovn-ic-nbctl ts-add ts1
+
+for i in 1 2; do
+ovn_start az$i
+ovn_as az$i
+
+# Enable route learning at AZ level
+ovn-nbctl set nb_global . options:ic-route-learn=true
+# Enable route advertising at AZ level
+ovn-nbctl set nb_global . options:ic-route-adv=true
+# Enable blacklist single filter for IPv6
+ovn-nbctl set nb_global . options:ic-route-blacklist="2003:db8:1::/64,\
+2004:::/32,2005:1234::/21"
+
+OVS_WAIT_UNTIL([ovn-nbctl show | grep ts1])
+
+# Create LRP and connect to TS
+ovn-nbctl lr-add lr$i
+ovn-nbctl lrp-add lr$i lrp-lr$i-ts1 aa:aa:aa:aa:aa:0$i 2001:db8:1::$i/64
+ovn-nbctl lsp-add ts1 lsp-ts1-lr$i \
+-- lsp-set-addresses lsp-ts1-lr$i router \
+-- lsp-set-type lsp-ts1-lr$i router \
+-- lsp-set-options lsp-ts1-lr$i router-port=lrp-lr$i-ts1
+
+ovn-nbctl lrp-add lr$i lrp-lr$i-p$i 00:00:00:00:00:0$i 2002:db8:1::$i/64
+
+# Create blacklisted LRPs and connect to TS
+ovn-nbctl lrp-add lr$i lrp-lr$i-p-ext$i \
+11:11:11:11:11:1$i 2003:db8:1::$i/64
+
+ovn-nbctl lrp-add lr$i lrp-lr$i-p-ext2$i \
+22:22:22:22:22:2$i 2004::bbb::$i/48
+
+# filtered by 2005:1234::/21 - (2005:1000: - 2005:17ff:)
+ovn-nbctl lrp-add lr$i lrp-lr$i-p-ext3$i \
+33:33:33:33:33:3$i 2005:1734:5678::$i/50
+
+# additional not filtered prefix -> different subnet bits
+ovn-nbctl lrp-add lr$i lrp-lr$i-p-ext4$i \
+33:33:33:33:33:3$i 2005:1834:5678::$i/50
+
+done
+
+for i in 1 2; do
+OVS_WAIT_UNTIL([ovn_as az$i ovn-nbctl lr-route-list lr$i | grep learned])
+done
+
+AT_CHECK([ovn_as az1 ovn-nbctl lr-route-list lr1 |
+awk '/learned/{print $1, $2}' ], [0], [dnl
+2002:db8:1::/64 2001:db8:1::2
+2005:1834:5678::/50 2001:db8:1::2
+])
+
+for i in 1 2; do
+ovn_as az$i
+
+# Drop blacklist
+ovn-nbctl remove nb_global . options ic-route-blacklist
+
+done
+
+OVS_WAIT_FOR_OUTPUT([ovn_as az1 ovn-nbctl lr-route-list lr1 |
+awk '/learned/{print $1, $2}' | sort ], [0], [dnl
+2002:db8:1::/64 2001:db8:1::2
+2003:db8:1::/64 2001:db8:1::2
+2004::bbb::/48 2001:db8:1::2
+2005:1734:5678::/50 2001:db8:1::2
+2005:1834:5678::/50 2001:db8:1::2
+])
+
+for i in 1 2; do
+ovn_as az$i
+
+ovn-nbctl set nb_global . \
+options:ic-route-blacklist="2003:db8:1::/64,2004:db8:1::/64"
+
+# Create an 'extra' blacklisted LRP and connect to TS
+ovn-nbctl lrp-add lr$i lrp-lr$i-p-ext2$i \
+44:44:44:44:44:4$i 2004:db8:1::$i/64
+
+done
+
+OVS_WAIT_FOR_OUTPUT([ovn_as az1 ovn-nbctl lr-route-list lr1 |
+awk '/learned/{print $1, $2}' | sort ], [0], [dnl
+2002:db8:1::/64 2001:db8:1::2
+2004::bbb::/48 2001:db8:1::2
+2005:1734:5678::/50 2001:db8:1::2
+2005:1834:5678::/50 2001:db8:1::2
+])
+
+OVN_CLEANUP_IC([az1], [az2])
+
+AT_CLEANUP
+])
-- 
2.25.1


-- 




_'Esta mensagem é direcionada apenas para os endereços 

Re: [ovs-dev] [PATCH ovn v3] ovn-ic: Fix global blacklist filter for IPv6 addresses.

[Roberto Bartzen Acosta via dev]

Thanks for your review Ales.

On Fri, 2 Feb 2024 at 07:34 Ales Musil  wrote:

>
>
> On Tue, Jan 30, 2024 at 3:10 PM Roberto Bartzen Acosta via dev <
> ovs-dev@openvswitch.org> wrote:
>
>> This commit fixes the prefix filter function as the return condition for
>> IPv6 addresses is disabling the advertisement of all learned prefixes
>> regardless of the match with the blacklist or not.
>>
>> Reported-at: https://bugs.launchpad.net/ubuntu/+source/ovn/+bug/2046804
>> Fixes: 57b347c55168 ("ovn-ic: Route advertisement.")
>> Signed-off-by: Roberto Bartzen Acosta 
>> ---
>>
>
> Hi Roberto,
>
> thank you for the patch.
>
>
>>  ic/ovn-ic.c |  22 ---
>>  tests/ovn-ic.at | 100 
>>  2 files changed, 116 insertions(+), 6 deletions(-)
>>
>> diff --git a/ic/ovn-ic.c b/ic/ovn-ic.c
>> index 6f8f5734d..1c9c9ae2c 100644
>> --- a/ic/ovn-ic.c
>> +++ b/ic/ovn-ic.c
>> @@ -1024,6 +1024,20 @@ prefix_is_link_local(struct in6_addr *prefix,
>> unsigned int plen)
>>  ((prefix->s6_addr[1] & 0xc0) == 0x80));
>>  }
>>
>> +static bool
>> +compare_ipv6_prefixes(const struct in6_addr *s_prefix,
>> +  const struct in6_addr *d_prefix2, int plen)
>> +{
>> +struct in6_addr mask = ipv6_create_mask(plen);
>> +for (int i = 0; i <= (plen / 8); i++) {
>> +if ((s_prefix->s6_addr[i] & mask.s6_addr[i]) ^
>> +(d_prefix2->s6_addr[i] & mask.s6_addr[i])) {
>> +return false;
>> +}
>> +}
>> +return true;
>> +}
>> +
>>
>  static bool
>>  prefix_is_black_listed(const struct smap *nb_options,
>> struct in6_addr *prefix,
>> @@ -1064,12 +1078,8 @@ prefix_is_black_listed(const struct smap
>> *nb_options,
>>  continue;
>>  }
>>  } else {
>> -struct in6_addr mask = ipv6_create_mask(bl_plen);
>> -for (int i = 0; i < 16 && mask.s6_addr[i] != 0; i++) {
>> -if ((prefix->s6_addr[i] & mask.s6_addr[i])
>> -!= (bl_prefix.s6_addr[i] & mask.s6_addr[i])) {
>> -continue;
>> -}
>> +if (!compare_ipv6_prefixes(prefix, _prefix, bl_plen)) {
>> +continue;
>>  }
>>
>
>
> There is no need for hand implementation, OvS provides plenty of helpers.
> This can be replaced with something like the snippet below:
>
> struct in6_addr mask = ipv6_create_mask(bl_plen);
> struct in6_addr m_prefix = ipv6_addr_bitand(prefix, );
> struct in6_addr m_bl_prefix = ipv6_addr_bitand(_prefix, );
>
> if (!ipv6_addr_equals(_prefix, _bl_prefix)) {
> continue;
> }
>

Sure, this makes sense. I will change it and send a new patch version.
Thanks


>
>>  }
>>  matched = true;
>> diff --git a/tests/ovn-ic.at b/tests/ovn-ic.at
>> index d4c436f84..1f9df71e9 100644
>> --- a/tests/ovn-ic.at
>> +++ b/tests/ovn-ic.at
>> @@ -1274,3 +1274,103 @@ OVN_CLEANUP_IC([az1], [az2])
>>
>>  AT_CLEANUP
>>  ])
>> +
>> +OVN_FOR_EACH_NORTHD([
>> +AT_SETUP([ovn-ic -- route sync -- IPv6 blacklist filter])
>> +AT_KEYWORDS([IPv6-route-sync-blacklist])
>> +
>> +ovn_init_ic_db
>> +ovn-ic-nbctl ts-add ts1
>> +
>> +for i in 1 2; do
>> +ovn_start az$i
>> +ovn_as az$i
>> +
>> +# Enable route learning at AZ level
>> +ovn-nbctl set nb_global . options:ic-route-learn=true
>> +# Enable route advertising at AZ level
>> +ovn-nbctl set nb_global . options:ic-route-adv=true
>> +# Enable blacklist single filter for IPv6
>> +ovn-nbctl set nb_global .
>> options:ic-route-blacklist="2003:db8:1::/64,\
>> +2004:::/32,2005:1234::/21"
>> +
>> +OVS_WAIT_UNTIL([ovn-nbctl show | grep ts1])
>> +
>> +# Create LRP and connect to TS
>> +ovn-nbctl lr-add lr$i
>> +ovn-nbctl lrp-add lr$i lrp-lr$i-ts1 aa:aa:aa:aa:aa:0$i
>> 2001:db8:1::$i/64
>> +ovn-nbctl lsp-add ts1 lsp-ts1-lr$i \
>> +-- lsp-set-addresses lsp-ts1-lr$i router \
>> +-- lsp-set-type lsp-ts1-lr$i router \
>> +-- lsp-set-options lsp-ts1-lr$i router-port=lrp-lr$i-ts1
>> +
>> +ovn-nbctl lrp-add lr$i lrp-lr$i-p$i 00:00:00:00:00:0$i
>> 2002:db8:1::$i/64
>> +
>> +# Create blacklisted LRPs and connect to T

[ovs-dev] [PATCH ovn v3] ovn-ic: Fix global blacklist filter for IPv6 addresses.

[Roberto Bartzen Acosta via dev]

This commit fixes the prefix filter function as the return condition for IPv6 
addresses is disabling the advertisement of all learned prefixes regardless of 
the match with the blacklist or not.

Reported-at: https://bugs.launchpad.net/ubuntu/+source/ovn/+bug/2046804
Fixes: 57b347c55168 ("ovn-ic: Route advertisement.")
Signed-off-by: Roberto Bartzen Acosta 
---
 ic/ovn-ic.c |  22 ---
 tests/ovn-ic.at | 100 
 2 files changed, 116 insertions(+), 6 deletions(-)

diff --git a/ic/ovn-ic.c b/ic/ovn-ic.c
index 6f8f5734d..1c9c9ae2c 100644
--- a/ic/ovn-ic.c
+++ b/ic/ovn-ic.c
@@ -1024,6 +1024,20 @@ prefix_is_link_local(struct in6_addr *prefix, unsigned 
int plen)
 ((prefix->s6_addr[1] & 0xc0) == 0x80));
 }
 
+static bool
+compare_ipv6_prefixes(const struct in6_addr *s_prefix,
+  const struct in6_addr *d_prefix2, int plen)
+{
+struct in6_addr mask = ipv6_create_mask(plen);
+for (int i = 0; i <= (plen / 8); i++) {
+if ((s_prefix->s6_addr[i] & mask.s6_addr[i]) ^
+(d_prefix2->s6_addr[i] & mask.s6_addr[i])) {
+return false;
+}
+}
+return true;
+}
+
 static bool
 prefix_is_black_listed(const struct smap *nb_options,
struct in6_addr *prefix,
@@ -1064,12 +1078,8 @@ prefix_is_black_listed(const struct smap *nb_options,
 continue;
 }
 } else {
-struct in6_addr mask = ipv6_create_mask(bl_plen);
-for (int i = 0; i < 16 && mask.s6_addr[i] != 0; i++) {
-if ((prefix->s6_addr[i] & mask.s6_addr[i])
-!= (bl_prefix.s6_addr[i] & mask.s6_addr[i])) {
-continue;
-}
+if (!compare_ipv6_prefixes(prefix, _prefix, bl_plen)) {
+continue;
 }
 }
 matched = true;
diff --git a/tests/ovn-ic.at b/tests/ovn-ic.at
index d4c436f84..1f9df71e9 100644
--- a/tests/ovn-ic.at
+++ b/tests/ovn-ic.at
@@ -1274,3 +1274,103 @@ OVN_CLEANUP_IC([az1], [az2])
 
 AT_CLEANUP
 ])
+
+OVN_FOR_EACH_NORTHD([
+AT_SETUP([ovn-ic -- route sync -- IPv6 blacklist filter])
+AT_KEYWORDS([IPv6-route-sync-blacklist])
+
+ovn_init_ic_db
+ovn-ic-nbctl ts-add ts1
+
+for i in 1 2; do
+ovn_start az$i
+ovn_as az$i
+
+# Enable route learning at AZ level
+ovn-nbctl set nb_global . options:ic-route-learn=true
+# Enable route advertising at AZ level
+ovn-nbctl set nb_global . options:ic-route-adv=true
+# Enable blacklist single filter for IPv6
+ovn-nbctl set nb_global . options:ic-route-blacklist="2003:db8:1::/64,\
+2004:::/32,2005:1234::/21"
+
+OVS_WAIT_UNTIL([ovn-nbctl show | grep ts1])
+
+# Create LRP and connect to TS
+ovn-nbctl lr-add lr$i
+ovn-nbctl lrp-add lr$i lrp-lr$i-ts1 aa:aa:aa:aa:aa:0$i 2001:db8:1::$i/64
+ovn-nbctl lsp-add ts1 lsp-ts1-lr$i \
+-- lsp-set-addresses lsp-ts1-lr$i router \
+-- lsp-set-type lsp-ts1-lr$i router \
+-- lsp-set-options lsp-ts1-lr$i router-port=lrp-lr$i-ts1
+
+ovn-nbctl lrp-add lr$i lrp-lr$i-p$i 00:00:00:00:00:0$i 2002:db8:1::$i/64
+
+# Create blacklisted LRPs and connect to TS
+ovn-nbctl lrp-add lr$i lrp-lr$i-p-ext$i \
+11:11:11:11:11:1$i 2003:db8:1::$i/64
+
+ovn-nbctl lrp-add lr$i lrp-lr$i-p-ext2$i \
+22:22:22:22:22:2$i 2004::bbb::$i/48
+
+# filtered by 2005:1234::/21 - (2005:1000: - 2005:17ff:)
+ovn-nbctl lrp-add lr$i lrp-lr$i-p-ext3$i \
+33:33:33:33:33:3$i 2005:1734:5678::$i/50
+
+# additional not filtered prefix -> different subnet bits
+ovn-nbctl lrp-add lr$i lrp-lr$i-p-ext4$i \
+33:33:33:33:33:3$i 2005:1834:5678::$i/50
+
+done
+
+for i in 1 2; do
+OVS_WAIT_UNTIL([ovn_as az$i ovn-nbctl lr-route-list lr$i | grep learned])
+done
+
+AT_CHECK([ovn_as az1 ovn-nbctl lr-route-list lr1 |
+awk '/learned/{print $1, $2}' ], [0], [dnl
+2002:db8:1::/64 2001:db8:1::2
+2005:1834:5678::/50 2001:db8:1::2
+])
+
+for i in 1 2; do
+ovn_as az$i
+
+# Drop blacklist
+ovn-nbctl remove nb_global . options ic-route-blacklist
+
+done
+
+OVS_WAIT_FOR_OUTPUT([ovn_as az1 ovn-nbctl lr-route-list lr1 |
+awk '/learned/{print $1, $2}' | sort ], [0], [dnl
+2002:db8:1::/64 2001:db8:1::2
+2003:db8:1::/64 2001:db8:1::2
+2004::bbb::/48 2001:db8:1::2
+2005:1734:5678::/50 2001:db8:1::2
+2005:1834:5678::/50 2001:db8:1::2
+])
+
+for i in 1 2; do
+ovn_as az$i
+
+ovn-nbctl set nb_global . \
+options:ic-route-blacklist="2003:db8:1::/64,2004:db8:1::/64"
+
+# Create an 'extra' blacklisted LRP and connect to TS
+ovn-nbctl lrp-add lr$i lrp-lr$i-p-ext2$i \
+44:44:44:44:44:4$i 2004:db8:1::$i/64
+
+done
+
+OVS_WAIT_FOR_OUTPUT([ovn_as az1 ovn-nbctl lr-route-list lr1 |
+awk '/learned/{print $1, $2}' | sort ], [0], [dnl
+2002:db8:1::/64 2001:db8:1::2
+2004::bbb::/48 2001:db8:1::2

[ovs-dev] [PATCH ovn v2] ovn-ic: fix global blacklist filter for IPv6 addresses

[Roberto Bartzen Acosta via dev]

This commit fixes the prefix filter function as the return condition for IPv6 
addresses is disabling the advertisement of all learned prefixes regardless of 
the match with the blacklist or not.

Reported-at: https://bugs.launchpad.net/ubuntu/+source/ovn/+bug/2046804
Fixes: 57b347c55168 ("ovn-ic: Route advertisement.")
---
 ic/ovn-ic.c |  22 ---
 tests/ovn-ic.at | 100 
 2 files changed, 116 insertions(+), 6 deletions(-)

diff --git a/ic/ovn-ic.c b/ic/ovn-ic.c
index 6f8f5734d..1c9c9ae2c 100644
--- a/ic/ovn-ic.c
+++ b/ic/ovn-ic.c
@@ -1024,6 +1024,20 @@ prefix_is_link_local(struct in6_addr *prefix, unsigned 
int plen)
 ((prefix->s6_addr[1] & 0xc0) == 0x80));
 }
 
+static bool
+compare_ipv6_prefixes(const struct in6_addr *s_prefix,
+  const struct in6_addr *d_prefix2, int plen)
+{
+struct in6_addr mask = ipv6_create_mask(plen);
+for (int i = 0; i <= (plen / 8); i++) {
+if ((s_prefix->s6_addr[i] & mask.s6_addr[i]) ^
+(d_prefix2->s6_addr[i] & mask.s6_addr[i])) {
+return false;
+}
+}
+return true;
+}
+
 static bool
 prefix_is_black_listed(const struct smap *nb_options,
struct in6_addr *prefix,
@@ -1064,12 +1078,8 @@ prefix_is_black_listed(const struct smap *nb_options,
 continue;
 }
 } else {
-struct in6_addr mask = ipv6_create_mask(bl_plen);
-for (int i = 0; i < 16 && mask.s6_addr[i] != 0; i++) {
-if ((prefix->s6_addr[i] & mask.s6_addr[i])
-!= (bl_prefix.s6_addr[i] & mask.s6_addr[i])) {
-continue;
-}
+if (!compare_ipv6_prefixes(prefix, _prefix, bl_plen)) {
+continue;
 }
 }
 matched = true;
diff --git a/tests/ovn-ic.at b/tests/ovn-ic.at
index d4c436f84..1f9df71e9 100644
--- a/tests/ovn-ic.at
+++ b/tests/ovn-ic.at
@@ -1274,3 +1274,103 @@ OVN_CLEANUP_IC([az1], [az2])
 
 AT_CLEANUP
 ])
+
+OVN_FOR_EACH_NORTHD([
+AT_SETUP([ovn-ic -- route sync -- IPv6 blacklist filter])
+AT_KEYWORDS([IPv6-route-sync-blacklist])
+
+ovn_init_ic_db
+ovn-ic-nbctl ts-add ts1
+
+for i in 1 2; do
+ovn_start az$i
+ovn_as az$i
+
+# Enable route learning at AZ level
+ovn-nbctl set nb_global . options:ic-route-learn=true
+# Enable route advertising at AZ level
+ovn-nbctl set nb_global . options:ic-route-adv=true
+# Enable blacklist single filter for IPv6
+ovn-nbctl set nb_global . options:ic-route-blacklist="2003:db8:1::/64,\
+2004:::/32,2005:1234::/21"
+
+OVS_WAIT_UNTIL([ovn-nbctl show | grep ts1])
+
+# Create LRP and connect to TS
+ovn-nbctl lr-add lr$i
+ovn-nbctl lrp-add lr$i lrp-lr$i-ts1 aa:aa:aa:aa:aa:0$i 2001:db8:1::$i/64
+ovn-nbctl lsp-add ts1 lsp-ts1-lr$i \
+-- lsp-set-addresses lsp-ts1-lr$i router \
+-- lsp-set-type lsp-ts1-lr$i router \
+-- lsp-set-options lsp-ts1-lr$i router-port=lrp-lr$i-ts1
+
+ovn-nbctl lrp-add lr$i lrp-lr$i-p$i 00:00:00:00:00:0$i 2002:db8:1::$i/64
+
+# Create blacklisted LRPs and connect to TS
+ovn-nbctl lrp-add lr$i lrp-lr$i-p-ext$i \
+11:11:11:11:11:1$i 2003:db8:1::$i/64
+
+ovn-nbctl lrp-add lr$i lrp-lr$i-p-ext2$i \
+22:22:22:22:22:2$i 2004::bbb::$i/48
+
+# filtered by 2005:1234::/21 - (2005:1000: - 2005:17ff:)
+ovn-nbctl lrp-add lr$i lrp-lr$i-p-ext3$i \
+33:33:33:33:33:3$i 2005:1734:5678::$i/50
+
+# additional not filtered prefix -> different subnet bits
+ovn-nbctl lrp-add lr$i lrp-lr$i-p-ext4$i \
+33:33:33:33:33:3$i 2005:1834:5678::$i/50
+
+done
+
+for i in 1 2; do
+OVS_WAIT_UNTIL([ovn_as az$i ovn-nbctl lr-route-list lr$i | grep learned])
+done
+
+AT_CHECK([ovn_as az1 ovn-nbctl lr-route-list lr1 |
+awk '/learned/{print $1, $2}' ], [0], [dnl
+2002:db8:1::/64 2001:db8:1::2
+2005:1834:5678::/50 2001:db8:1::2
+])
+
+for i in 1 2; do
+ovn_as az$i
+
+# Drop blacklist
+ovn-nbctl remove nb_global . options ic-route-blacklist
+
+done
+
+OVS_WAIT_FOR_OUTPUT([ovn_as az1 ovn-nbctl lr-route-list lr1 |
+awk '/learned/{print $1, $2}' | sort ], [0], [dnl
+2002:db8:1::/64 2001:db8:1::2
+2003:db8:1::/64 2001:db8:1::2
+2004::bbb::/48 2001:db8:1::2
+2005:1734:5678::/50 2001:db8:1::2
+2005:1834:5678::/50 2001:db8:1::2
+])
+
+for i in 1 2; do
+ovn_as az$i
+
+ovn-nbctl set nb_global . \
+options:ic-route-blacklist="2003:db8:1::/64,2004:db8:1::/64"
+
+# Create an 'extra' blacklisted LRP and connect to TS
+ovn-nbctl lrp-add lr$i lrp-lr$i-p-ext2$i \
+44:44:44:44:44:4$i 2004:db8:1::$i/64
+
+done
+
+OVS_WAIT_FOR_OUTPUT([ovn_as az1 ovn-nbctl lr-route-list lr1 |
+awk '/learned/{print $1, $2}' | sort ], [0], [dnl
+2002:db8:1::/64 2001:db8:1::2
+2004::bbb::/48 2001:db8:1::2
+2005:1734:5678::/50 2001:db8:1::2

[ovs-dev] [PATCH ovn] ovn-ic: fix global blacklist filter for IPv6 addresses

[Roberto Bartzen Acosta via dev]

This commit fixes the prefix filter function as the return condition for IPv6 
addresses is disabling the advertisement of all learned prefixes regardless of 
the match with the blacklist or not.

Reported-at: https://bugs.launchpad.net/ubuntu/+source/ovn/+bug/2046804
Fixes: 57b347c55168 ("ovn-ic: Route advertisement.")
---
 ic/ovn-ic.c | 22 
 tests/ovn-ic.at | 92 +
 2 files changed, 108 insertions(+), 6 deletions(-)

diff --git a/ic/ovn-ic.c b/ic/ovn-ic.c
index 6f8f5734d..d8e038801 100644
--- a/ic/ovn-ic.c
+++ b/ic/ovn-ic.c
@@ -1024,6 +1024,20 @@ prefix_is_link_local(struct in6_addr *prefix, unsigned 
int plen)
 ((prefix->s6_addr[1] & 0xc0) == 0x80));
 }
 
+static bool
+compare_ipv6_prefixes(const struct in6_addr *s_prefix,
+  const struct in6_addr *d_prefix2, int plen)
+{
+struct in6_addr mask = ipv6_create_mask(plen);
+for (int i = 0; i < (plen/8); i++) {
+if ((s_prefix->s6_addr[i] & mask.s6_addr[i]) ^
+(d_prefix2->s6_addr[i] & mask.s6_addr[i])) {
+return false;
+}
+}
+return true;
+}
+
 static bool
 prefix_is_black_listed(const struct smap *nb_options,
struct in6_addr *prefix,
@@ -1064,12 +1078,8 @@ prefix_is_black_listed(const struct smap *nb_options,
 continue;
 }
 } else {
-struct in6_addr mask = ipv6_create_mask(bl_plen);
-for (int i = 0; i < 16 && mask.s6_addr[i] != 0; i++) {
-if ((prefix->s6_addr[i] & mask.s6_addr[i])
-!= (bl_prefix.s6_addr[i] & mask.s6_addr[i])) {
-continue;
-}
+if (!compare_ipv6_prefixes(prefix, _prefix, bl_plen)) {
+continue;
 }
 }
 matched = true;
diff --git a/tests/ovn-ic.at b/tests/ovn-ic.at
index d4c436f84..42ab89aef 100644
--- a/tests/ovn-ic.at
+++ b/tests/ovn-ic.at
@@ -1274,3 +1274,95 @@ OVN_CLEANUP_IC([az1], [az2])
 
 AT_CLEANUP
 ])
+
+OVN_FOR_EACH_NORTHD([
+AT_SETUP([ovn-ic -- route sync -- IPv6 blacklist filter])
+AT_KEYWORDS([IPv6-route-sync-blacklist])
+
+ovn_init_ic_db
+ovn-ic-nbctl ts-add ts1
+
+for i in 1 2; do
+ovn_start az$i
+ovn_as az$i
+
+# Enable route learning at AZ level
+ovn-nbctl set nb_global . options:ic-route-learn=true
+# Enable route advertising at AZ level
+ovn-nbctl set nb_global . options:ic-route-adv=true
+# Enable blacklist single filter for IPv6
+ovn-nbctl set nb_global . options:ic-route-blacklist="2003:db8:1::/64,\
+2004:::/32,2005:1234:5678::/40"
+
+OVS_WAIT_UNTIL([ovn-nbctl show | grep ts1])
+
+# Create LRP and connect to TS
+ovn-nbctl lr-add lr$i
+ovn-nbctl lrp-add lr$i lrp-lr$i-ts1 aa:aa:aa:aa:aa:0$i 2001:db8:1::$i/64
+ovn-nbctl lsp-add ts1 lsp-ts1-lr$i \
+-- lsp-set-addresses lsp-ts1-lr$i router \
+-- lsp-set-type lsp-ts1-lr$i router \
+-- lsp-set-options lsp-ts1-lr$i router-port=lrp-lr$i-ts1
+
+ovn-nbctl lrp-add lr$i lrp-lr$i-p$i 00:00:00:00:00:0$i 2002:db8:1::$i/64
+
+# Create blacklisted LRPs and connect to TS
+ovn-nbctl lrp-add lr$i lrp-lr$i-p-ext$i \
+11:11:11:11:11:1$i 2003:db8:1::$i/64
+
+ovn-nbctl lrp-add lr$i lrp-lr$i-p-ext2$i \
+22:22:22:22:22:2$i 2004::bbb::$i/48
+
+ovn-nbctl lrp-add lr$i lrp-lr$i-p-ext3$i \
+33:33:33:33:33:3$i 2005:1234:5678::$i/50
+
+done
+
+for i in 1 2; do
+OVS_WAIT_UNTIL([ovn_as az$i ovn-nbctl lr-route-list lr$i | grep learned])
+done
+
+AT_CHECK([ovn_as az1 ovn-nbctl lr-route-list lr1 |
+awk '/learned/{print $1, $2}' ], [0], [dnl
+2002:db8:1::/64 2001:db8:1::2
+])
+
+for i in 1 2; do
+ovn_as az$i
+
+# Drop blacklist
+ovn-nbctl remove nb_global . options ic-route-blacklist
+
+done
+
+OVS_WAIT_FOR_OUTPUT([ovn_as az1 ovn-nbctl lr-route-list lr1 |
+awk '/learned/{print $1, $2}' | sort ], [0], [dnl
+2002:db8:1::/64 2001:db8:1::2
+2003:db8:1::/64 2001:db8:1::2
+2004::bbb::/48 2001:db8:1::2
+2005:1234:5678::/50 2001:db8:1::2
+])
+
+for i in 1 2; do
+ovn_as az$i
+
+ovn-nbctl set nb_global . \
+options:ic-route-blacklist="2003:db8:1::/64,2004:db8:1::/64"
+
+# Create an 'extra' blacklisted LRP and connect to TS
+ovn-nbctl lrp-add lr$i lrp-lr$i-p-ext2$i \
+44:44:44:44:44:4$i 2004:db8:1::$i/64
+
+done
+
+OVS_WAIT_FOR_OUTPUT([ovn_as az1 ovn-nbctl lr-route-list lr1 |
+awk '/learned/{print $1, $2}' | sort ], [0], [dnl
+2002:db8:1::/64 2001:db8:1::2
+2004::bbb::/48 2001:db8:1::2
+2005:1234:5678::/50 2001:db8:1::2
+])
+
+OVN_CLEANUP_IC([az1], [az2])
+
+AT_CLEANUP
+])
-- 
2.25.1


-- 




_'Esta mensagem é direcionada apenas para os endereços constantes no 
cabeçalho inicial. Se você não está listado nos endereços constantes no 
cabeçalho, pedimos-lhe que desconsidere completamente o conteúdo dessa 
mensagem e cuja 

[ovs-dev] [PATCH ovs v2] Documentation: Adding note about using the jemalloc library.

[Roberto Bartzen Acosta via dev]

Updating the reference documentation with the inclusion of possible building 
problems with libjemalloc and solution suggestions.

Reported-at: https://bugs.launchpad.net/ubuntu/+source/openvswitch/+bug/2015748
Signed-off-by: Roberto Bartzen Acosta 
---
 Documentation/intro/install/general.rst | 16 
 1 file changed, 16 insertions(+)

diff --git a/Documentation/intro/install/general.rst 
b/Documentation/intro/install/general.rst
index 19e360d47..e2eb19510 100644
--- a/Documentation/intro/install/general.rst
+++ b/Documentation/intro/install/general.rst
@@ -344,6 +344,22 @@ you wish to link with jemalloc add it to LIBS::
 
 $ ./configure LIBS=-ljemalloc
 
+.. note::
+  Linking Open vSwitch with the jemalloc shared library may not work as
+  expected in certain operating system development environments. You can
+  override the automatic compiler decision to avoid possible linker issues by
+  passing ``-fno-lto`` or disabling ``-fno-builtin`` flag since the jemalloc
+  override standard built-in memory allocation functions such as malloc,
+  calloc, etc. Both options can solve possible jemalloc linker issues with pros
+  and cons for each case, feel free to choose the path that appears best to
+  you. Disabling LTO flag example::
+
+  $ ./configure LIBS=-ljemalloc CFLAGS=-fno-lto
+
+  Disabling built-in flag example::
+
+  ./configure LIBS=-ljemalloc CFLAGS=-fno-builtin
+
 .. _general-building:
 
 Building
-- 
2.25.1


-- 




_'Esta mensagem é direcionada apenas para os endereços constantes no 
cabeçalho inicial. Se você não está listado nos endereços constantes no 
cabeçalho, pedimos-lhe que desconsidere completamente o conteúdo dessa 
mensagem e cuja cópia, encaminhamento e/ou execução das ações citadas estão 
imediatamente anuladas e proibidas'._


* **'Apesar do Magazine Luiza tomar 
todas as precauções razoáveis para assegurar que nenhum vírus esteja 
presente nesse e-mail, a empresa não poderá aceitar a responsabilidade por 
quaisquer perdas ou danos causados por esse e-mail ou por seus anexos'.*



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

Re: [ovs-dev] [PATCH ovs] Documentation: Adding note about using the jemalloc library.

[Roberto Bartzen Acosta via dev]

Em sex., 26 de jan. de 2024 às 16:55, Frode Nordahl <
frode.nord...@canonical.com> escreveu:

> Thanks for raising the patch towards the documentation, Roberto!
>
> On Fri, Jan 26, 2024 at 5:57 PM Roberto Bartzen Acosta via dev
>  wrote:
> >
> > Current version of debian/rules simply uses the default GCC optimization
> settings during the linkage process.
> >
> > The main problem with this approach is that GCC on OS like Ubuntu Jammy,
> for example, can enable the -flto=auto flag option during the Open vSwitch
> building and linking process. In this case, the linked dynamic libraries
> would need to be compatible with the same lto optimization options, at the
> risk of not working, according to documentation [1]. However, it could be
> possible to link to jemalloc using the LTO option but the GIMPLE-bytecode
> may not work correctly. In this case, it would be necessary to disable the
> -fbuiltin flag [2] if it is set as default.
>
> As we started to discuss in the other review, I'm not entirely
> convinced that the mechanics of LTO is directly involved in the
> linkers omission to register the jemalloc shared library as a
> dependency. It might as well be a compiler or linker bug related to
> compiler built-ins that is revealed when LTO is enabled?
>

Yes, that would be a possible theory for this problem. So, without LTO
enabled I don't see a problem with build-ins when linking with jemalloc.


> We could of course spend weeks getting to the bottom of that, or we
> could tone that part of the commit message and in-line note down and
> provide a more generic observation based guidance, unless you are
> certain about the correlation?
>

It seems reasonable to me but I think about keeping the in-line note about
the two examples that can solve the problem. I mean, referencing disabling
LTO or built-in flags.
.. note:: Linking Open vSwitch with the jemalloc shared library may not
work as expected in certain operating system development environments. You
can override the automatic compiler decision to avoid possible linker
issues by passing ``-fno-lto`` or disabling ``-fno-builtin`` flag since the
jemalloc overrides standard built-in memory allocation functions such as
malloc, calloc, etc. Both options can solve possible jemalloc linker issues
with pros and cons for each case, feel free to choose the path that appears
best to you. Disabling LTO flag example::
 $ ./configure LIBS=-ljemalloc CFLAGS=-fno-lto
 Disabling built-in flag example::
 ./configure LIBS=-ljemalloc CFLAGS=-fno-builtin

Do you think this would be good?

Thanks


>
> --
> Frode Nordahl
>
> >
> > Updating the reference documentation with the inclusion of possible
> building problems with libjemalloc and solution suggestions.
> >
> > [1] https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html#index-flto
> > [2] https://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html
> >
> > Reported-at:
> https://bugs.launchpad.net/ubuntu/+source/openvswitch/+bug/2015748
> > Signed-off-by: Roberto Bartzen Acosta 
> > ---
> >  Documentation/intro/install/general.rst | 17 +
> >  1 file changed, 17 insertions(+)
> >
> > diff --git a/Documentation/intro/install/general.rst
> b/Documentation/intro/install/general.rst
> > index 19e360d47..ef4e6181d 100644
> > --- a/Documentation/intro/install/general.rst
> > +++ b/Documentation/intro/install/general.rst
> > @@ -344,6 +344,23 @@ you wish to link with jemalloc add it to LIBS::
> >
> >  $ ./configure LIBS=-ljemalloc
> >
> > +.. note::
> > +  Linking Open vSwitch with the jemalloc shared library may not work as
> > +  expected in certain operating system development environments if the
> GCC
> > +  compiler tries to optimize the linking process using the ``-flto``
> flag.
> > +  You can overrides the automatic compiler decision removing the
> link-time
> > +  optimization by passing ``-fno-lto`` or disabling ``-fno-builtin``
> flag since
> > +  the jemalloc override standard built-in memory allocation functions
> such as
> > +  malloc, calloc, etc. Both options can solve possible jemalloc linker
> issues
> > +  with pros and cons for each case, feel free to choose the path that
> appears
> > +  best to you. Disabling LTO flag example::
> > +
> > +  $ ./configure LIBS=-ljemalloc CFLAGS=-fno-lto
> > +
> > +  Disabling built-in flag example::
> > +
> > +  ./configure LIBS=-ljemalloc CFLAGS=-fno-builtin
> > +
> >  .. _general-building:
> >
> >  Building
> > --
> > 2.25.1
> >
> >
> > --
> >
> >
> >
> >
> > _'Esta mensagem é direcionada apenas para os endereços co

[ovs-dev] [PATCH ovs] Documentation: Adding note about using the jemalloc library.

[Roberto Bartzen Acosta via dev]

Current version of debian/rules simply uses the default GCC optimization 
settings during the linkage process.

The main problem with this approach is that GCC on OS like Ubuntu Jammy, for 
example, can enable the -flto=auto flag option during the Open vSwitch building 
and linking process. In this case, the linked dynamic libraries would need to 
be compatible with the same lto optimization options, at the risk of not 
working, according to documentation [1]. However, it could be possible to link 
to jemalloc using the LTO option but the GIMPLE-bytecode may not work 
correctly. In this case, it would be necessary to disable the -fbuiltin flag 
[2] if it is set as default.

Updating the reference documentation with the inclusion of possible building 
problems with libjemalloc and solution suggestions.

[1] https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html#index-flto
[2] https://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html

Reported-at: https://bugs.launchpad.net/ubuntu/+source/openvswitch/+bug/2015748
Signed-off-by: Roberto Bartzen Acosta 
---
 Documentation/intro/install/general.rst | 17 +
 1 file changed, 17 insertions(+)

diff --git a/Documentation/intro/install/general.rst 
b/Documentation/intro/install/general.rst
index 19e360d47..ef4e6181d 100644
--- a/Documentation/intro/install/general.rst
+++ b/Documentation/intro/install/general.rst
@@ -344,6 +344,23 @@ you wish to link with jemalloc add it to LIBS::
 
 $ ./configure LIBS=-ljemalloc
 
+.. note::
+  Linking Open vSwitch with the jemalloc shared library may not work as
+  expected in certain operating system development environments if the GCC
+  compiler tries to optimize the linking process using the ``-flto`` flag.
+  You can overrides the automatic compiler decision removing the link-time
+  optimization by passing ``-fno-lto`` or disabling ``-fno-builtin`` flag since
+  the jemalloc override standard built-in memory allocation functions such as
+  malloc, calloc, etc. Both options can solve possible jemalloc linker issues
+  with pros and cons for each case, feel free to choose the path that appears
+  best to you. Disabling LTO flag example::
+
+  $ ./configure LIBS=-ljemalloc CFLAGS=-fno-lto
+
+  Disabling built-in flag example::
+
+  ./configure LIBS=-ljemalloc CFLAGS=-fno-builtin
+
 .. _general-building:
 
 Building
-- 
2.25.1


-- 




_'Esta mensagem é direcionada apenas para os endereços constantes no 
cabeçalho inicial. Se você não está listado nos endereços constantes no 
cabeçalho, pedimos-lhe que desconsidere completamente o conteúdo dessa 
mensagem e cuja cópia, encaminhamento e/ou execução das ações citadas estão 
imediatamente anuladas e proibidas'._


* **'Apesar do Magazine Luiza tomar 
todas as precauções razoáveis para assegurar que nenhum vírus esteja 
presente nesse e-mail, a empresa não poderá aceitar a responsabilidade por 
quaisquer perdas ou danos causados por esse e-mail ou por seus anexos'.*



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

[ovs-dev] [PATCH ovs] Documentation: Adding note about using the jemalloc library.

[Roberto Bartzen Acosta via dev]

Current version of debian/rules simply uses the default GCC optimization 
settings during the linkage process.

The main problem with this approach is that GCC on OS like Ubuntu Jammy, for 
example, can enable the -flto=auto flag option during the Open vSwitch building 
and linking process. In this case, the linked dynamic libraries would need to 
be compatible with the same lto optimization options, at the risk of not 
working, according to documentation [1]. However, it could be possible to link 
to jemalloc using the LTO option but the GIMPLE-bytecode may not work 
correctly. In this case, it would be necessary to disable the -fbuiltin flag 
[2] if it is set as default.

Updating the reference documentation with the inclusion of possible building 
problems with libjemalloc and solution suggestions.

[1] https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html#index-flto
[2] https://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html

Signed-off-by: Roberto Bartzen Acosta 
---
 Documentation/intro/install/general.rst | 17 +
 1 file changed, 17 insertions(+)

diff --git a/Documentation/intro/install/general.rst 
b/Documentation/intro/install/general.rst
index 19e360d47..ef4e6181d 100644
--- a/Documentation/intro/install/general.rst
+++ b/Documentation/intro/install/general.rst
@@ -344,6 +344,23 @@ you wish to link with jemalloc add it to LIBS::
 
 $ ./configure LIBS=-ljemalloc
 
+.. note::
+  Linking Open vSwitch with the jemalloc shared library may not work as
+  expected in certain operating system development environments if the GCC
+  compiler tries to optimize the linking process using the ``-flto`` flag.
+  You can overrides the automatic compiler decision removing the link-time
+  optimization by passing ``-fno-lto`` or disabling ``-fno-builtin`` flag since
+  the jemalloc override standard built-in memory allocation functions such as
+  malloc, calloc, etc. Both options can solve possible jemalloc linker issues
+  with pros and cons for each case, feel free to choose the path that appears
+  best to you. Disabling LTO flag example::
+
+  $ ./configure LIBS=-ljemalloc CFLAGS=-fno-lto
+
+  Disabling built-in flag example::
+
+  ./configure LIBS=-ljemalloc CFLAGS=-fno-builtin
+
 .. _general-building:
 
 Building
-- 
2.25.1


-- 




_'Esta mensagem é direcionada apenas para os endereços constantes no 
cabeçalho inicial. Se você não está listado nos endereços constantes no 
cabeçalho, pedimos-lhe que desconsidere completamente o conteúdo dessa 
mensagem e cuja cópia, encaminhamento e/ou execução das ações citadas estão 
imediatamente anuladas e proibidas'._


* **'Apesar do Magazine Luiza tomar 
todas as precauções razoáveis para assegurar que nenhum vírus esteja 
presente nesse e-mail, a empresa não poderá aceitar a responsabilidade por 
quaisquer perdas ou danos causados por esse e-mail ou por seus anexos'.*



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

Re: [ovs-dev] [PATCH ovs v3] debian/rules: Fix incorrect use of link-time optimizer.

[Roberto Bartzen Acosta via dev]

Em sex., 26 de jan. de 2024 às 09:21, Frode Nordahl <
frode.nord...@canonical.com> escreveu:

>
>
> fre. 26. jan. 2024, 13:03 skrev Roberto Bartzen Acosta <
> roberto.aco...@luizalabs.com>:
>
>>
>>
>> Em sex., 26 de jan. de 2024 às 04:37, Frode Nordahl <
>> frode.nord...@canonical.com> escreveu:
>>
>>> On Thu, Jan 25, 2024 at 10:44 PM Frode Nordahl
>>>  wrote:
>>> >
>>> >
>>> >
>>> > tor. 25. jan. 2024, 22:32 skrev Roberto Bartzen Acosta <
>>> roberto.aco...@luizalabs.com>:
>>> >>
>>> >>
>>> >>
>>> >> Em qui., 25 de jan. de 2024 às 17:01, Frode Nordahl <
>>> frode.nord...@canonical.com> escreveu:
>>> >>>
>>> >>> Apologies for the tardy response to this thread, freeze deadlines and
>>> >>> PTO has prevented me from responding sooner.
>>> >>>
>>> >>> On Mon, Jan 15, 2024 at 12:14 PM Roberto Bartzen Acosta
>>> >>>  wrote:
>>> >>> >
>>> >>> >
>>> >>> >
>>> >>> > Em qua., 10 de jan. de 2024 às 15:37, Ilya Maximets <
>>> i.maxim...@redhat.com> escreveu:
>>> >>> > >
>>> >>> > > On 1/9/24 13:53, Simon Horman wrote:
>>> >>> > > > On Mon, Jan 08, 2024 at 08:34:36AM -0300, Roberto Bartzen
>>> Acosta via dev wrote:
>>> >>> > > >> Current version of debian/rules simply uses the default lto
>>> GCC
>>> >>> > > >> optimization settings during the linkage process.
>>> >>> > > >>
>>> >>> > > >> The main problem with this approach is that GCC on OS like
>>> Ubuntu
>>> >>> > > >> Jammy, for example, can enable the -flto=auto option during
>>> the
>>> >>> > > >> openvswitch building and linking process. In this case, the
>>> linked
>>> >>> > > >> dynamic libraries would need to be builded based on the same
>>> lto
>>> >>> > > >> optimization options, at the risk of not working, according to
>>> >>> > > >> documentation [1].
>>> >>>
>>> >>> The documentation also says:
>>> >>> "When producing the final binary, GCC only applies link-time
>>> >>> optimizations to those files that contain bytecode. Therefore, you
>>> can
>>> >>> mix and match object files and libraries with GIMPLE bytecodes and
>>> >>> final object code. GCC automatically selects which files to optimize
>>> >>> in LTO mode and which files to link without further processing."
>>> >>>
>>> >>> Which to me reads like it is supported to mix LTO optimized and
>>> >>> non-optimized objects?
>>> >>
>>> >>
>>> >> Yeah, that makes sense but another important doc reference is "The
>>> important thing to keep in mind is that to enable link-time optimizations
>>> you need to use the GCC driver to perform the link step. GCC automatically
>>> performs link-time optimization if any of the objects involved were
>>> compiled with the -flto command-line option." . So, my assumption is that
>>> LTO was automatically enabled because some of the objects involved in
>>> compiling with the jammy dev environment support it.
>>> >>
>>> >> In that case, the LTO documentation suggests that we always used
>>> -flto with some optimization flag (e.g. -O2) both at compile time and at
>>> link time. So, AFAIU, you should link the code using exactly the same
>>> optimization flags used at compile time, and the statement about
>>> "automatically selects which files to optimize in LTO" is correct as long
>>> as it is possible to read the GIMPLE bytecode of the objects involved for
>>> the optimization option passed (in our case: jemalloc).  As detailed in the
>>> doc, the idea of -flto is to inject in the object files some internal
>>> (GIMPLE-bytecode) representation of the source code, and that is also used
>>> at link time because, for optimization steps, the inlining bytecode happens
>>> again when linking your whole program. The libjemalloc has its own
>>> headers/inline (or inlinable) functions that also need to use LTO wit

Re: [ovs-dev] [PATCH ovs v3] debian/rules: Fix incorrect use of link-time optimizer.

[Roberto Bartzen Acosta via dev]

Em sex., 26 de jan. de 2024 às 04:37, Frode Nordahl <
frode.nord...@canonical.com> escreveu:

> On Thu, Jan 25, 2024 at 10:44 PM Frode Nordahl
>  wrote:
> >
> >
> >
> > tor. 25. jan. 2024, 22:32 skrev Roberto Bartzen Acosta <
> roberto.aco...@luizalabs.com>:
> >>
> >>
> >>
> >> Em qui., 25 de jan. de 2024 às 17:01, Frode Nordahl <
> frode.nord...@canonical.com> escreveu:
> >>>
> >>> Apologies for the tardy response to this thread, freeze deadlines and
> >>> PTO has prevented me from responding sooner.
> >>>
> >>> On Mon, Jan 15, 2024 at 12:14 PM Roberto Bartzen Acosta
> >>>  wrote:
> >>> >
> >>> >
> >>> >
> >>> > Em qua., 10 de jan. de 2024 às 15:37, Ilya Maximets <
> i.maxim...@redhat.com> escreveu:
> >>> > >
> >>> > > On 1/9/24 13:53, Simon Horman wrote:
> >>> > > > On Mon, Jan 08, 2024 at 08:34:36AM -0300, Roberto Bartzen Acosta
> via dev wrote:
> >>> > > >> Current version of debian/rules simply uses the default lto GCC
> >>> > > >> optimization settings during the linkage process.
> >>> > > >>
> >>> > > >> The main problem with this approach is that GCC on OS like
> Ubuntu
> >>> > > >> Jammy, for example, can enable the -flto=auto option during the
> >>> > > >> openvswitch building and linking process. In this case, the
> linked
> >>> > > >> dynamic libraries would need to be builded based on the same lto
> >>> > > >> optimization options, at the risk of not working, according to
> >>> > > >> documentation [1].
> >>>
> >>> The documentation also says:
> >>> "When producing the final binary, GCC only applies link-time
> >>> optimizations to those files that contain bytecode. Therefore, you can
> >>> mix and match object files and libraries with GIMPLE bytecodes and
> >>> final object code. GCC automatically selects which files to optimize
> >>> in LTO mode and which files to link without further processing."
> >>>
> >>> Which to me reads like it is supported to mix LTO optimized and
> >>> non-optimized objects?
> >>
> >>
> >> Yeah, that makes sense but another important doc reference is "The
> important thing to keep in mind is that to enable link-time optimizations
> you need to use the GCC driver to perform the link step. GCC automatically
> performs link-time optimization if any of the objects involved were
> compiled with the -flto command-line option." . So, my assumption is that
> LTO was automatically enabled because some of the objects involved in
> compiling with the jammy dev environment support it.
> >>
> >> In that case, the LTO documentation suggests that we always used -flto
> with some optimization flag (e.g. -O2) both at compile time and at link
> time. So, AFAIU, you should link the code using exactly the same
> optimization flags used at compile time, and the statement about
> "automatically selects which files to optimize in LTO" is correct as long
> as it is possible to read the GIMPLE bytecode of the objects involved for
> the optimization option passed (in our case: jemalloc).  As detailed in the
> doc, the idea of -flto is to inject in the object files some internal
> (GIMPLE-bytecode) representation of the source code, and that is also used
> at link time because, for optimization steps, the inlining bytecode happens
> again when linking your whole program. The libjemalloc has its own
> headers/inline (or inlinable) functions that also need to use LTO with some
> optimization option (e.g. -O2) when compiling that library from its source
> code (and in that case its GIMPLE bytecode is stored in the library).
> >>
> >> In summary, my assumption is that, probably, libjemalloc installed on
> OS didn't generate the GIMPLE bytecode properly to be used in the complete
> build and linking process with the optimization option passed by
> openvswitch. In other words, the issue seems to be with the jemalloc lib in
> the OS Jammy.
> >
> >
> > If that is the case, should we not fix the jemalloc build instead?
> >
> >> So, why am I making a possible change to remove the LTO flag from the
> openvswitch build process?  because the linkage process is susceptible to
> OS-GCC decisions that can generate incoherent results in some cases.
> >>
> >>>
> 

Re: [ovs-dev] [PATCH ovs v3] debian/rules: Fix incorrect use of link-time optimizer.

[Roberto Bartzen Acosta via dev]

Em qui., 25 de jan. de 2024 às 18:45, Frode Nordahl <
frode.nord...@canonical.com> escreveu:

>
>
> tor. 25. jan. 2024, 22:32 skrev Roberto Bartzen Acosta <
> roberto.aco...@luizalabs.com>:
>
>>
>>
>> Em qui., 25 de jan. de 2024 às 17:01, Frode Nordahl <
>> frode.nord...@canonical.com> escreveu:
>>
>>> Apologies for the tardy response to this thread, freeze deadlines and
>>> PTO has prevented me from responding sooner.
>>>
>>> On Mon, Jan 15, 2024 at 12:14 PM Roberto Bartzen Acosta
>>>  wrote:
>>> >
>>> >
>>> >
>>> > Em qua., 10 de jan. de 2024 às 15:37, Ilya Maximets <
>>> i.maxim...@redhat.com> escreveu:
>>> > >
>>> > > On 1/9/24 13:53, Simon Horman wrote:
>>> > > > On Mon, Jan 08, 2024 at 08:34:36AM -0300, Roberto Bartzen Acosta
>>> via dev wrote:
>>> > > >> Current version of debian/rules simply uses the default lto GCC
>>> > > >> optimization settings during the linkage process.
>>> > > >>
>>> > > >> The main problem with this approach is that GCC on OS like Ubuntu
>>> > > >> Jammy, for example, can enable the -flto=auto option during the
>>> > > >> openvswitch building and linking process. In this case, the linked
>>> > > >> dynamic libraries would need to be builded based on the same lto
>>> > > >> optimization options, at the risk of not working, according to
>>> > > >> documentation [1].
>>>
>>> The documentation also says:
>>> "When producing the final binary, GCC only applies link-time
>>> optimizations to those files that contain bytecode. Therefore, you can
>>> mix and match object files and libraries with GIMPLE bytecodes and
>>> final object code. GCC automatically selects which files to optimize
>>> in LTO mode and which files to link without further processing."
>>>
>>> Which to me reads like it is supported to mix LTO optimized and
>>> non-optimized objects?
>>>
>>
>> Yeah, that makes sense but another important doc reference is "The
>> important thing to keep in mind is that to enable link-time optimizations
>> you need to use the GCC driver to perform the link step. GCC automatically
>> performs link-time optimization if any of the objects involved were
>> compiled with the -flto command-line option." . So, my assumption is that
>> LTO was automatically enabled because some of the objects involved in
>> compiling with the jammy dev environment support it.
>>
>> In that case, the LTO documentation suggests that we always used -flto with
>> some optimization flag (e.g. -O2) both at compile time and at link time.
>> So, AFAIU, you should link the code using exactly the same optimization
>> flags used at compile time, and the statement about "automatically selects
>> which files to optimize in LTO" is correct as long as it is possible to
>> read the GIMPLE bytecode of the objects involved for the optimization
>> option passed (in our case: jemalloc).  As detailed in the doc, the idea of
>> -flto is to inject in the object files some internal (GIMPLE-bytecode)
>> representation of the source code, and that is also used at link time
>> because, for optimization steps, the inlining bytecode happens again when
>> linking your whole program. The libjemalloc has its own headers/inline (or
>> inlinable) functions that also need to use LTO with some optimization
>> option (e.g. -O2) when compiling that library from its source code (and in
>> that case its GIMPLE bytecode is stored in the library).
>>
>> In summary, my assumption is that, probably, libjemalloc installed on OS
>> didn't generate the GIMPLE bytecode properly to be used in the complete
>> build and linking process with the optimization option passed by
>> openvswitch. In other words, the issue seems to be with the jemalloc lib in
>> the OS Jammy.
>>
>
> If that is the case, should we not fix the jemalloc build instead?
>

Of course, It would be a good approach! maybe you could let the internal
Canonical SEG OS team know about this.


> So, why am I making a possible change to remove the LTO flag from the
>> openvswitch build process?  because the linkage process is susceptible to
>> OS-GCC decisions that can generate incoherent results in some cases.
>>
>>
>>>
>>> > > >>
>>> > > >> I'm not sure of the real benefits of using this link-tim

Re: [ovs-dev] [PATCH ovs v3] debian/rules: Fix incorrect use of link-time optimizer.

[Roberto Bartzen Acosta via dev]

Em qui., 25 de jan. de 2024 às 17:01, Frode Nordahl <
frode.nord...@canonical.com> escreveu:

> Apologies for the tardy response to this thread, freeze deadlines and
> PTO has prevented me from responding sooner.
>
> On Mon, Jan 15, 2024 at 12:14 PM Roberto Bartzen Acosta
>  wrote:
> >
> >
> >
> > Em qua., 10 de jan. de 2024 às 15:37, Ilya Maximets <
> i.maxim...@redhat.com> escreveu:
> > >
> > > On 1/9/24 13:53, Simon Horman wrote:
> > > > On Mon, Jan 08, 2024 at 08:34:36AM -0300, Roberto Bartzen Acosta via
> dev wrote:
> > > >> Current version of debian/rules simply uses the default lto GCC
> > > >> optimization settings during the linkage process.
> > > >>
> > > >> The main problem with this approach is that GCC on OS like Ubuntu
> > > >> Jammy, for example, can enable the -flto=auto option during the
> > > >> openvswitch building and linking process. In this case, the linked
> > > >> dynamic libraries would need to be builded based on the same lto
> > > >> optimization options, at the risk of not working, according to
> > > >> documentation [1].
>
> The documentation also says:
> "When producing the final binary, GCC only applies link-time
> optimizations to those files that contain bytecode. Therefore, you can
> mix and match object files and libraries with GIMPLE bytecodes and
> final object code. GCC automatically selects which files to optimize
> in LTO mode and which files to link without further processing."
>
> Which to me reads like it is supported to mix LTO optimized and
> non-optimized objects?
>

Yeah, that makes sense but another important doc reference is "The
important thing to keep in mind is that to enable link-time optimizations
you need to use the GCC driver to perform the link step. GCC automatically
performs link-time optimization if any of the objects involved were
compiled with the -flto command-line option." . So, my assumption is that
LTO was automatically enabled because some of the objects involved in
compiling with the jammy dev environment support it.

In that case, the LTO documentation suggests that we always used -flto with
some optimization flag (e.g. -O2) both at compile time and at link time.
So, AFAIU, you should link the code using exactly the same optimization
flags used at compile time, and the statement about "automatically selects
which files to optimize in LTO" is correct as long as it is possible to
read the GIMPLE bytecode of the objects involved for the optimization
option passed (in our case: jemalloc).  As detailed in the doc, the idea of
-flto is to inject in the object files some internal (GIMPLE-bytecode)
representation of the source code, and that is also used at link time
because, for optimization steps, the inlining bytecode happens again when
linking your whole program. The libjemalloc has its own headers/inline (or
inlinable) functions that also need to use LTO with some optimization
option (e.g. -O2) when compiling that library from its source code (and in
that case its GIMPLE bytecode is stored in the library).

In summary, my assumption is that, probably, libjemalloc installed on OS
didn't generate the GIMPLE bytecode properly to be used in the complete
build and linking process with the optimization option passed by
openvswitch. In other words, the issue seems to be with the jemalloc lib in
the OS Jammy.

So, why am I making a possible change to remove the LTO flag from the
openvswitch build process?  because the linkage process is susceptible to
OS-GCC decisions that can generate incoherent results in some cases.


>
> > > >>
> > > >> I'm not sure of the real benefits of using this link-time
> optimization
> > >
> > > At least for DPDK-enabled builds LTO usually provides noticeable
> > > performance improvement.  In the past I measured up to 10% packet
> > > rate increase with LTO.  Though the gap went a bit lower with modern
> > > compilers.  I think, it should still provide noticeable performance
> > > improvements at least for the userspace datapath.
> > >
> > > >> option, and since when it is enabled it causes problems with shared
> > > >> libs link libjemalloc, for example, it seems safer overwritten
> > > >> compiler decision by passing -fno-lto command.
> > >
> > > Building shared libraries with LTO is indeed a bit problematic.
> > > I agree that correctness should have a priority over potential
> > > performance benefits.
> > >
> > > Just out of curiosity, how do you add jemalloc into dependencies?
> > > Using one of the environment variables?
> 

Re: [ovs-dev] [PATCH ovs v3] debian/rules: Fix incorrect use of link-time optimizer.

[Roberto Bartzen Acosta via dev]

Em qua., 10 de jan. de 2024 às 15:37, Ilya Maximets 
escreveu:
>
> On 1/9/24 13:53, Simon Horman wrote:
> > On Mon, Jan 08, 2024 at 08:34:36AM -0300, Roberto Bartzen Acosta via
dev wrote:
> >> Current version of debian/rules simply uses the default lto GCC
> >> optimization settings during the linkage process.
> >>
> >> The main problem with this approach is that GCC on OS like Ubuntu
> >> Jammy, for example, can enable the -flto=auto option during the
> >> openvswitch building and linking process. In this case, the linked
> >> dynamic libraries would need to be builded based on the same lto
> >> optimization options, at the risk of not working, according to
> >> documentation [1].
> >>
> >> I'm not sure of the real benefits of using this link-time optimization
>
> At least for DPDK-enabled builds LTO usually provides noticeable
> performance improvement.  In the past I measured up to 10% packet
> rate increase with LTO.  Though the gap went a bit lower with modern
> compilers.  I think, it should still provide noticeable performance
> improvements at least for the userspace datapath.
>
> >> option, and since when it is enabled it causes problems with shared
> >> libs link libjemalloc, for example, it seems safer overwritten
> >> compiler decision by passing -fno-lto command.
>
> Building shared libraries with LTO is indeed a bit problematic.
> I agree that correctness should have a priority over potential
> performance benefits.
>
> Just out of curiosity, how do you add jemalloc into dependencies?
> Using one of the environment variables?

yeap, I'm just using the standard libs flag on a Ubuntu OS as suggested by
the OpenvSwitch documentation (*LIBS=-ljemalloc* ) [1]

override_dh_auto_configure: test -d _debian || mkdir _debiancd
_debian && ( \  test -e Makefile || \   ../configure 
--prefix=/usr
--localstatedir=/var --enable-ssl LIBS=-ljemalloc \ 

--sysconfdir=/etc \  
$(DATAPATH_CONFIGURE_OPTS) \   
$(EXTRA_CONFIGURE_OPTS) \)


[1] https://docs.openvswitch.org/en/latest/intro/install/general/


>
> >>
> >> [1] https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html#index-flto
> >>
> >> Reported-at:
https://bugs.launchpad.net/ubuntu/+source/openvswitch/+bug/2015748
> >> Signed-off-by: Roberto Bartzen Acosta 
> >
> > Hi,
> >
> > for one reason or another our automation was unable to apply this patch.
> > But I have done so locally in my own tree (it is not upstream)
> > and run the GitHub based tests with success:
> >
> > https://github.com/horms/ovs/actions/runs/7448358289
> >
> > From my point of view this patch seems reasonable.
> >
> > Acked-by: Simon Horman 
> >
> > But I would be interested to hear feedback from others before applying
it
> > to the upstream tree.
>
> @Frode, do you have any thoughts on this change?  Is it a problem
> also for the main (in-distribution) Ubuntu/Debian builds?
>
> >
> >> ---
> >>  debian/rules | 2 +-
> >>  1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/debian/rules b/debian/rules
> >> index dc5cc8a65..de8771813 100755
> >> --- a/debian/rules
> >> +++ b/debian/rules
> >> @@ -2,7 +2,7 @@
> >>  # -*- makefile -*-
> >>  #export DH_VERBOSE=1
> >>  export DEB_BUILD_MAINT_OPTIONS = hardening=+all
> >> -export DEB_CFLAGS_MAINT_APPEND = -fPIC
> >> +export DEB_CFLAGS_MAINT_APPEND = -fPIC -fno-lto
>

-- 




_‘Esta mensagem é direcionada apenas para os endereços constantes no 
cabeçalho inicial. Se você não está listado nos endereços constantes no 
cabeçalho, pedimos-lhe que desconsidere completamente o conteúdo dessa 
mensagem e cuja cópia, encaminhamento e/ou execução das ações citadas estão 
imediatamente anuladas e proibidas’._


* **‘Apesar do Magazine Luiza tomar 
todas as precauções razoáveis para assegurar que nenhum vírus esteja 
presente nesse e-mail, a empresa não poderá aceitar a responsabilidade por 
quaisquer perdas ou danos causados por esse e-mail ou por seus anexos’.*



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

[ovs-dev] [PATCH ovs v3] debian/rules: Fix incorrect use of link-time optimizer.

[Roberto Bartzen Acosta via dev]

Current version of debian/rules simply uses the default lto GCC
optimization settings during the linkage process.

The main problem with this approach is that GCC on OS like Ubuntu
Jammy, for example, can enable the -flto=auto option during the
openvswitch building and linking process. In this case, the linked
dynamic libraries would need to be builded based on the same lto
optimization options, at the risk of not working, according to
documentation [1].

I'm not sure of the real benefits of using this link-time optimization
option, and since when it is enabled it causes problems with shared
libs link libjemalloc, for example, it seems safer overwritten
compiler decision by passing -fno-lto command.

[1] https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html#index-flto

Reported-at: https://bugs.launchpad.net/ubuntu/+source/openvswitch/+bug/2015748
Signed-off-by: Roberto Bartzen Acosta 
---
 debian/rules | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/rules b/debian/rules
index dc5cc8a65..de8771813 100755
--- a/debian/rules
+++ b/debian/rules
@@ -2,7 +2,7 @@
 # -*- makefile -*-
 #export DH_VERBOSE=1
 export DEB_BUILD_MAINT_OPTIONS = hardening=+all
-export DEB_CFLAGS_MAINT_APPEND = -fPIC
+export DEB_CFLAGS_MAINT_APPEND = -fPIC -fno-lto

 %:
  dh $@

-- 




_‘Esta mensagem é direcionada apenas para os endereços constantes no 
cabeçalho inicial. Se você não está listado nos endereços constantes no 
cabeçalho, pedimos-lhe que desconsidere completamente o conteúdo dessa 
mensagem e cuja cópia, encaminhamento e/ou execução das ações citadas estão 
imediatamente anuladas e proibidas’._


* **‘Apesar do Magazine Luiza tomar 
todas as precauções razoáveis para assegurar que nenhum vírus esteja 
presente nesse e-mail, a empresa não poderá aceitar a responsabilidade por 
quaisquer perdas ou danos causados por esse e-mail ou por seus anexos’.*



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

[ovs-dev] [PATCH ovs v2] debian/rules: Fix incorrect use of link-time optimizer.

[Roberto Bartzen Acosta via dev]

Current version of debian/rules simply uses the default lto GCC
optimization settings during the linkage process.

The main problem with this approach is that GCC on OS like Ubuntu Jammy,
for example, can enable the -flto=auto option during the openvswitch
building and linking process. In this case, the linked dynamic libraries
would need to be builded based on the same lto optimization options, at the
risk of not working, according to documentation [1].

I'm not sure of the real benefits of using this link-time optimization
option, and since when it is enabled it causes problems with shared libs
link libjemalloc, for example, it seems safer overwritten compiler decision
by passing -fno-lto command.

[1] https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html#index-flto

Reported-at:
https://bugs.launchpad.net/ubuntu/+source/openvswitch/+bug/2015748
Signed-off-by: Roberto Bartzen Acosta 
---
 debian/rules | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/rules b/debian/rules
index dc5cc8a65..de8771813 100755
--- a/debian/rules
+++ b/debian/rules
@@ -2,7 +2,7 @@
 # -*- makefile -*-
 #export DH_VERBOSE=1
 export DEB_BUILD_MAINT_OPTIONS = hardening=+all
-export DEB_CFLAGS_MAINT_APPEND = -fPIC
+export DEB_CFLAGS_MAINT_APPEND = -fPIC -fno-lto

 %:
dh $@

-- 




_‘Esta mensagem é direcionada apenas para os endereços constantes no 
cabeçalho inicial. Se você não está listado nos endereços constantes no 
cabeçalho, pedimos-lhe que desconsidere completamente o conteúdo dessa 
mensagem e cuja cópia, encaminhamento e/ou execução das ações citadas estão 
imediatamente anuladas e proibidas’._


* **‘Apesar do Magazine Luiza tomar 
todas as precauções razoáveis para assegurar que nenhum vírus esteja 
presente nesse e-mail, a empresa não poderá aceitar a responsabilidade por 
quaisquer perdas ou danos causados por esse e-mail ou por seus anexos’.*



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

[ovs-dev] [PATCH ovs] debian/rules: Fix incorrect use of link-time optimizer.

[Roberto Bartzen Acosta via dev]

Current version of debian/rules simply uses the default lto GCC
optimization settings during the linkage process.

The main problem with this approach is that GCC on OS like Ubuntu Jammy,
for example, can enable the -flto=auto option during the openvswitch
building and linking process. In this case, the linked dynamic libraries
would need to be builded based on the same lto optimization options, at the
risk of not working, according to documentation [1].

I'm not sure of the real benefits of using this link-time optimization
option, and since when it is enabled it causes problems with shared libs
links such as libjemalloc, for example, it seems safer overwritten compiler
decision by passing -fno-lto command.

[1] https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html#index-flto

Reported-at:
https://bugs.launchpad.net/ubuntu/+source/openvswitch/+bug/2015748
Signed-off-by: Roberto Bartzen Acosta 
---
 debian/rules | 2 +-
 1 file changed, 2 insertion(+), 1 deletion(-)

diff --git a/debian/rules b/debian/rules
index dc5cc8a65..de8771813 100755
--- a/debian/rules
+++ b/debian/rules
@@ -2,7 +2,7 @@
 # -*- makefile -*-
 #export DH_VERBOSE=1
 export DEB_BUILD_MAINT_OPTIONS = hardening=+all
-export DEB_CFLAGS_MAINT_APPEND = -fPIC
+export DEB_CFLAGS_MAINT_APPEND = -fPIC -fno-lto

 %:
dh $@

-- 




_‘Esta mensagem é direcionada apenas para os endereços constantes no 
cabeçalho inicial. Se você não está listado nos endereços constantes no 
cabeçalho, pedimos-lhe que desconsidere completamente o conteúdo dessa 
mensagem e cuja cópia, encaminhamento e/ou execução das ações citadas estão 
imediatamente anuladas e proibidas’._


* **‘Apesar do Magazine Luiza tomar 
todas as precauções razoáveis para assegurar que nenhum vírus esteja 
presente nesse e-mail, a empresa não poderá aceitar a responsabilidade por 
quaisquer perdas ou danos causados por esse e-mail ou por seus anexos’.*



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

Re: [ovs-dev] Scale testing OVN with ovn-heater for OpenStack use cases

[Roberto Bartzen Acosta via dev]

I'm interested in attending this meet, Frode. Please include me in the
invite list.

Thanks

Em ter., 4 de jul. de 2023 às 13:06, Numan Siddique 
escreveu:

> On Tue, Jul 4, 2023, 8:00 PM Frode Nordahl 
> wrote:
>
> > On Tue, Jul 4, 2023 at 4:16 PM Dumitru Ceara  wrote:
> > >
> > > On 6/30/23 23:07, Terry Wilson wrote:
> > > > On Fri, Jun 30, 2023 at 2:26 AM Frode Nordahl
> > > >  wrote:
> > > >>
> > > >> Hello all,
> > > >>
> > > >> On Tue, May 30, 2023 at 5:16 PM Felix Huettner
> > > >>  wrote:
> > > >>>
> > > >>> Hi Dumitru,
> > > >>>
> > > >>> On Fri, May 26, 2023 at 01:30:54PM +0200, Dumitru Ceara wrote:
> > >  On 5/24/23 09:37, Felix Huettner wrote:
> > > > Hi everyone,
> > > 
> > >  Hi Felix,
> > > 
> > > >
> > > > Ilya mentioned to me that you will want to bring openstack
> > examples to
> > > > ovn-heater.
> > > >
> > > 
> > >  Yes, we're discussing that.
> > > 
> > > > I wanted to ask how to best join this effort. It would be great
> > for us
> > > 
> > >  Everyone is welcome to contribute! :)
> > > 
> > > >>>
> > > >>> Great, we will try that out.
> > > >>
> > > >> Thank you for your interest in this effort, as promised I'm in the
> > > >> process of organizing a community meeting to get this going.
> > > >>
> > > >> Below are some proposals for dates and times, please respond with a
> > > >> prioritized list of what works best for you and we'll try to land
> on a
> > > >> single date/time for a first meeting:
> > > >> Wednesday July 5th 13:00 UTC
> > > >> Tuesday July 11th 13:30 UTC
> > > >> Wednesday July 12th 8:30 UTC
> > > >
> > > > I'd be interested in attending. Of these, Tuesday July 11th @ 13:30
> > > > works best for me. 08:30 would be 03:30 for me, which is a little
> > > > early. I could do Wed July 5th as well. It's the day after the the
> > > > July 4 holiday here, and a lot of people are making it a long
> weekend.
> > > > So there will be the inevitable "catch up" associated with that, but
> > > > it is doable.
> > > >
> > > > Terry (otherwiseguy)
> > > >
> > >
> > > Given that July 5th is tomorrow I'm assuming there won't be a community
> > > meeting as it seems quite short notice.
> > >
> > > Frode, is Tuesday July 11th 13:30 UTC still an option for you?  If I'm
> > > not wrong this was the slot that worked for everyone that replied.
> >
> > Yes, Tuesday July 11th 13:30 UTC is indeed sailing up as the consensus,
> > so let's conclude that's the date/time of our first meeting.
> >
> > Thanks for swift replies everyone! I'll send an meeting invite with
> > proposed
> > agenda to those who responded to this thread soon, and I'll also pop a
> > video link into this thread as we get closer for the benefit of anyone
> else
> > interested.
> >
>
> Please include me in the invite list.
> (nusid...@redhat.com)
>
> Numan
>
>
> > --
> > Frode Nordahl
> >
> > >
> > > Thanks,
> > > Dumitru
> > >
> > >
> > ___
> > 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
>

-- 




_‘Esta mensagem é direcionada apenas para os endereços constantes no 
cabeçalho inicial. Se você não está listado nos endereços constantes no 
cabeçalho, pedimos-lhe que desconsidere completamente o conteúdo dessa 
mensagem e cuja cópia, encaminhamento e/ou execução das ações citadas estão 
imediatamente anuladas e proibidas’._


* **‘Apesar do Magazine Luiza tomar 
todas as precauções razoáveis para assegurar que nenhum vírus esteja 
presente nesse e-mail, a empresa não poderá aceitar a responsabilidade por 
quaisquer perdas ou danos causados por esse e-mail ou por seus anexos’.*



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

[ovs-dev] [PATCH ovn] ovn-nbctl: Fix documentation typo

[Roberto Bartzen Acosta via dev]

Typo fix in the ovn-nbctl man page.
According to the ovn-nbctl man8:
* NAT command
[--may-exist] [--stateless] [--gateway_port=GATEWAY_PORT]
lr-nat-add router type external_ip logical_ip [logical_port external_mac]

Result using man page sintax:
ovn-nbctl: unrecognized option '--gateway_port'

The option expected by the implementation is:
--gateway-port


Fixes: 2d942be ("northd: Add support for NAT with multiple DGP")
Signed-off-by: Roberto Acosta 
---
 utilities/ovn-nbctl.8.xml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/utilities/ovn-nbctl.8.xml b/utilities/ovn-nbctl.8.xml
index 72d4088f0..54dbdb791 100644
--- a/utilities/ovn-nbctl.8.xml
+++ b/utilities/ovn-nbctl.8.xml
@@ -1151,7 +1151,7 @@
 NAT Commands

 
-  [--may-exist] [--stateless]
[--gateway_port=GATEWAY_PORT]
lr-nat-add router type
external_ip logical_ip [logical_port
external_mac]
+  [--may-exist] [--stateless]
[--gateway-port=GATEWAY_PORT]
lr-nat-add router type
external_ip logical_ip [logical_port
external_mac]
   
 
   Adds the specified NAT to router.

-- 




_‘Esta mensagem é direcionada apenas para os endereços constantes no 
cabeçalho inicial. Se você não está listado nos endereços constantes no 
cabeçalho, pedimos-lhe que desconsidere completamente o conteúdo dessa 
mensagem e cuja cópia, encaminhamento e/ou execução das ações citadas estão 
imediatamente anuladas e proibidas’._


* **‘Apesar do Magazine Luiza tomar 
todas as precauções razoáveis para assegurar que nenhum vírus esteja 
presente nesse e-mail, a empresa não poderá aceitar a responsabilidade por 
quaisquer perdas ou danos causados por esse e-mail ou por seus anexos’.*



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