Re: [ovs-dev] [PATCH ovn v5 0/7] Optimize load balancer hairpin logical flows.
On Fri, Nov 20, 2020 at 8:04 AM Mark Michelson wrote: > > For the series: > > Acked-by: Mark Michelson Thanks Dumitru and Mark for the reviews. I applied this series to master. @Ben - There are changes in ovn-northd in this series which would break the ddlog tests. When you respin another version of ddlog, you can skip the failing tests with northd-ddlog. I will work on the ddlog changes. Thanks Numan > > On 11/17/20 9:26 AM, num...@ovn.org wrote: > > From: Numan Siddique > > > > This patch series optimizes the load balancer hairpin logical flows. > > Presently, ovn-northd generates a lot of these logical flows. > > > > Suppose there are 'm' load balancers associated to a logical switch and > > each load balancer > > has 'n' VIPs and each VIP has 'p' backends then ovn-northd adds (m * ((n * > > p) + n)) > > hairpin logical flows. > > > > With this patch series, ovn-northd adds just 5 hairpin logical flows. > > > > To reduce the number of lflows, load balancer information is now pushed > > to the Southbound database using a new 'Load_Balancer' table. > > ovn-controller programs the OF flows required for handling the load > > balancer hairpin traffic directly and new OVN actions are added to > > abstract the hairpining from ovn-northd. > > > > v4 -> v5 > > > >* Incorporated Dumitru's changes on top of v4 patch 2 and squashed it > > into one patch - v5 p2. > > > > v3 -> v4 > > > >* Addressed review comments from Dumitru which was missed out in v3. > >* Separate lb structures for northd and ovn-controller in lib/lb.c. > >* Incorporated Dumitru's code suggestions in patch 1 for syncing > > the NB load balancer to SB load balancer. > > > > v2 -> v3 > > > >* Addressed most of the review comments from Dumitru. > >* Modified the test cases to make use of the newly added helper test > > functions. > > > > v1 -> v2 > > - > >* Addressed the review comments from Mark Michelson. > >* Added 2 more patches to the series to have SB Load balancer support > > ovn-detrace and 'ovn-sbctl --vflows' as pointed by Dumitru Ceara. > > > > > > Dumitru Ceara (1): > >northd: Refactor load balancer vip parsing. > > > > Numan Siddique (6): > >Add new table Load_Balancer in Southbound database. > >controller: Add load balancer hairpin OF flows. > >actions: Add new actions chk_lb_hairpin, chk_lb_hairpin_reply and > > ct_snat_to_vip. > >northd: Make use of new hairpin actions. > >ovn-detrace: Add SB Load Balancer cookier handler. > >sbctl: Add Load Balancer support for vflows option. > > > > controller/lflow.c | 234 + > > controller/lflow.h | 6 +- > > controller/ovn-controller.c | 27 +- > > include/ovn/actions.h| 15 +- > > include/ovn/logical-fields.h | 3 + > > lib/actions.c| 116 ++- > > lib/automake.mk | 4 +- > > lib/lb.c | 301 + > > lib/lb.h | 97 ++ > > northd/ovn-northd.8.xml | 65 +++- > > northd/ovn-northd.c | 632 ++- > > ovn-sb.ovsschema | 27 +- > > ovn-sb.xml | 82 + > > tests/ovn-northd.at | 115 ++- > > tests/ovn.at | 510 +++- > > tests/test-ovn.c | 3 + > > utilities/ovn-detrace.in | 11 +- > > utilities/ovn-sbctl.c| 59 > > utilities/ovn-trace.c| 65 +++- > > 19 files changed, 1940 insertions(+), 432 deletions(-) > > create mode 100644 lib/lb.c > > create mode 100644 lib/lb.h > > > > ___ > dev mailing list > d...@openvswitch.org > https://mail.openvswitch.org/mailman/listinfo/ovs-dev > ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH net-next v2] net: openvswitch: Be liberal in tcp conntrack.
Jakub Kicinski wrote: > On Mon, 16 Nov 2020 18:31:26 +0530 nusid...@redhat.com wrote: > > From: Numan Siddique > > > > There is no easy way to distinguish if a conntracked tcp packet is > > marked invalid because of tcp_in_window() check error or because > > it doesn't belong to an existing connection. With this patch, > > openvswitch sets liberal tcp flag for the established sessions so > > that out of window packets are not marked invalid. > > > > A helper function - nf_ct_set_tcp_be_liberal(nf_conn) is added which > > sets this flag for both the directions of the nf_conn. > > > > Suggested-by: Florian Westphal > > Signed-off-by: Numan Siddique > > Florian, LGTY? Sorry, this one sailed past me. Acked-by: Florian Westphal ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH net-next v2] net: openvswitch: Be liberal in tcp conntrack.
On Mon, 16 Nov 2020 18:31:26 +0530 nusid...@redhat.com wrote: > From: Numan Siddique > > There is no easy way to distinguish if a conntracked tcp packet is > marked invalid because of tcp_in_window() check error or because > it doesn't belong to an existing connection. With this patch, > openvswitch sets liberal tcp flag for the established sessions so > that out of window packets are not marked invalid. > > A helper function - nf_ct_set_tcp_be_liberal(nf_conn) is added which > sets this flag for both the directions of the nf_conn. > > Suggested-by: Florian Westphal > Signed-off-by: Numan Siddique Florian, LGTY? ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH ovn 14/14] ovn-nbctl: Fix leak of array of new policies.
LGTM.
--
taoyunxi...@cmss.chinamobile.com
>CC: Tao YunXiang
>Fixes: 5820502a5507 ("ovn-nbctl.c: Fix lr-policy-del command")
>Signed-off-by: Ilya Maximets
>---
> utilities/ovn-nbctl.c | 1 +
> 1 file changed, 1 insertion(+)
>
>diff --git a/utilities/ovn-nbctl.c b/utilities/ovn-nbctl.c
>index 448c86f42..fa1522152 100644
>--- a/utilities/ovn-nbctl.c
>+++ b/utilities/ovn-nbctl.c
>@@ -3758,6 +3758,7 @@ nbctl_lr_policy_del(struct ctl_context *ctx)
> if (!shash_find(&ctx->options, "--if-exists")) {
> ctl_error(ctx, "Logical router policy uuid is not
>found.");
> }
>+ free(new_policies);
> return;
> }
>
>--
>2.25.4
>
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] Congratulations!!!
My name is Sheryll Goedert. I was lucky enough to win a Powerball lottery jackpot of $396.9 million on the Powerball lottery. Congratulations, your email has won a donation of 3,200,000:00€. Contact me about the claim Via Email: goederts...@gmail.com ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH ovn v5 0/7] Optimize load balancer hairpin logical flows.
For the series: Acked-by: Mark Michelson On 11/17/20 9:26 AM, num...@ovn.org wrote: From: Numan Siddique This patch series optimizes the load balancer hairpin logical flows. Presently, ovn-northd generates a lot of these logical flows. Suppose there are 'm' load balancers associated to a logical switch and each load balancer has 'n' VIPs and each VIP has 'p' backends then ovn-northd adds (m * ((n * p) + n)) hairpin logical flows. With this patch series, ovn-northd adds just 5 hairpin logical flows. To reduce the number of lflows, load balancer information is now pushed to the Southbound database using a new 'Load_Balancer' table. ovn-controller programs the OF flows required for handling the load balancer hairpin traffic directly and new OVN actions are added to abstract the hairpining from ovn-northd. v4 -> v5 * Incorporated Dumitru's changes on top of v4 patch 2 and squashed it into one patch - v5 p2. v3 -> v4 * Addressed review comments from Dumitru which was missed out in v3. * Separate lb structures for northd and ovn-controller in lib/lb.c. * Incorporated Dumitru's code suggestions in patch 1 for syncing the NB load balancer to SB load balancer. v2 -> v3 * Addressed most of the review comments from Dumitru. * Modified the test cases to make use of the newly added helper test functions. v1 -> v2 - * Addressed the review comments from Mark Michelson. * Added 2 more patches to the series to have SB Load balancer support ovn-detrace and 'ovn-sbctl --vflows' as pointed by Dumitru Ceara. Dumitru Ceara (1): northd: Refactor load balancer vip parsing. Numan Siddique (6): Add new table Load_Balancer in Southbound database. controller: Add load balancer hairpin OF flows. actions: Add new actions chk_lb_hairpin, chk_lb_hairpin_reply and ct_snat_to_vip. northd: Make use of new hairpin actions. ovn-detrace: Add SB Load Balancer cookier handler. sbctl: Add Load Balancer support for vflows option. controller/lflow.c | 234 + controller/lflow.h | 6 +- controller/ovn-controller.c | 27 +- include/ovn/actions.h| 15 +- include/ovn/logical-fields.h | 3 + lib/actions.c| 116 ++- lib/automake.mk | 4 +- lib/lb.c | 301 + lib/lb.h | 97 ++ northd/ovn-northd.8.xml | 65 +++- northd/ovn-northd.c | 632 ++- ovn-sb.ovsschema | 27 +- ovn-sb.xml | 82 + tests/ovn-northd.at | 115 ++- tests/ovn.at | 510 +++- tests/test-ovn.c | 3 + utilities/ovn-detrace.in | 11 +- utilities/ovn-sbctl.c| 59 utilities/ovn-trace.c| 65 +++- 19 files changed, 1940 insertions(+), 432 deletions(-) create mode 100644 lib/lb.c create mode 100644 lib/lb.h ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH ovn v3] Provide the option to pin ovn-controller and ovn-northd to a specific version.
Hi Numan, I have one minor nit below. If you either address it or can explain it away, then: Acked-by: Mark Michelson On 11/18/20 9:14 AM, num...@ovn.org wrote: From: Numan Siddique OVN recommends updating/upgrading ovn-controllers first and then ovn-northd and OVN DB ovsdb-servers. This is to ensure that any new functionality specified by the database or logical flows created by ovn-northd is understood by ovn-controller. However certain deployments may upgrade ovn-northd services first and then ovn-controllers. In a large scal deployment, this can result in downtime during upgrades as old ovn-controllers may not understand new logical flows or new actions added by ovn-northd. Even upgrading ovn-controllers first can result in ovn-controllers rejecting some of the logical flows if an existing OVN action is changed. One such example is ct_commit action which recently was updated to take new arguments. To avoid such downtimes during upgrades, this patch adds the functionality of pinning ovn-controller and ovn-northd to a specific version. An internal OVN version is generated and this version is stored by ovn-northd in the Southbound SB_Global table's options:northd_internal_version. When ovn-controller notices that the internal version has changed, it stops handling the database changes - both Southbound and OVS. All the existing OF flows are preserved. When ovn-controller is upgraded to the same version as ovn-northd services, it will process the database changes. This feature is made optional and disabled by default. A CMS can enable it by configuring the OVS local database with the option - ovn-match-northd-version=true. Signed-off-by: Numan Siddique --- v2 -> v3 - * Addressed the review comments from Dumitru. * Added comments in actions.h and submitting-patches.rst about the changes that needs to be done when existing actions are updated. v1 -> v2 * Added test cases and missing documentation. * Renamed the ovsdb option from ignore_northd_verison to ovn-pin-to-northd. * Added NEWS item. .../contributing/submitting-patches.rst | 12 ++ NEWS | 3 + controller/ovn-controller.8.xml | 11 ++ controller/ovn-controller.c | 52 ++- include/ovn/actions.h | 4 + lib/ovn-util.c| 17 ++ lib/ovn-util.h| 4 + northd/ovn-northd.c | 18 ++- tests/ovn.at | 147 ++ 9 files changed, 263 insertions(+), 5 deletions(-) diff --git a/Documentation/internals/contributing/submitting-patches.rst b/Documentation/internals/contributing/submitting-patches.rst index 0a9de58669..31a3ca747b 100644 --- a/Documentation/internals/contributing/submitting-patches.rst +++ b/Documentation/internals/contributing/submitting-patches.rst @@ -397,6 +397,18 @@ Remember to follow-up and actually remove the feature from OVN codebase once deprecation grace period has expired and users had opportunity to use at least one OVN release that would have informed them about feature deprecation! +OVN upgrades + + +If the patch introduces any new OVN actions or updates existing OVN actions, +then make sure to check the function ovn_get_internal_version() in +lib/ovn-util.c and increment the macro - OVN_INTERNAL_MINOR_VER. + +Adding new OVN actions or changing existing OVN actions can have datapath +disruptions during OVN upgrades. To minimize disruptions, OVN supports +version matching between ovn-northd and ovn-controller and it is important +to update the internal OVN version when the patch introduces such changes. + Comments diff --git a/NEWS b/NEWS index 6010230679..bb95724b36 100644 --- a/NEWS +++ b/NEWS @@ -8,6 +8,9 @@ Post-v20.09.0 server. - Support other_config:vlan-passthru=true to allow VLAN tagged incoming traffic. + - Support version pinning between ovn-northd and ovn-controller as an + option. If the option is enabled and the versions don't match, + ovn-controller will not process any DB changes. OVN v20.09.0 - 28 Sep 2020 -- diff --git a/controller/ovn-controller.8.xml b/controller/ovn-controller.8.xml index 16bc47b205..b5c0800f0b 100644 --- a/controller/ovn-controller.8.xml +++ b/controller/ovn-controller.8.xml @@ -233,6 +233,17 @@ The boolean flag indicates if the chassis is used as an interconnection gateway. + + external_ids:ovn-match-northd-version + +The boolean flag indicates if ovn-controller needs to +check ovn-northd version. If this +flag is set to true and the ovn-northd's version (reported +in the Southbound database) doesn't match with the +ovn-controller's internal version, then it will stop +processing the southbound and lo
Re: [ovs-dev] [PATCH ovn 0/6] Combine Logical Flows by Logical Datapath.
Hi Ilya,
With regards to the test failures, I also see test 58 fail.
Test 59 sometimes passes and sometimes fails. I saw the crash you
referenced one time out of probably 25 test runs. As a double-check, I
reverted this series and ran the test in a loop. I never saw the test
fail or crash :(. here's something strange about the backtrace:
#0 0x004afb29 in hmap_next_with_hash__ (hash=1182893543,
node=0xe1) at ./include/openvswitch/hmap.h:323
#1 hmap_first_with_hash (hmap=0x2510070, hmap=0x2510070,
hash=1182893543) at ./include/openvswitch/hmap.h:334
(gdb) f 1
#1 hmap_first_with_hash (hmap=0x2510070, hmap=0x2510070,
hash=1182893543) at ./include/openvswitch/hmap.h:334
334 return hmap_next_with_hash__(hmap->buckets[hash &
hmap->mask], hash);
(gdb) list
329 /* Returns the first node in 'hmap' with the given 'hash', or a
null pointer if
330 * no nodes have that hash value. */
331 static inline struct hmap_node *
332 hmap_first_with_hash(const struct hmap *hmap, size_t hash)
333 {
334 return hmap_next_with_hash__(hmap->buckets[hash &
hmap->mask], hash);
335 }
336
337 /* Returns the first node in 'hmap' in the bucket in which the
given 'hash'
338 * would land, or a null pointer if that bucket is empty. */
Notice that on line 334, we pass the node as the first parameter and the
hash as the second parameter. This seems to match the function signature
of hmap_next_with_hash__(). But if you look at the backtrace, frame #0
shows the parameters reversed. Is that a normal gdb thing?
Test 153 passes for me every time. I ran it about 20 times and it always
passed. That test has had some trouble in the past with being too strict
with the matches it tries to make in the openflow table. If that's the
issue, then the match may need to be reworked again.
Test 159's failure was caused by my SNAT CT zone request patch and I
have a fix up for it now:
https://patchwork.ozlabs.org/project/ovn/patch/20201120001343.1485936-1-mmich...@redhat.com/
I think before we get this merged, we definitely need to get the test
failures figured out. Test 59 in particular is worrying.
On 11/14/20 2:56 AM, Ilya Maximets wrote:
This series is aimed to reduce size of a Southbound DB.
In modern OVN cluster there is a big probability that same logical
flows are installed for several logical switches. Currently, OVN
will create a separate logical flow for each logical switch (datapath)
filled with exact same match, actions and so on. The only difference
between these flows is a logical_datapath column. Depending on
a size of a cluster, there could be hundreds or even thousands of
copies of the same flow.
This change introduces new table Logical Datapath Group. With
this table we could combine datapaths in a single set and link
the whole datapath group to a single logical flow.
In my testing for a 7MB Northbound DB with 100 logical switches
taken from the ovn-k8s cluster test, size of a Southbound DB
decreased from 480 MB to 90 MB.
Number of logical flows in SB DB for this test case:
Currently- 1173779
With patches - 171632
Current implementation is functional, but it has few small
unfinished parts:
1. Backward compatibility code for ovn-controller is missing.
2. Some tests are failing and I don't know why yet (didn't spend
much time on this):
58: ovn -- dhcpv6 : 1 HV, 2 LS, 5 LSPs FAILED (ovn.at:6209)
59: ovn -- 2 HVs, 2 LRs connected via LS, gateway router FAILED
(ovs-macros.at:222)
153: ovn -- Symmetric ECMP reply flows FAILED (ovn.at:21589)
159: ovn -- ARP replies for SNAT external ipsFAILED (ovn.at:22328)
Test 59 fails with crash inside idl code on ovn-controller side
and that is suspicious (might be not entirely my fault):
SIGSEGV detected, backtrace:
0x4567de
0x7f27270b96b0
0x4b1e40
0x4abeb7
0x4b0cbf
0x4b0b43
0x4b04a9
0x4afa0f
0x4aa554
0x4aa35f
0x4aec62
0x42043c
0x7f27270a41a3 <__libc_start_main+0xf3>
0x404e5e <_start+0x2e>
3. Patches 3-5 should be a single patch in order to work.
Split for now to make review easier.
4. Code might be not so elegnt in a few places.
First 5 patches implements 1:1 relation between lflow and datapath
group, but it's still beneficial to have. First 5 patches reduces
DB in my case form 480 to 150 MB.
I also didn't run any performance tests. This will be necessary, since
flow processing is altered and this might give extra load on northd
and ovn-controller.
P.S. It looks like it's still Friday the 13th PST.. :)
Ilya Maximets (6):
tests: Sort flow and database dumps.
ovn-sb.ovsschema: Add Logical Datapath Groups.
northd: Add support for logical datapath groups.
controller: Unfinished changes to support Logical Datapath Groups.
utilities: Add support for Logica
[ovs-dev] Filtros, etiquetas y valores
Webinar en Vivo: Microsoft Excel: tablas dinámicas. 05 y 12de Diciembre - Horario de 10:00 a 14:00 Hrs. BUEN FIN: 3 x 2 en todos nuestros cursos. Promoción válida durante noviembre y diciembre 2020 así como enero 2021 Nuestro curso está diseñado para enseñarte a importar o construir bases de datos correctamente estructuradas para la creación de tablas dinámicas y a utilizar todas las herramientas de edición que Excel ofrece para esta funcionalidad. Ejes Temáticos: - Podrá importar o construir bases de datos correctamente estructuradas para la creación de tablas dinámicas. - Podrá seleccionar los datos que conformarán la tabla dinámica. - Podrá crear y editar tablas dinámicas. - Será capaz de hacer cruces de los campos como filtros, etiquetas y valores que generen informes relevantes. - Podrá utilizar los segmentadores de datos. - Podrá crear gráficos dinámicos a partir de tablas dinámicas creadas previamente. Para mayor información, responder sobre este correo con la palabra Tablas + los siguientes datos: NOMBRE: TELÉFONO: EMPRESA: CORREO ALTERNO: Para información inmediata llamar al: (+52) 55 15 54 66 30 - (+52) 55 30 16 70 85 O puede enviarnos un mensaje vía whatsapp Innova Learn México - innovalearn. mx - Mérida, Yucatán, México ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH ovn] northd: Fix leaks of strings while formatting ecmp flows.
On 11/19/20 8:40 PM, Ilya Maximets wrote:
> Result of 'normalize_v46_prefix()' should be freed and all dynamic
> strings should be destroyed.
>
> Direct leak of 156 byte(s) in 13 object(s) allocated from:
> #0 0x53700f in malloc (northd/ovn-northd+0x53700f)
> #1 0x71b146 in xmalloc ovs/lib/util.c:138:15
> #2 0x71b39a in xvasprintf ovs/lib/util.c:202:9
> #3 0x71b753 in xasprintf ovs/lib/util.c:343:9
> #4 0x59bddc in add_ecmp_symmetric_reply_flows northd/ovn-northd.c:7985:18
> #5 0x59aab5 in build_ecmp_route_flow northd/ovn-northd.c:8102:13
> #6 0x592260 in build_static_route_flows_for_lrouter ovn-northd.c:10243:13
> #7 0x589267 in build_lswitch_and_lrouter_iterate_by_od
> ovn-northd.c:11241:5
> #8 0x5888ca in build_lswitch_and_lrouter_flows northd/ovn-northd.c:11313:9
> #9 0x5730a0 in build_lflows northd/ovn-northd.c:11401:5
> #10 0x56f992 in ovnnb_db_run northd/ovn-northd.c:12339:5
> #11 0x56e8a7 in ovn_db_run northd/ovn-northd.c:12932:5
> #12 0x56d6af in main northd/ovn-northd.c:13338:17
> #13 0x7f5371d041a2 in __libc_start_main (/lib64/libc.so.6+0x271a2)
>
> Fixes: 4fdca656857d ("Add ECMP symmetric replies.")
> Signed-off-by: Ilya Maximets
> ---
Please, ignore this one. Re-sent as part of a patch-set:
https://patchwork.ozlabs.org/project/ovn/list/?series=215674
Best regards, Ilya Maximets.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [PATCH ovn 14/14] ovn-nbctl: Fix leak of array of new policies.
CC: Tao YunXiang
Fixes: 5820502a5507 ("ovn-nbctl.c: Fix lr-policy-del command")
Signed-off-by: Ilya Maximets
---
utilities/ovn-nbctl.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/utilities/ovn-nbctl.c b/utilities/ovn-nbctl.c
index 448c86f42..fa1522152 100644
--- a/utilities/ovn-nbctl.c
+++ b/utilities/ovn-nbctl.c
@@ -3758,6 +3758,7 @@ nbctl_lr_policy_del(struct ctl_context *ctx)
if (!shash_find(&ctx->options, "--if-exists")) {
ctl_error(ctx, "Logical router policy uuid is not found.");
}
+free(new_policies);
return;
}
--
2.25.4
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [PATCH ovn 12/14] ovn-nbctl: Fix IP leak on router NAT addition failure.
Cleanup needed instead of direct return.
Fixes: 43f42ecb3a5a ("Use normalized IP addreses in `ovn-nbctl lr-nat-add`")
Signed-off-by: Ilya Maximets
---
utilities/ovn-nbctl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/utilities/ovn-nbctl.c b/utilities/ovn-nbctl.c
index 89537edf0..526dbf86c 100644
--- a/utilities/ovn-nbctl.c
+++ b/utilities/ovn-nbctl.c
@@ -4311,7 +4311,7 @@ nbctl_lr_nat_add(struct ctl_context *ctx)
if (strcmp(nat_type, "dnat_and_snat") && stateless) {
ctl_error(ctx, "stateless is not applicable to dnat or snat types");
-return;
+goto cleanup;
}
int is_snat = !strcmp("snat", nat_type);
--
2.25.4
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [PATCH ovn 11/14] ovn-nbctl: Fix leak of IPs while configuring NAT.
CC: Ankur Sharma
Fixes: 20bc58a67f39 ("External IP based NAT: Add Columns and CLI")
Signed-off-by: Ilya Maximets
---
utilities/ovn-nbctl.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/utilities/ovn-nbctl.c b/utilities/ovn-nbctl.c
index fb6766839..89537edf0 100644
--- a/utilities/ovn-nbctl.c
+++ b/utilities/ovn-nbctl.c
@@ -4601,8 +4601,11 @@ nbctl_lr_nat_set_ext_ips(struct ctl_context *ctx)
} else {
nbrec_nat_set_allowed_ext_ips(nat, addr_set);
}
+free(nat_ip);
+free(old_ip);
return;
}
+free(old_ip);
}
if (!nat_found) {
--
2.25.4
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [PATCH ovn 09/14] northd: Fix leak of dynamic string for fwd group ports.
'group_ports' never destroyed and re-created on each iteration.
CC: Manoj Sharma
Fixes: edb240081518 ("Forwarding group to load balance l2 traffic with liveness
detection")
Signed-off-by: Ilya Maximets
---
northd/ovn-northd.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/northd/ovn-northd.c b/northd/ovn-northd.c
index 1d41aacc6..474333e68 100644
--- a/northd/ovn-northd.c
+++ b/northd/ovn-northd.c
@@ -6138,6 +6138,7 @@ build_fwd_group_lflows(struct ovn_datapath *od, struct
hmap *lflows)
if (!(!od->nbs || !od->nbs->n_forwarding_groups)) {
struct ds match = DS_EMPTY_INITIALIZER;
struct ds actions = DS_EMPTY_INITIALIZER;
+struct ds group_ports = DS_EMPTY_INITIALIZER;
for (int i = 0; i < od->nbs->n_forwarding_groups; ++i) {
const struct nbrec_forwarding_group *fwd_group = NULL;
@@ -6171,7 +6172,7 @@ build_fwd_group_lflows(struct ovn_datapath *od, struct
hmap *lflows)
ds_put_format(&match, "eth.dst == %s", fwd_group->vmac);
/* Create a comma separated string of child ports */
-struct ds group_ports = DS_EMPTY_INITIALIZER;
+ds_clear(&group_ports);
if (fwd_group->liveness) {
ds_put_cstr(&group_ports, "liveness=\"true\",");
}
@@ -6192,6 +6193,7 @@ build_fwd_group_lflows(struct ovn_datapath *od, struct
hmap *lflows)
ds_destroy(&match);
ds_destroy(&actions);
+ds_destroy(&group_ports);
}
}
--
2.25.4
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [PATCH ovn 10/14] actions: Fix leak of dynamic string on fwd group encoding failure.
CC: Manoj Sharma
Fixes: edb240081518 ("Forwarding group to load balance l2 traffic with liveness
detection")
Signed-off-by: Ilya Maximets
---
lib/actions.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/lib/actions.c b/lib/actions.c
index ea949e1bd..99ce04197 100644
--- a/lib/actions.c
+++ b/lib/actions.c
@@ -3446,6 +3446,7 @@ encode_FWD_GROUP(const struct ovnact_fwd_group *fwd_group,
if (fwd_group->liveness) {
/* Find the openflow port number of the tunnel port */
if (!ep->tunnel_ofport(ep->aux, port_name, &ofport)) {
+ds_destroy(&ds);
return;
}
--
2.25.4
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [PATCH ovn 13/14] ovn-nbctl: Fix IP leak on failure of lr policy addition.
Fixes: 742474bad730 ("ovn-nbctl: Enhance lr-policy-add to set the options.")
Signed-off-by: Ilya Maximets
---
utilities/ovn-nbctl.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/utilities/ovn-nbctl.c b/utilities/ovn-nbctl.c
index 526dbf86c..448c86f42 100644
--- a/utilities/ovn-nbctl.c
+++ b/utilities/ovn-nbctl.c
@@ -3689,6 +3689,7 @@ nbctl_lr_policy_add(struct ctl_context *ctx)
} else {
ctl_error(ctx, "No value specified for the option : %s", key);
free(key);
+free(next_hop);
return;
}
free(key);
--
2.25.4
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [PATCH ovn 07/14] ovn-controller: Fix leak of pending ct zones.
shash contains pointers to the data that should be freed.
Direct leak of 32 byte(s) in 2 object(s) allocated from:
#0 0x52100f in malloc (/controller/ovn-controller+0x52100f)
#1 0x752436 in xmalloc /lib/util.c:138:15
#2 0x5a2f0b in add_pending_ct_zone_entry /controller/ovn-controller.c:548:45
#3 0x5a2d1d in update_ct_zones /controller/ovn-controller.c:668:9
#4 0x59d8c6 in en_ct_zones_run /controller/ovn-controller.c:1495:5
#5 0x5dade4 in engine_run /lib/inc-proc-eng.c:377:9
#6 0x59adf4 in main /controller/ovn-controller.c
#7 0x7f0799ef41a2 in __libc_start_main (/lib64/libc.so.6+0x271a2)
CC: xu rong
Fixes: 252e1642fb59 ("ovn-controller: pending_ct_zones should be destroyed")
Signed-off-by: Ilya Maximets
---
controller/ovn-controller.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/controller/ovn-controller.c b/controller/ovn-controller.c
index 70a193bb2..7b915ed6a 100644
--- a/controller/ovn-controller.c
+++ b/controller/ovn-controller.c
@@ -1512,7 +1512,7 @@ en_ct_zones_cleanup(void *data)
struct ed_type_ct_zones *ct_zones_data = data;
simap_destroy(&ct_zones_data->current);
-shash_destroy(&ct_zones_data->pending);
+shash_destroy_free_data(&ct_zones_data->pending);
}
static void
--
2.25.4
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [PATCH ovn 06/14] pinctrl: Fix leak of DNS cache records.
'smap_clear()' doesn't free allocated memory, but 'smap_clone()'
re-initializes hash map clearing internal pointers and leaking
this memory. 'smap_destroy()' should be used instead.
Also, all the records and array of datapaths should be freed on
destruction of a cache entry.
Direct leak of 16 byte(s) in 2 object(s) allocated from:
#0 0x5211c7 in calloc (/controller/ovn-controller+0x5211c7)
#1 0x752364 in xcalloc /lib/util.c:121:31
#2 0x576e76 in sync_dns_cache /controller/pinctrl.c:2517:25
#3 0x5758fb in pinctrl_run /controller/pinctrl.c:3158:5
#4 0x59b06c in main /controller/ovn-controller.c:2642:25
#5 0x7fb570fc11a2 in __libc_start_main (/lib64/libc.so.6+0x271a2)
Indirect leak of 26 byte(s) in 2 object(s) allocated from:
#0 0x52100f in malloc (/controller/ovn-controller+0x52100f)
#1 0x7523d6 in xmalloc /lib/util.c:138:15
#2 0x7524a8 in xmemdup0 /lib/util.c:168:15
#3 0x73d8fc in smap_clone /lib/smap.c:314:45
#4 0x576e2f in sync_dns_cache /controller/pinctrl.c:2513:13
#5 0x5758fb in pinctrl_run /controller/pinctrl.c:3158:5
#6 0x59b06c in main /controller/ovn-controller.c:2642:25
#7 0x7fb570fc11a2 in __libc_start_main (/lib64/libc.so.6+0x271a2)
Fixes: 6b72068202f1 ("ovn-controller: Add a new thread in pinctrl module to
handle packet-ins.")
Signed-off-by: Ilya Maximets
---
controller/pinctrl.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/controller/pinctrl.c b/controller/pinctrl.c
index a5236564b..2012ba65a 100644
--- a/controller/pinctrl.c
+++ b/controller/pinctrl.c
@@ -2509,7 +2509,7 @@ sync_dns_cache(const struct sbrec_dns_table *dns_table)
dns_data->delete = false;
if (!smap_equal(&dns_data->records, &sbrec_dns->records)) {
-smap_clear(&dns_data->records);
+smap_destroy(&dns_data->records);
smap_clone(&dns_data->records, &sbrec_dns->records);
}
@@ -2525,6 +2525,8 @@ sync_dns_cache(const struct sbrec_dns_table *dns_table)
struct dns_data *d = iter->data;
if (d->delete) {
shash_delete(&dns_cache, iter);
+smap_destroy(&d->records);
+free(d->dps);
free(d);
}
}
@@ -2537,6 +2539,8 @@ destroy_dns_cache(void)
SHASH_FOR_EACH_SAFE (iter, next, &dns_cache) {
struct dns_data *d = iter->data;
shash_delete(&dns_cache, iter);
+smap_destroy(&d->records);
+free(d->dps);
free(d);
}
}
--
2.25.4
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [PATCH ovn 05/14] ofctrl: Fix leak of meter mod bands.
'parse_ofp_meter_mod_str' allocates space for meter.bands that
should be freed.
Direct leak of 448 byte(s) in 7 object(s) allocated from:
#0 0x52100f in malloc (/controller/ovn-controller+0x52100f)
#1 0x7523a6 in xmalloc /lib/util.c:138:15
#2 0x6fd079 in ofpbuf_init /lib/ofpbuf.c:123:26
#3 0x6cba27 in parse_ofp_meter_mod_str /lib/ofp-meter.c:779:5
#4 0x5705b8 in add_meter_string /controller/ofctrl.c:1674:19
#5 0x56f736 in ofctrl_put /controller/ofctrl.c:2105:13
#6 0x59aebb in main /controller/ovn-controller.c:2627:25
#7 0x7f07873251a2 in __libc_start_main (/lib64/libc.so.6+0x271a2)
CC: Guoshuai Li
Fixes: c25094b3884d ("ovn: OVN Support QoS meter")
Signed-off-by: Ilya Maximets
---
controller/ofctrl.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/controller/ofctrl.c b/controller/ofctrl.c
index 79529d13c..c1bbc589e 100644
--- a/controller/ofctrl.c
+++ b/controller/ofctrl.c
@@ -1675,6 +1675,7 @@ add_meter_string(struct ovn_extend_table_info *m_desired,
&usable_protocols);
if (!error) {
add_meter_mod(&mm, msgs);
+free(mm.meter.bands);
} else {
static struct vlog_rate_limit rl = VLOG_RATE_LIMIT_INIT(5, 1);
VLOG_ERR_RL(&rl, "new meter %s %s", error, meter_string);
--
2.25.4
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [PATCH ovn 04/14] actions: Fix leak of select group members.
'dsts' should be freed in case of any error.
Direct leak of 4 byte(s) in 1 object(s) allocated from:
#0 0x502378 in realloc (/tests/ovstest+0x502378)
#1 0x622826 in xrealloc /lib/util.c:149:9
#2 0x8194f4 in parse_select_action /lib/actions.c:1185:20
#3 0x814f49 in parse_set_action /lib/actions.c:3499:13
#4 0x814341 in parse_action /lib/actions.c:3554:9
#5 0x8139ef in parse_actions /lib/actions.c:3643:14
#6 0x8136a3 in ovnacts_parse /lib/actions.c:3678:9
#7 0x813c80 in ovnacts_parse_string /lib/actions.c:3705:5
#8 0x53a4e8 in test_parse_actions /tests/test-ovn.c:1321:17
#9 0x54e7a8 in ovs_cmdl_run_command__ /lib/command-line.c:247:17
#10 0x537c75 in test_ovn_main /tests/test-ovn.c:1630:5
#11 0x54e7a8 in ovs_cmdl_run_command__ /lib/command-line.c:247:17
#12 0x537359 in main /tests/ovstest.c:133:9
#13 0x7f9ce05ba1a2 in __libc_start_main (/lib64/libc.so.6+0x271a2)
CC: Han Zhou
Fixes: 85b3544aabb2 ("ovn-controller: A new action "select".")
Signed-off-by: Ilya Maximets
---
lib/actions.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/lib/actions.c b/lib/actions.c
index d98af0f91..ea949e1bd 100644
--- a/lib/actions.c
+++ b/lib/actions.c
@@ -1188,6 +1188,7 @@ parse_select_action(struct action_context *ctx, struct
expr_field *res_field)
}
if (n_dsts <= 1) {
lexer_syntax_error(ctx->lexer, "expecting at least 2 group members");
+free(dsts);
return;
}
--
2.25.4
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [PATCH ovn 03/14] actions: Fix leak of child ports in fwd group.
'child_port_list' is an array of pointers that should be freed too.
Direct leak of 30 byte(s) in 6 object(s) allocated from:
#0 0x501fff in malloc (/tests/ovstest+0x501fff)
#1 0x6227e6 in xmalloc /lib/util.c:138:15
#2 0x6228b8 in xmemdup0 /lib/util.c:168:15
#3 0x8183d6 in parse_fwd_group_action /lib/actions.c:3374:30
#4 0x814b6e in parse_action /lib/actions.c:3610:9
#5 0x8139ef in parse_actions /lib/actions.c:3637:14
#6 0x8136a3 in ovnacts_parse /lib/actions.c:3672:9
#7 0x813c80 in ovnacts_parse_string /lib/actions.c:3699:5
#8 0x53a979 in test_parse_actions /tests/test-ovn.c:1372:21
#9 0x54e7a8 in ovs_cmdl_run_command__ /lib/command-line.c:247:17
#10 0x537c75 in test_ovn_main /tests/test-ovn.c:1630:5
#11 0x54e7a8 in ovs_cmdl_run_command__ /lib/command-line.c:247:17
#12 0x537359 in main /tests/ovstest.c:133:9
#13 0x7f06978f21a2 in __libc_start_main (/lib64/libc.so.6+0x271a2)
CC: Manoj Sharma
Fixes: edb240081518 ("Forwarding group to load balance l2 traffic with liveness
detection")
Signed-off-by: Ilya Maximets
---
lib/actions.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/lib/actions.c b/lib/actions.c
index 6300fef2c..d98af0f91 100644
--- a/lib/actions.c
+++ b/lib/actions.c
@@ -3366,6 +3366,9 @@ parse_fwd_group_action(struct action_context *ctx)
lexer_syntax_error(ctx->lexer,
"expecting logical switch port");
if (child_port_list) {
+for (int i = 0; i < n_child_ports; i++) {
+free(child_port_list[i]);
+}
free(child_port_list);
}
return;
@@ -3471,6 +3474,9 @@ encode_FWD_GROUP(const struct ovnact_fwd_group *fwd_group,
static void
ovnact_fwd_group_free(struct ovnact_fwd_group *fwd_group)
{
+for (int i = 0; i < fwd_group->n_child_ports; i++) {
+free(fwd_group->child_ports[i]);
+}
free(fwd_group->child_ports);
}
--
2.25.4
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [PATCH ovn 08/14] ovn-nbctl: Fix error leak on duplicated switch port.
Error is allocated from heap and should be freed.
Fixes: 738295605b44 ("ovn: Detect and prevent duplicate address assignments.")
Signed-off-by: Ilya Maximets
---
utilities/ovn-nbctl.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/utilities/ovn-nbctl.c b/utilities/ovn-nbctl.c
index b5633c725..fb6766839 100644
--- a/utilities/ovn-nbctl.c
+++ b/utilities/ovn-nbctl.c
@@ -1683,6 +1683,7 @@ nbctl_lsp_set_addresses(struct ctl_context *ctx)
error = lsp_contains_duplicates(ls, lsp, ctx->argv[i]);
if (error) {
ctl_error(ctx, "%s", error);
+free(error);
return;
}
}
--
2.25.4
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [PATCH ovn 02/14] test-ovn: Fix expression leak.
No need to clone when assigning to the same variable.
Fixes: 024500aeab9a ("expr: Evaluate the condition expression in a separate
step.")
Signed-off-by: Ilya Maximets
---
tests/test-ovn.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tests/test-ovn.c b/tests/test-ovn.c
index 74b5a3384..18c675303 100644
--- a/tests/test-ovn.c
+++ b/tests/test-ovn.c
@@ -919,7 +919,7 @@ test_tree_shape_exhaustively(struct expr *expr, struct
shash *symtab,
} else if (operation >= OP_SIMPLIFY) {
modified = expr_simplify(expr_clone(expr));
modified = expr_evaluate_condition(
-expr_clone(modified), tree_shape_is_chassis_resident_cb,
+modified, tree_shape_is_chassis_resident_cb,
NULL, NULL);
ovs_assert(expr_honors_invariants(modified));
--
2.25.4
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [PATCH ovn 01/14] northd: Fix leaks of strings while formatting ecmp flows.
Result of 'normalize_v46_prefix()' should be freed and all dynamic
strings should be destroyed.
Fixes: 4fdca656857d ("Add ECMP symmetric replies.")
Signed-off-by: Ilya Maximets
---
northd/ovn-northd.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/northd/ovn-northd.c b/northd/ovn-northd.c
index 148d2a051..1d41aacc6 100644
--- a/northd/ovn-northd.c
+++ b/northd/ovn-northd.c
@@ -7971,6 +7971,7 @@ add_ecmp_symmetric_reply_flows(struct hmap *lflows,
IN6_IS_ADDR_V4MAPPED(&route->prefix) ? "4" : "6",
route->is_src_route ? "dst" : "src",
cidr);
+free(cidr);
ovn_lflow_add_with_hint(lflows, od, S_ROUTER_IN_DEFRAG, 100,
ds_cstr(&match), "ct_next;",
&st_route->header_);
@@ -8022,6 +8023,10 @@ add_ecmp_symmetric_reply_flows(struct hmap *lflows,
ovn_lflow_add_with_hint(lflows, od, S_ROUTER_IN_ARP_RESOLVE,
200, ds_cstr(&ecmp_reply),
action, &st_route->header_);
+
+ds_destroy(&match);
+ds_destroy(&actions);
+ds_destroy(&ecmp_reply);
}
static void
--
2.25.4
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [PATCH ovn 00/14] Pack of fixes for memory leaks.
Found by Clang AddressSanitizer. All patches has correct and different 'Fixes' tags, so could be backported to appropriate branches. Ilya Maximets (14): northd: Fix leaks of strings while formatting ecmp flows. test-ovn: Fix expression leak. actions: Fix leak of child ports in fwd group. actions: Fix leak of select group members. ofctrl: Fix leak of meter mod bands. pinctrl: Fix leak of DNS cache records. ovn-controller: Fix leak of pending ct zones. ovn-nbctl: Fix error leak on duplicated switch port. northd: Fix leak of dynamic string for fwd group ports. actions: Fix leak of dynamic string on fwd group encoding failure. ovn-nbctl: Fix leak of IPs while configuring NAT. ovn-nbctl: Fix IP leak on router NAT addition failure. ovn-nbctl: Fix IP leak on failure of lr policy addition. ovn-nbctl: Fix leak of array of new policies. controller/ofctrl.c | 1 + controller/ovn-controller.c | 2 +- controller/pinctrl.c| 6 +- lib/actions.c | 8 northd/ovn-northd.c | 9 - tests/test-ovn.c| 2 +- utilities/ovn-nbctl.c | 8 +++- 7 files changed, 31 insertions(+), 5 deletions(-) -- 2.25.4 ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [PATCH ovn] Clear port binding flows when datapath CT zone changes.
In commit f9cab11d5fabe2ae321a3b4bad5972b61df958c0, a LOG_TO_PHY flow
was changed so that it was no longer associated with a particular port
binding. The logic there was that the particular flow contains data
pertaining to the port binding's peer's datapath, so it didn't make
sense to associate the flow with the port binding. This change was
necessary in order for flows to be recalculated properly if the
requested SNAT CT zone on a gateway router was changed. Since the
datapath was changed but no port bindings were changed, that particular
flow needed to be cleared so it could be recalculated with the new CT
zones put in place.
Unfortunately, that change broke some other behavior. Specifically, if a
router was changed from a distributed router to a gateway router, then
its port bindings and its port bindings' peers would be updated so that
they were no longer type "patch" but instead type "l3gateway". They
would attempt to remove all associated physical flows and then install
the newly relevant ones. Since the LOG_TO_PHY flow was no longer
associated with a port binding, that flow would remain. The result was
that traffic could be sent to the gateway router on chassis where the
gateway router was not pinned.
This commit seeks to fix both behaviors. Now if CT zones are changed on
a particular datapath, then all port bindings on that datapath, as well
as all of those port bindings' peers will have their physical flows
removed. When physical flows are recomputed, all of the appropriate
flows will be added.
Signed-off-by: Mark Michelson
---
controller/ovn-controller.c | 31 ++--
controller/physical.c | 58 +
controller/physical.h | 4 +++
3 files changed, 79 insertions(+), 14 deletions(-)
diff --git a/controller/ovn-controller.c b/controller/ovn-controller.c
index 25de0c72f..eceb804ac 100644
--- a/controller/ovn-controller.c
+++ b/controller/ovn-controller.c
@@ -64,6 +64,7 @@
#include "timer.h"
#include "stopwatch.h"
#include "lib/inc-proc-eng.h"
+#include "hmapx.h"
VLOG_DEFINE_THIS_MODULE(main);
@@ -549,7 +550,7 @@ add_pending_ct_zone_entry(struct shash *pending_ct_zones,
static void
update_ct_zones(const struct sset *lports, const struct hmap *local_datapaths,
struct simap *ct_zones, unsigned long *ct_zone_bitmap,
-struct shash *pending_ct_zones)
+struct shash *pending_ct_zones, struct hmapx *updated_dps)
{
struct simap_node *ct_zone, *ct_zone_next;
int scan_start = 1;
@@ -563,6 +564,7 @@ update_ct_zones(const struct sset *lports, const struct
hmap *local_datapaths,
}
/* Local patched datapath (gateway routers) need zones assigned. */
+struct shash all_lds = SHASH_INITIALIZER(&all_lds);
const struct local_datapath *ld;
HMAP_FOR_EACH (ld, hmap_node, local_datapaths) {
/* XXX Add method to limit zone assignment to logical router
@@ -571,6 +573,8 @@ update_ct_zones(const struct sset *lports, const struct
hmap *local_datapaths,
char *snat = alloc_nat_zone_key(&ld->datapath->header_.uuid, "snat");
sset_add(&all_users, dnat);
sset_add(&all_users, snat);
+shash_add(&all_lds, dnat, ld);
+shash_add(&all_lds, snat, ld);
int req_snat_zone = datapath_snat_ct_zone(ld->datapath);
if (req_snat_zone >= 0) {
@@ -636,6 +640,11 @@ update_ct_zones(const struct sset *lports, const struct
hmap *local_datapaths,
bitmap_set1(ct_zone_bitmap, snat_req_node->data);
simap_put(ct_zones, snat_req_node->name, snat_req_node->data);
+struct shash_node *ld_node = shash_find(&all_lds, snat_req_node->name);
+if (ld_node) {
+struct local_datapath *dp = ld_node->data;
+hmapx_add(updated_dps, (void *) dp->datapath);
+}
}
/* xxx This is wasteful to assign a zone to each port--even if no
@@ -664,10 +673,17 @@ update_ct_zones(const struct sset *lports, const struct
hmap *local_datapaths,
bitmap_set1(ct_zone_bitmap, zone);
simap_put(ct_zones, user, zone);
+
+struct shash_node *ld_node = shash_find(&all_lds, user);
+if (ld_node) {
+struct local_datapath *dp = ld_node->data;
+hmapx_add(updated_dps, (void *) dp->datapath);
+}
}
simap_destroy(&req_snat_zones);
sset_destroy(&all_users);
+shash_destroy(&all_lds);
}
static void
@@ -1098,6 +1114,9 @@ struct ed_type_runtime_data {
bool tracked;
bool local_lports_changed;
struct hmap tracked_dp_bindings;
+
+/* CT zone data. Contains datapaths that had updated CT zones */
+struct hmapx ct_updated_datapaths;
};
/* struct ed_type_runtime_data has the below members for tracking the
@@ -1189,6 +1208,8 @@ en_runtime_data_init(struct engine_node *node OVS_UNUSED,
/* Init the tracked data. */
hmap_init(&data->tracked_dp_bindings);
+hmapx_init(&data->ct_updated_datapat
[ovs-dev] Lessons from America in 2020: Literature on societal divisions and the books that teach, calm & soothe & escape from this year!
BookConcierge is the worlds biggest online bookstore & lowest-price determinator in 23 countries. Price. Speed. Variety: only the Best & Cheapest & F [http://australia.bookconcierge.co] - THOUGHT LEADERS & INSIGHTS ON [http://bookconcierge.hk/]BOOKCONCIERGE AUSTRALIA [http://australia.bookconcierge.co] - - THE CULTURE & PLEASURE OF HATE - [http://australia.bookconcierge.co/9780141018928/On-the-Pleasure-of-Hating] [http://australia.bookconcierge.co/9780062883759/Love-Your-Enemies-How-Decent-People-Can-Save-America-from-Our-Culture-of-Contempt] [http://australia.bookconcierge.co/9781250195029/Them] [http://australia.bookconcierge.co/9780812983418/The-Road-to-Character] - CULTURAL WARS - [http://australia.bookconcierge.co/9780313350382/Culture-Wars-in-America-A-Documentary-and-Reference-Guide-Documentary-and-Reference-Guides] [http://australia.bookconcierge.co/9781610392761/The-Culture-Map] [http://australia.bookconcierge.co/9780465015344/The-Power-of-One-The-Ed-McAteer-Story] [http://australia.bookconcierge.co/9781472979575/The-Madness-of-Crowds] - Is Racism Embedded? - [http://australia.bookconcierge.co/9781632864130/White-Rage] [http://australia.bookconcierge.co/9780374186326/Life-of-a-Klansman] [http://australia.bookconcierge.co/9780807047415/White-Fragility] [http://australia.bookconcierge.co/9780525509288/How-To-Be-An-Antiracist] - HEALTHCARE REFORM - [http://australia.bookconcierge.co/9780195181326/Your-Money-or-Your-Life-Strong-Medicine-for-America-s-Health-Care-System] [http://australia.bookconcierge.co/9780300171099/Remedy-and-Reaction-The-Peculiar-American-Struggle-over-Health-Care-Reform] [http://australia.bookconcierge.co/9780465079353/Social-Transformation-of-American-Medicine-the-Rise-of-a-Soverign-Profession-and-the-Making-of-a-Vast-Industry] [http://australia.bookconcierge.co/9780520270190/Inside-National-Health-Reform] - THE OPIOID CRISIS - [http://australia.bookconcierge.co/9781788549868/Dopesick] [http://australia.bookconcierge.co/9781421421407/Drug-Dealer-MD] [http://australia.bookconcierge.co/9781250196262/American-Fix] [http://australia.bookconcierge.co/9781784708832/Cherry] - Click & Search & browse our 30 million books freely on BookConcierge Australia [http://australia.bookconcierge.co] - UNSURE WHAT TO LOOK FOR? CHOOSE YOUR CATEGORY, AND JUST CLICK AN EMPTY SEARCH TO BROWSE RANDOMLY, FREELY, AND BE ENDLESSLY CAPTIVATED BY ALL THE NEW BOOKS YOU CAN DISCOVER! WE ALSO SUPPLY SCHOOL & ACADEMIC TEXT BOOKS AND MATERIALS! TALK TO US TO FIND OUT MORE! [http://australia.bookconcierge.co] _EDUCATORS, TELL US: WHAT PRODUCTS OR SERVICES DO YOU WANT EASY ACCESS TO BUY FOR YOUR TEACHING NEEDS?__ _ LIFE AS AN EDUCATOR IS NEVER EASY - WE ARE HERE TO HELP YOU! TELL US: REPLY TO THIS EMAIL OR EMAIL feedb...@bookconcierge.co TO TALK TO US! - SELECTED & PRIZE WINNING READS ON BOOKCONCIERGE AUSTRALIA [http://australia.bookconcierge.co]- [http://australia.bookconcierge.co/9780525509288/How-To-Be-An-Antiracist] [http://australia.bookconcierge.co/9781982141462/Untitled-Nonfiction-Ed] [http://australia.bookconcierge.co/9780807047415/White-Fragility] [http://australia.bookconcierge.co/9780307453433/Coming-Apart-The-State-of-White-America-1960-2010] [http://australia.bookconcierge.co/9781920769413/Living-in-the-Hothouse] [http://australia.bookconcierge.co/9780060081584/The-Dance-of-Fear-Rising-Above-Anxiety-Fear-and-Shame-to-Be-Your-Best-and-Bravest-Self] [http://australia.bookconcierge.co/9781847920102/Spillover] [http://australia.bookconcierge.co/9780522871548/Sunburnt-Country] [http://australia.bookconcierge.co/9781597841207/Cleanliness-in-Islam] [http://australia.bookconcierge.co//9780140250916/The-Coming-Plague-Newly-Emerging-Diseases-in-a-World-Out-of-Balance] [http://australia.bookconcierge.co/9780801444814/The-Culture-of-Cleanliness-in-Renaissance-Italy] [http://australia.bookconcierge.co/9781911545194/The-Invisible-Killer] [http://australia.bookconcierge.co/9780670070633/High-and-Dry] [http://australia.bookconcierge.co/9781163063224/On-Cleanliness-and-Domestic-Virtues] [http://australia.bookconcierge.co/9780868409733/Greenhouse-Solutions-with-Sustainable-Energy]
[ovs-dev] A website where you may find your sweetheart!
A website where you may find your sweetheart! Note: It is likely that the quick wit and auty of our members will leave you speechless. Now you can enjoy your time： You are man You are women About Us Opportunity to travel across the continents is extremely exciting but yet still not completely available. However, we live in the age of the Internet and enjoy limitless possibilities it provides. People from the USA, Germany or the UK can make new connections with from Russians, Argentinians, or Chinese without any problems and in a snap of a finger. JollyRomance gives a chance to meet someone you would not have met in real life. Our Goal JollyRomance strives to be a place connecting people from all over the world. We put efforts on involving people from different countries to be registered here and enjoy communication. ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [PATCH ovn] northd: Fix leaks of strings while formatting ecmp flows.
Result of 'normalize_v46_prefix()' should be freed and all dynamic
strings should be destroyed.
Direct leak of 156 byte(s) in 13 object(s) allocated from:
#0 0x53700f in malloc (northd/ovn-northd+0x53700f)
#1 0x71b146 in xmalloc ovs/lib/util.c:138:15
#2 0x71b39a in xvasprintf ovs/lib/util.c:202:9
#3 0x71b753 in xasprintf ovs/lib/util.c:343:9
#4 0x59bddc in add_ecmp_symmetric_reply_flows northd/ovn-northd.c:7985:18
#5 0x59aab5 in build_ecmp_route_flow northd/ovn-northd.c:8102:13
#6 0x592260 in build_static_route_flows_for_lrouter ovn-northd.c:10243:13
#7 0x589267 in build_lswitch_and_lrouter_iterate_by_od ovn-northd.c:11241:5
#8 0x5888ca in build_lswitch_and_lrouter_flows northd/ovn-northd.c:11313:9
#9 0x5730a0 in build_lflows northd/ovn-northd.c:11401:5
#10 0x56f992 in ovnnb_db_run northd/ovn-northd.c:12339:5
#11 0x56e8a7 in ovn_db_run northd/ovn-northd.c:12932:5
#12 0x56d6af in main northd/ovn-northd.c:13338:17
#13 0x7f5371d041a2 in __libc_start_main (/lib64/libc.so.6+0x271a2)
Fixes: 4fdca656857d ("Add ECMP symmetric replies.")
Signed-off-by: Ilya Maximets
---
northd/ovn-northd.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/northd/ovn-northd.c b/northd/ovn-northd.c
index 148d2a051..1d41aacc6 100644
--- a/northd/ovn-northd.c
+++ b/northd/ovn-northd.c
@@ -7971,6 +7971,7 @@ add_ecmp_symmetric_reply_flows(struct hmap *lflows,
IN6_IS_ADDR_V4MAPPED(&route->prefix) ? "4" : "6",
route->is_src_route ? "dst" : "src",
cidr);
+free(cidr);
ovn_lflow_add_with_hint(lflows, od, S_ROUTER_IN_DEFRAG, 100,
ds_cstr(&match), "ct_next;",
&st_route->header_);
@@ -8022,6 +8023,10 @@ add_ecmp_symmetric_reply_flows(struct hmap *lflows,
ovn_lflow_add_with_hint(lflows, od, S_ROUTER_IN_ARP_RESOLVE,
200, ds_cstr(&ecmp_reply),
action, &st_route->header_);
+
+ds_destroy(&match);
+ds_destroy(&actions);
+ds_destroy(&ecmp_reply);
}
static void
--
2.25.4
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] OVN Meeting Logs 19 November, 2020
Here is the IRC log for the OVN meeting for 19 November, 2020 http://eavesdrop.openstack.org/meetings//ovn_community_development_discussion/2020/ovn_community_development_discussion.2020-11-19-18.15.log.html If you are interested in attending this meeting, it happens every Thursday in the #openvswitch channel on the Freenode IRC server. The next one is at 13:15 EST (18:15 GMT, 10:15 PST) on 26 November, 2020. Mark Michelson ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] Whatsapp Business - Aumente sus ventas
Webinar en Vivo: Cómo aumentar tus ventas con Whatsapp Business - 05 de Diciembre Whatsapp robot: cómo configurarlo para incrementar tus ventas - 12 de Diciembre - Horario de 10:00 a 14:00 Hrs.- BUEN FIN: 3 x 2 en todos nuestros cursos. Promoción válida durante noviembre y diciembre 2020 así como enero 2021 Aprenderá a crear contenido de valor con el objetivo de generar alto impacto a través de la aplicación más utilizada del mundo.El participante aprenderá a descargar, configurar, redactar y aplicar un robot automatizado, en la aplicación Whatsapp Business, para optimizar su proceso de ventas. Objetivos Específicos: - WhatsApp cómo poderosa herramienta de ventas. - Errores comunes al utilizar WhatsApp cómo herramienta de marketing. - Atención al cliente como estrategia de fidelización. - Robot en Whatsapp Business. * Tipos de robot. * Guion y contenido. *Configuración de la herramienta Whatsapp Business. Para mayor información, responder sobre este correo con la palabra Whatsapp + los siguientes datos: NOMBRE: TELÉFONO: EMPRESA: CORREO ALTERNO: Para información inmediata llamar al: (+52) 55 15 54 66 30 - (+52) 55 30 16 70 85 O puede enviarnos un mensaje vía whatsapp Innova Learn México - innovalearn. mx - Mérida, Yucatán, México ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH ovn v2] ovn-controller: Fix nb_cfg update with monitor_cond_change in flight.
On Thu, Nov 19, 2020 at 09:59:04AM -0800, Ben Pfaff wrote: > On Thu, Nov 19, 2020 at 11:50:57AM +0100, Dumitru Ceara wrote: > > On 11/19/20 5:15 AM, Ben Pfaff wrote: > > > On Tue, Nov 17, 2020 at 05:50:20PM +0100, Dumitru Ceara wrote: > > >> It is not correct for ovn-controller to pass the current SB_Global.nb_cfg > > >> value to ofctrl_put() if there are pending changes to conditional > > >> monitoring clauses (local or in flight). It might be that after the > > >> monitor condition is acked by the SB, records that were added to the SB > > >> before SB_Global.nb_cfg was set are now sent as updates to > > >> ovn-controller. These should be first installed in OVS before > > >> ovn-controller reports that it caught up with the current > > >> SB_Global.nb_cfg value. > > >> > > >> Also, ofctrl_put should not advance cur_cfg if there are flow updates in > > >> flight. > > ... > > > > ovn-controller has changed (advanced?) to the point that I have trouble > > > understanding the code now. I'm going to assume that you understand it > > > pretty well, but please allow me to ask a question here. Will this > > > > I'm doing my best but there are so many dependencies and side effects in > > the code.. > > DDlog might actually help with that, eventually. It should allow us to > program in the problem domain, rather than writing a lot of code to > manage dependencies. > > > > always manage to come up to date with some version of the sb, or is > > > there a chance that it never will report a consistent value if the sb > > > keeps changing quickly? I wasn't able to figure that out with a quick > > > look. > > > > > > > Now, back to your question: > > > > TLDR: If ovn-controller has to continuously change its monitor > > conditions I *think* there is a chance that it will never report that is > > caught up with a specific SB seqno. However, I tried various scenarios > > (with quick SB updates or claiming/releasing OVS interfaces in quick > > succession) and I didn't manage to make "ovn-nbctl --wait=hv sync" block > > indefinitely. > > That's good, empirically. > > > Moreover, I think the question is if it's correct for ovn-controller to > > report it has caught up if there are unseen SB flows that correspond to > > its currently requested but not acked monitor condition? > > I think the answer is "no", which means that the next question is, how > do we implement it properly? I don't have an immediate answer. The > database interfacing code is rather complex these days. Oh, let me give this patch a conditional "ack". If you are pretty confident that it makes things better, then it has my blessing: Acked-by: Ben Pfaff ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH ovn v2] ovn-controller: Fix nb_cfg update with monitor_cond_change in flight.
On Thu, Nov 19, 2020 at 11:50:57AM +0100, Dumitru Ceara wrote: > On 11/19/20 5:15 AM, Ben Pfaff wrote: > > On Tue, Nov 17, 2020 at 05:50:20PM +0100, Dumitru Ceara wrote: > >> It is not correct for ovn-controller to pass the current SB_Global.nb_cfg > >> value to ofctrl_put() if there are pending changes to conditional > >> monitoring clauses (local or in flight). It might be that after the > >> monitor condition is acked by the SB, records that were added to the SB > >> before SB_Global.nb_cfg was set are now sent as updates to > >> ovn-controller. These should be first installed in OVS before > >> ovn-controller reports that it caught up with the current > >> SB_Global.nb_cfg value. > >> > >> Also, ofctrl_put should not advance cur_cfg if there are flow updates in > >> flight. ... > > ovn-controller has changed (advanced?) to the point that I have trouble > > understanding the code now. I'm going to assume that you understand it > > pretty well, but please allow me to ask a question here. Will this > > I'm doing my best but there are so many dependencies and side effects in > the code.. DDlog might actually help with that, eventually. It should allow us to program in the problem domain, rather than writing a lot of code to manage dependencies. > > always manage to come up to date with some version of the sb, or is > > there a chance that it never will report a consistent value if the sb > > keeps changing quickly? I wasn't able to figure that out with a quick > > look. > > > > Now, back to your question: > > TLDR: If ovn-controller has to continuously change its monitor > conditions I *think* there is a chance that it will never report that is > caught up with a specific SB seqno. However, I tried various scenarios > (with quick SB updates or claiming/releasing OVS interfaces in quick > succession) and I didn't manage to make "ovn-nbctl --wait=hv sync" block > indefinitely. That's good, empirically. > Moreover, I think the question is if it's correct for ovn-controller to > report it has caught up if there are unseen SB flows that correspond to > its currently requested but not acked monitor condition? I think the answer is "no", which means that the next question is, how do we implement it properly? I don't have an immediate answer. The database interfacing code is rather complex these days. ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH v5 ovn 1/2] northd: Fair ACL log meters.
On Thu, Nov 19, 2020 at 02:31:04PM +0530, Numan Siddique wrote: > Thanks for v5. This patch doesn't apply cleanly on the latest master. > > I'd suggest to post the patch 1 was an independent patch rebased on on > top of latest master > > I think you can submit the patch 2 once the patch 1 is accepted , > either as part of ddlog patch series > or after the ddlog patches are merged. Yeah, I wouldn't worry about the ddlog patch. I'm happy to help shepherd that in after the initial patch goes in. ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH ovn v7 5/5] ovn-northd-ddlog: New implementation of ovn-northd based on ddlog.
On Thu, Nov 19, 2020 at 09:11:38AM +0100, Dumitru Ceara wrote: > On 11/19/20 6:13 AM, Ben Pfaff wrote: > > From: Leonid Ryzhyk > > > > This implementation is incremental, meaning that it only recalculates > > what is needed for the southbound database when northbound changes > > occur. It is expected to scale better than the C implementation, > > for large deployments. (This may take testing and tuning to be > > effective.) > > > > There are three tests that I'm having mysterious trouble getting > > to work with DDlog. For now, I've marked the testsuite to skip > > them unless RUN_ANYWAY=yes is set in the environment. > > > > Signed-off-by: Leonid Ryzhyk > > Co-authored-by: Justin Pettit > > Signed-off-by: Justin Pettit > > Co-authored-by: Ben Pfaff > > Signed-off-by: Ben Pfaff > > Acked-by: Dumitru Ceara > > Hi Ben, > > This is not a review, just a note that my "Acked-by" should probably go > to patch 2/5 "tests: Prepare for multiple northd types.". Unless I'm > mistaken, I didn't review the last patch of the series yet, except the > fact that I tried running the OVN tests. > > I'm not saying patch 5/5 "ovn-northd-ddlog: New implementation of > ovn-northd based on ddlog." is not good, just that I didn't review it yet :) Thanks, I misunderstood. I'll move the ack. ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH] Allow to create tunnel ports with the same config
On Thu, Nov 19, 2020 at 08:31:44AM -0500, Ihar Hrachyshka wrote: > On Thu, Nov 19, 2020 at 12:51 AM Ben Pfaff wrote: > > > > On Wed, Nov 18, 2020 at 10:35:01PM -0500, Ihar Hrachyshka wrote: > > > It's a legal setup where tunnel ports with the same config are created > > > on different bridges served by Open vSwitch. Specifically, multiple > > > OVN controllers may emulate multiple chassis running on the same > > > physical host, in which case they may need to create separate tunnel > > > ports to connect to the same remote chassis on their respective > > > bridges. > > > > > > Signed-off-by: Ihar Hrachyshka > > > > That makes sense for sending packets, but which one is supposed to > > receive a packet when one arrives for that tunnel? > > > > If we are talking in OVN context, each virtual ovn-controller chassis > on the same host has to have a different IP / port to distinguish > between chassis. I don't think it's a useful configuration to have two > two incoming tunnel ports with the same config for the same IP that > are not served by separate DST IP addresses. I think that this code rejects tunnel ports with exactly the same configuration, though. If the two ports were configured with different local IP addresses, then this code would not flag a conflict. Do I misunderstand? ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] Bug#974588: openvswitch: DPDK 20.11 support and transition for bullseye
> > I proposed an earlier upload from git as a temporary measure to ease > > the ABI transition. I worry that an ABI transition 2 months after the > > transition freeze is too much to ask, even if it only affects > > src:openvswitch (and src:collectd, but that's a straightforward > > rebuild, no changes needed). > > Nonetheless, let's see if the release team considers this acceptable. > > Two things worth mentioning: > 1. We will have support for DPDK 20.11 in OVS by next week by Ian Stokes > This was already validated vs 20.11-rc4 Hi Christian, Just to clarify this, I think we will have an RFC patch to support DPDK 20.11 with OVS master by either tomorrow or early next week. We are just waiting on review of the patch below http://patchwork.ozlabs.org/project/openvswitch/patch/20201119123554.44684-1-sunil.pa...@intel.com/ But just to clarify, once I release the RFC patch that does not mean it will be up streamed immediately to OVS master, just that it will be available for review by the community at that stage. Support for DPDK 20.11 in OVS master will not be available until the community has signed off on the patch itself (which may require patch revisions), this may take longer than next week. Regards Ian ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] Bug#974588: openvswitch: DPDK 20.11 support and transition for bullseye
... > I proposed an earlier upload from git as a temporary measure to ease > the ABI transition. I worry that an ABI transition 2 months after the > transition freeze is too much to ask, even if it only affects > src:openvswitch (and src:collectd, but that's a straightforward > rebuild, no changes needed). > Nonetheless, let's see if the release team considers this acceptable. Two things worth mentioning: 1. We will have support for DPDK 20.11 in OVS by next week by Ian Stokes This was already validated vs 20.11-rc4 2. On the approach of "upload from git in January to meet Feature Freeze and then the final version later" I wanted to state that Ubuntu did upload OVS that way for years and never had problems. OVS git branches at that time are fairly stable and the commits landing after Feature Freeze are usually fine to do so. So this approach is not an experiment to meet the deadline, but a common practise ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] What we cherish most of all are our customers! That's why we organize this clearance sale!
Great service. Speedy delivery! "Excellent service. Excellent product!" - By Jacob ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] Bug#974588: openvswitch: DPDK 20.11 support and transition for bullseye
> > Also, I would very much like to have OVS and OVN being packaged and > > maintained on both Ubuntu and Debian the same way. I would very much > > like if this could happen, because maintaining OVS is hard, and I really > > feel alone doing it. Your thoughts? > > > > Cheers, > > > > Thomas Goirand (zigo) > > I'm sure this could be arranged - after all we already follow the same > model for src:dpdk, where myself and Christian share the workload and > use a common repository for Debian and Ubuntu. > > Christian, would it be possible for you to initiate a discussion with > the relevant people from the Ubuntu side? Sure, I'm only helping there sometimes from the DPDK POV. CC'ing James Page who owns this. ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] Q
-- Greetings, We guess you are healthy and as well coping with the Covid-19 pandemic situation, our office has sent you a message earlier but there is no answer from you, did you read our notice sent to you last week via e-mail message? Yours Faithfully, MR. PETER HAMBROOK IMF OFFICE LONDON UNITED KINGDOM. P. O BOX 6, 1 CHURCHILL PLACE, CANARY WHARF, E14, 1QE ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH] Allow to create tunnel ports with the same config
On Thu, Nov 19, 2020 at 12:51 AM Ben Pfaff wrote: > > On Wed, Nov 18, 2020 at 10:35:01PM -0500, Ihar Hrachyshka wrote: > > It's a legal setup where tunnel ports with the same config are created > > on different bridges served by Open vSwitch. Specifically, multiple > > OVN controllers may emulate multiple chassis running on the same > > physical host, in which case they may need to create separate tunnel > > ports to connect to the same remote chassis on their respective > > bridges. > > > > Signed-off-by: Ihar Hrachyshka > > That makes sense for sending packets, but which one is supposed to > receive a packet when one arrives for that tunnel? > If we are talking in OVN context, each virtual ovn-controller chassis on the same host has to have a different IP / port to distinguish between chassis. I don't think it's a useful configuration to have two two incoming tunnel ports with the same config for the same IP that are not served by separate DST IP addresses. Ihar ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [PATCH dpdk-latest v2] build: Remove DPDK make build references.
Building DPDK using Make is removed since DPDK 20.08.
Hence, remove its references in OVS as well.
Fixes: 540e70fba6d5 ("build: Add support for DPDK meson build.")
Tested-at: https://travis-ci.org/github/Sunil-Pai-G/ovs/builds/742699277
Signed-off-by: Sunil Pai G
---
v1->v2:
- replace python script for pkg-config output parsing
with native linux tools.
---
.travis/linux-build.sh| 4 +-
Documentation/intro/install/afxdp.rst | 2 +-
Documentation/intro/install/dpdk.rst | 75 ++
acinclude.m4 | 89 +--
python/automake.mk| 3 +-
python/build/pkgcfg.py| 30 -
6 files changed, 52 insertions(+), 151 deletions(-)
delete mode 100644 python/build/pkgcfg.py
diff --git a/.travis/linux-build.sh b/.travis/linux-build.sh
index 917bbf962..e085780e9 100755
--- a/.travis/linux-build.sh
+++ b/.travis/linux-build.sh
@@ -145,12 +145,12 @@ function install_dpdk()
CC=gcc meson $DPDK_OPTS build
ninja -C build
-sudo ninja -C build install
+ninja -C build install
# Update the library paths.
sudo ldconfig
-echo "Installed DPDK source"
+echo "Installed DPDK source in $(pwd)"
popd
echo "${DPDK_VER}" > ${VERSION_FILE}
}
diff --git a/Documentation/intro/install/afxdp.rst
b/Documentation/intro/install/afxdp.rst
index 327f2b3df..aad0aeebe 100644
--- a/Documentation/intro/install/afxdp.rst
+++ b/Documentation/intro/install/afxdp.rst
@@ -396,7 +396,7 @@ PVP using vhostuser device
--
First, build OVS with DPDK and AFXDP::
- ./configure --enable-afxdp --with-dpdk=shared|static|
+ ./configure --enable-afxdp --with-dpdk=shared|static
make -j4 && make install
Create a vhost-user port from OVS::
diff --git a/Documentation/intro/install/dpdk.rst
b/Documentation/intro/install/dpdk.rst
index 7a1852bc5..46419d9f9 100644
--- a/Documentation/intro/install/dpdk.rst
+++ b/Documentation/intro/install/dpdk.rst
@@ -80,62 +80,37 @@ Install DPDK
#. Configure and install DPDK using Meson
- Meson is the preferred tool to build recent DPDK releases
- as Make support is deprecated and will be removed from DPDK 20.11.
- OVS supports DPDK Meson builds from DPDK 19.11 onwards.
-
Build and install the DPDK library::
- $ export DPDK_TARGET=x86_64-native-linuxapp-gcc
- $ export DPDK_BUILD=$DPDK_DIR/$DPDK_TARGET
- $ meson $DPDK_TARGET
- $ ninja -C $DPDK_TARGET
- $ sudo ninja -C $DPDK_TARGET install
+ $ export DPDK_BUILD=$DPDK_DIR/build
+ $ meson build
+ $ ninja -C build
+ $ sudo ninja -C build install
$ sudo ldconfig
Detailed information can be found at `DPDK documentation`_.
-#. (Optional) Configure DPDK as a shared library
+#. (Optional) Configure and export the DPDK shared library location
+
+ Since DPDK is built both as static and shared library by default, no extra
+ configuration is required for the build.
- When using Meson, DPDK is built both as static and shared library.
- So no extra configuration is required in this case.
+ Exporting the path to library is not necessary if the DPDK libraries are
+ system installed. For libraries installed using a prefix
+ (assuming $DPDK_INSTALL in the below case), export the path to this
+ library and also update the $PKG_CONFIG_PATH for use before building OVS::
- In case of Make, DPDK can be built as either a static library or a shared
- library. By default, it is configured for the former. If you wish to use
- the latter, set
- ``CONFIG_RTE_BUILD_SHARED_LIB=y`` in ``$DPDK_DIR/config/common_base``.
+ $ export LD_LIBRARY_PATH=$DPDK_INSTALL/lib/x86_64-linux-gnu/
+ $ export PKG_CONFIG_PATH=$DPDK_INSTALL/lib/x86_64-linux-gnu/pkgconfig/
.. note::
Minor performance loss is expected when using OVS with a shared DPDK
library compared to a static DPDK library.
-#. Configure and install DPDK using Make
-
- Build and install the DPDK library::
-
- $ export DPDK_TARGET=x86_64-native-linuxapp-gcc
- $ export DPDK_BUILD=$DPDK_DIR/$DPDK_TARGET
- $ make install T=$DPDK_TARGET DESTDIR=install
-
-#. (Optional) Export the DPDK shared library location
-
- If DPDK was built as a shared library using Make, export the path to this
- library for use when building OVS::
-
- $ export LD_LIBRARY_PATH=$DPDK_DIR/x86_64-native-linuxapp-gcc/lib
-
- In case of Meson, exporting the path to library is not necessary if
- the DPDK libraries are system installed. For libraries installed using
- a prefix(assuming $DPDK_INSTALL in the below case), export the path to this
- library and also update the $PKG_CONFIG_PATH for use before building OVS::
-
- $ export $DPDK_LIB=$DPDK_INSTALL/lib/x86_64-linux-gnu
- $ export LD_LIBRARY_PATH=$DPDK_LIB/:$LD_LIBRARY_PATH
- $ export PKG_CONFIG_PATH=$DPDK_LIB/pkgconfig/:$PKG_CONFIG_PATH
-
.. _DPDK s
Re: [ovs-dev] [PATCH ovn v2] ovn-controller: Fix nb_cfg update with monitor_cond_change in flight.
On 11/19/20 5:15 AM, Ben Pfaff wrote:
> On Tue, Nov 17, 2020 at 05:50:20PM +0100, Dumitru Ceara wrote:
>> It is not correct for ovn-controller to pass the current SB_Global.nb_cfg
>> value to ofctrl_put() if there are pending changes to conditional
>> monitoring clauses (local or in flight). It might be that after the
>> monitor condition is acked by the SB, records that were added to the SB
>> before SB_Global.nb_cfg was set are now sent as updates to
>> ovn-controller. These should be first installed in OVS before
>> ovn-controller reports that it caught up with the current
>> SB_Global.nb_cfg value.
>>
>> Also, ofctrl_put should not advance cur_cfg if there are flow updates in
>> flight.
>>
>> Fixes: ca278d98a4f5 ("ovn-controller: Initial use of incremental engine -
>> quiet mode.")
>> Signed-off-by: Dumitru Ceara
>>
>> ---
>> v2:
>> - use new IDL *set_condition() return value.
>> - fix ofctrl_put to not advance cur_cfg if there are flow updates in
>> flight.
>
> ovn-controller has changed (advanced?) to the point that I have trouble
I would say "became more complex"..
> understanding the code now. I'm going to assume that you understand it
> pretty well, but please allow me to ask a question here. Will this
I'm doing my best but there are so many dependencies and side effects in
the code..
> always manage to come up to date with some version of the sb, or is
> there a chance that it never will report a consistent value if the sb
> keeps changing quickly? I wasn't able to figure that out with a quick
> look.
>
Now, back to your question:
TLDR: If ovn-controller has to continuously change its monitor
conditions I *think* there is a chance that it will never report that is
caught up with a specific SB seqno. However, I tried various scenarios
(with quick SB updates or claiming/releasing OVS interfaces in quick
succession) and I didn't manage to make "ovn-nbctl --wait=hv sync" block
indefinitely.
Moreover, I think the question is if it's correct for ovn-controller to
report it has caught up if there are unseen SB flows that correspond to
its currently requested but not acked monitor condition?
Long version:
The main processing loop in ovn-controller looks something like this:
a. In the beginning of the loop monitor_cond_change requests (due to the
previous iteration) are sent when ovsdb_idl_loop_run(&ovnsb_idl_loop) is
executed. monitor_cond_change replies for older requests are also
handled here.
b. Local datapaths (along with a lot of other stuff) are updated inside
the incremental processing engine in engine_run().
c. ovn-controller requests OVS to update flows using as barrier seqno
the last nb_cfg value read when no monitor_cond_change was pending.
d. Then monitor conditions are changed (if local datapaths have changed)
in update_sb_monitors().
e. Get the last seqno confirmed by OVS (ofctrl_get_cur_cfg()) and store
it in chassis_private.nb_cfg.
If in every iteration at step "b" above local datapaths change (due to
SB changes or OVS interfaces being claimed/released) then in the next
iteration we'll be requesting a cond change at step "a".
If at some point at step "a" SB_Global.nb_cfg gets updated, this won't
get propagated to ofctrl in step "c" until monitor conditions stop
changing for at least one iteration.
However, in practice:
- If SB changes cause monitor_cond_change that means port_bindings are
being added/deleted/updated but that can happen, I *think*, only with
ovn-northd intervention but ovn-northd should be already waiting for
ovn-controller to catch up "ovn-nbctl --wait=hv sync".
- If OVS ports are continuously claimed/released I think it's safe to
assume that ovn-controller is never really up to date with the contents
of the SB.
Another issue i see now is that steps "c" and "d" should probably be
swapped. I can do that in a v3 if you're OK with the new semantics of
nb_cfg.
P.S.: Sorry for the long email.
Regards,
Dumitru
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH] checkpatch: Add check for a whitespace after cast.
> Coding style says: "Put a space between the ``()`` used in a cast and > the expression whose type is cast: ``(void *) 0``.". > This style rule is frequently overlooked. Let's check for it. > > Signed-off-by: Ilya Maximets Hi Ilya, Thanks for the patch, it's a nice addition to checkpatch, tested on myside and works as expected, LGTM. Acked-by: Ian Stokes Regards Ian ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] Established biz - $24.99/mo Credit Card Processing 0.79% for 2021 - unlimited flat-fee
Paying more than $500/month in Visa/MasterCard Credit Card Processing Fees? Give me 3 minutes to explain your alternative. 1) How much of your profit margin is 'spent' on fees every month? Tired of paying? Your processor isn't telling you about all the available options. Why don't they offer you zero-fee processing? They can't. Why? Their equipment is old. Their system is rigid. And you keep paying. Use the new laws - you can demand zero-fee cash discount processing. 2) Here's how it works. (Thanks to US Law: 15 U. S. Code § 1693o– 2): You Get: Unlimited Flat-Fee Processing for only $24. 99 per month. - Your business gets unlimited credit card processing. - Same flat fee each month - unlimited transactions. - We cover equipment fees - you start off with a free terminal - no rental fees. - No surprises - only our 'No Contract Policy' Click To Reply To This Email - Send us a name & phone number. October 2020 Promotion: 3) Our October Promotion - First-Come-First-Serve: Email us today - and here' s what we' re offering: Free Equipment (No Rental-Fees on Terminals). Only 30-Day Commitment Needed. No Cancellation Fees. Try Without Obligation. What steps do I need to take? 1) Email us a name/number. 2) Don't cancel your current processor. 3) Place our new terminal right next to your old one. 4) Try us out. Risk free. No obligation. 5) Not happy? We'll come get our equipment. Click to send a quick email: I'm interested. Best, Anne (Image of our most popular equipment & processing terminals. ) To Unsubscribe you must click the Unsubscribe link here. This is an automated system - emails or replies with " stop" or " remove" do not work. Your request will be handled promptly but please allow 1-3 days for complete removal. You may also write to the address below: 8 The Green STE 8 - Dover, DE 19901 ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] OVS-DPDK patch review list update
> On 11/18/20 8:54 PM, Stokes, Ian wrote: > > Hi All, > > > > Please see the updated patch review list from this week's call. > > > > Regards > > Ian > > > > > > Patch List > > > > Stats to Date for patch series > > > > Merged: 9 > > Merge Candidate: 0 > > Review in progress: 4 > > No review in progress: 2 > > Deferred: 3 > > Dropped: 2 > > > > > > > > === Merge Candidate (Close to merging) === > > N/A > > > > > > === Review In Progress === > > > > name: ofproto-dpif-xlate: Do not use zero-weight buckets in select groups. > > href: https://patchwork.ozlabs.org/project/openvswitch/list/?series=112576 > > subm: Ben Pfaff (OVN) > > why?: looks correct, still valid, Ilya validated but no response afterward, > > get > closure. > > Status: Needs review and rebase but close to merging. Needs external review > (prioritize) > > --- > > > > name: dpdk: Support running PMD threads on any core. > > href: > http://patchwork.ozlabs.org/project/openvswitch/patch/20201102131045.1041 > 0-1-david.march...@redhat.com/ > > subm: David Marchand (RH) > > why?: v4 submitted addressing comments on v3. > > Status: Review ongoing, targeting dpdk-latest branch. > > --- > > > > name: build: Remove DPDK make build references. > > href: https://patchwork.ozlabs.org/project/openvswitch/list/?series=213639 > > subm: Sunil Pai G (Intel) > > why?: Should be included with RFC patch to move OVS master to 20.11. > > Status: Reviewed by Intel, awaiting comments from Ilya. > > --- > > > > name: python: Update build system to ensure dirs.py is created > > href: http://patchwork.ozlabs.org/project/openvswitch/list/?series=215046 > > subm: Mark Gray (RH) > > why?: Required to fix windows build. > > Status: v2 submitted, feedback provided by Ilya. > > --- > > > > > > > > === Not Reviewed (No review in progress) === > > > > name: bond/mirror: fix duplicate output when mix bond and mirror > > href: > https://patchwork.ozlabs.org/project/openvswitch/patch/SG2PR03MB396067B > 6740f08908f2bb1b9b6...@sg2pr03mb3960.apcprd03.prod.outlook.com/ > > subm: Shuang Huang > > why?: Bug fix > > Status: Needs review > > --- > > > > name: ovsdb-idl.at: Return stream open_block python tests. > > href: > https://patchwork.ozlabs.org/project/openvswitch/patch/20200904115126.353 > 935-1-i.maxim...@ovn.org/ > > Subm: Ilya > > Why: Bug fix > > Status: Needs review > > This one already reviewed and merged. > > Best regards, Ilya Maximets. Apologies Ilya, I missed that, thanks for flagging, I'll update this. Regards Ian ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [PATCH net] net: openvswitch: fix TTL decrement action netlink message format
Currently, the openvswitch module is not accepting the correctly formated
netlink message for the TTL decrement action. For both setting and getting
the dec_ttl action, the actions should be nested in the
OVS_DEC_TTL_ATTR_ACTION attribute as mentioned in the openvswitch.h uapi.
Fixes: 744676e77720 ("openvswitch: add TTL decrement action")
Signed-off-by: Eelco Chaudron
---
include/uapi/linux/openvswitch.h |2 +
net/openvswitch/actions.c|7 ++--
net/openvswitch/flow_netlink.c | 74 --
3 files changed, 60 insertions(+), 23 deletions(-)
diff --git a/include/uapi/linux/openvswitch.h b/include/uapi/linux/openvswitch.h
index 8300cc29dec8..8d16744edc31 100644
--- a/include/uapi/linux/openvswitch.h
+++ b/include/uapi/linux/openvswitch.h
@@ -1058,4 +1058,6 @@ enum ovs_dec_ttl_attr {
__OVS_DEC_TTL_ATTR_MAX
};
+#define OVS_DEC_TTL_ATTR_MAX (__OVS_DEC_TTL_ATTR_MAX - 1)
+
#endif /* _LINUX_OPENVSWITCH_H */
diff --git a/net/openvswitch/actions.c b/net/openvswitch/actions.c
index b87bfc82f44f..5829a020b81c 100644
--- a/net/openvswitch/actions.c
+++ b/net/openvswitch/actions.c
@@ -958,14 +958,13 @@ static int dec_ttl_exception_handler(struct datapath *dp,
struct sk_buff *skb,
{
/* The first action is always 'OVS_DEC_TTL_ATTR_ARG'. */
struct nlattr *dec_ttl_arg = nla_data(attr);
- int rem = nla_len(attr);
if (nla_len(dec_ttl_arg)) {
- struct nlattr *actions = nla_next(dec_ttl_arg, &rem);
+ struct nlattr *actions = nla_data(dec_ttl_arg);
if (actions)
- return clone_execute(dp, skb, key, 0, actions, rem,
-last, false);
+ return clone_execute(dp, skb, key, 0, nla_data(actions),
+nla_len(actions), last, false);
}
consume_skb(skb);
return 0;
diff --git a/net/openvswitch/flow_netlink.c b/net/openvswitch/flow_netlink.c
index 9d3e50c4d29f..ec0689ddc635 100644
--- a/net/openvswitch/flow_netlink.c
+++ b/net/openvswitch/flow_netlink.c
@@ -2503,28 +2503,42 @@ static int validate_and_copy_dec_ttl(struct net *net,
__be16 eth_type, __be16 vlan_tci,
u32 mpls_label_count, bool log)
{
- int start, err;
- u32 nested = true;
+ const struct nlattr *attrs[OVS_DEC_TTL_ATTR_MAX + 1];
+ int start, action_start, err, rem;
+ const struct nlattr *a, *actions;
+
+ memset(attrs, 0, sizeof(attrs));
+ nla_for_each_nested(a, attr, rem) {
+ int type = nla_type(a);
- if (!nla_len(attr))
- return ovs_nla_add_action(sfa, OVS_ACTION_ATTR_DEC_TTL,
- NULL, 0, log);
+ /* Ignore unknown attributes to be future proof. */
+ if (type > OVS_DEC_TTL_ATTR_MAX)
+ continue;
+
+ if (!type || attrs[type])
+ return -EINVAL;
+
+ attrs[type] = a;
+ }
+
+ actions = attrs[OVS_DEC_TTL_ATTR_ACTION];
+ if (rem || !actions || (nla_len(actions) && nla_len(actions) <
NLA_HDRLEN))
+ return -EINVAL;
start = add_nested_action_start(sfa, OVS_ACTION_ATTR_DEC_TTL, log);
if (start < 0)
return start;
- err = ovs_nla_add_action(sfa, OVS_DEC_TTL_ATTR_ACTION, &nested,
-sizeof(nested), log);
-
- if (err)
- return err;
+ action_start = add_nested_action_start(sfa, OVS_DEC_TTL_ATTR_ACTION,
log);
+ if (action_start < 0)
+ return start;
- err = __ovs_nla_copy_actions(net, attr, key, sfa, eth_type,
+ err = __ovs_nla_copy_actions(net, actions, key, sfa, eth_type,
vlan_tci, mpls_label_count, log);
if (err)
return err;
+ add_nested_action_end(*sfa, action_start);
add_nested_action_end(*sfa, start);
return 0;
}
@@ -3487,20 +3501,42 @@ static int check_pkt_len_action_to_attr(const struct
nlattr *attr,
static int dec_ttl_action_to_attr(const struct nlattr *attr,
struct sk_buff *skb)
{
- int err = 0, rem = nla_len(attr);
- struct nlattr *start;
+ struct nlattr *start, *action_start;
+ const struct nlattr *a;
+ int err = 0, rem;
start = nla_nest_start_noflag(skb, OVS_ACTION_ATTR_DEC_TTL);
-
if (!start)
return -EMSGSIZE;
- err = ovs_nla_put_actions(nla_data(attr), rem, skb);
- if (err)
- nla_nest_cancel(skb, start);
- else
- nla_nest_end(skb, start);
+ nla_for_each_attr(a, nla_data(attr), nla_len(attr), rem) {
+ switch (nla_type(a)) {
+ case OVS_DEC_TTL_ATTR_ACTION:
+
+ ac
Re: [ovs-dev] [PATCH v2] python: Update build system to ensure dirs.py is created
On 18/11/2020 15:11, Ilya Maximets wrote:
> On 11/17/20 7:02 PM, Mark Gray wrote:
>> Update build system to ensure dirs.py is created when it is a
>> dependency for a build target. Also, update setup.py to
>> check for that dependency.
>>
>> Signed-off-by: Mark Gray
>> ---
>>
>> v2: Added v2 tag
>>
>> lib/automake.mk | 2 +-
>> python/automake.mk| 24
>> python/ovs/.gitignore | 2 +-
>> python/setup.py | 9 +
>> tests/automake.mk | 2 +-
>> vtep/automake.mk | 2 +-
>> 6 files changed, 25 insertions(+), 16 deletions(-)
>>
>> diff --git a/lib/automake.mk b/lib/automake.mk
>> index 8eeb6c3f676c..fad6ffb40cef 100644
>> --- a/lib/automake.mk
>> +++ b/lib/automake.mk
>> @@ -629,7 +629,7 @@ EXTRA_DIST += build-aux/extract-ofp-msgs
>> # _server IDL
>> OVSIDL_BUILT += lib/ovsdb-server-idl.c lib/ovsdb-server-idl.h
>> lib/ovsdb-server-idl.ovsidl
>> EXTRA_DIST += lib/ovsdb-server-idl.ann
>> -lib/ovsdb-server-idl.ovsidl: ovsdb/_server.ovsschema
>> lib/ovsdb-server-idl.ann
>> +lib/ovsdb-server-idl.ovsidl: ovsdb/_server.ovsschema
>> lib/ovsdb-server-idl.ann python/ovs/dirs.py
Thanks for the quick review Ilya
>
> What about dependency for lib/vswitch-idl.ovsidl and tests/idltest.ovsidl?
lib/vswitch-idl.ovsidl this was actually covered in the previous patch.
The tests one is below.
> I think it's better to add dependency directly for ovsdb/ovsdb-idlc.in or
> at least to $(OVSIDL_BUILT) target and not fix every single case.
Absolutely. Much cleaner - dont know why I didn't do that from the
start. See follow-up:
https://patchwork.ozlabs.org/project/openvswitch/patch/20201119084434.461714-1-mark.d.g...@redhat.com/
>
>> $(AM_V_GEN)$(OVSDB_IDLC) annotate $(srcdir)/ovsdb/_server.ovsschema
>> $(srcdir)/lib/ovsdb-server-idl.ann > $@.tmp && mv $@.tmp $@
>>
>> INSTALL_DATA_LOCAL += lib-install-data-local
>> diff --git a/python/automake.mk b/python/automake.mk
>> index c4382ec60928..767512f1757f 100644
>> --- a/python/automake.mk
>> +++ b/python/automake.mk
>> @@ -74,12 +74,12 @@ ovs-install-data-local:
>> $(MKDIR_P) python/ovs
>> sed \
>> -e '/^##/d' \
>> --e 's,[@]pkgdatadir[@],$(pkgdatadir),g' \
>> --e 's,[@]RUNDIR[@],$(RUNDIR),g' \
>> --e 's,[@]LOGDIR[@],$(LOGDIR),g' \
>> --e 's,[@]bindir[@],$(bindir),g' \
>> --e 's,[@]sysconfdir[@],$(sysconfdir),g' \
>> --e 's,[@]DBDIR[@],$(DBDIR),g' \
>> +-e 's,[@]pkgdatadir[@],$(pkgdatadir),g' \
>> +-e 's,[@]RUNDIR[@],$(RUNDIR),g' \
>> +-e 's,[@]LOGDIR[@],$(LOGDIR),g' \
>> +-e 's,[@]bindir[@],$(bindir),g' \
>> +-e 's,[@]sysconfdir[@],$(sysconfdir),g' \
>> +-e 's,[@]DBDIR[@],$(DBDIR),g' \
>> < $(srcdir)/python/ovs/dirs.py.template \
>> > python/ovs/dirs.py.tmp
>> $(MKDIR_P) $(DESTDIR)$(pkgdatadir)/python/ovs
>> @@ -107,12 +107,12 @@ ALL_LOCAL += $(srcdir)/python/ovs/dirs.py
>> $(srcdir)/python/ovs/dirs.py: python/ovs/dirs.py.template
>> $(AM_V_GEN)sed \
>> -e '/^##/d' \
>> --e 's,[@]pkgdatadir[@],$(pkgdatadir),g' \
>> --e 's,[@]RUNDIR[@],$(RUNDIR),g' \
>> --e 's,[@]LOGDIR[@],$(LOGDIR),g' \
>> --e 's,[@]bindir[@],$(bindir),g' \
>> --e 's,[@]sysconfdir[@],$(sysconfdir),g' \
>> --e 's,[@]DBDIR[@],$(sysconfdir)/openvswitch,g' \
>> +-e 's,[@]pkgdatadir[@],$(pkgdatadir),g' \
>> +-e 's,[@]RUNDIR[@],$(RUNDIR),g' \
>> +-e 's,[@]LOGDIR[@],$(LOGDIR),g' \
>> +-e 's,[@]bindir[@],$(bindir),g' \
>> +-e 's,[@]sysconfdir[@],$(sysconfdir),g' \
>> +-e 's,[@]DBDIR[@],$(sysconfdir)/openvswitch,g' \
>> < $? > $@.tmp && \
>> mv $@.tmp $@
>> EXTRA_DIST += python/ovs/dirs.py.template
>> diff --git a/python/ovs/.gitignore b/python/ovs/.gitignore
>> index 51030beca437..8bbcd824f472 100644
>> --- a/python/ovs/.gitignore
>> +++ b/python/ovs/.gitignore
>> @@ -1,2 +1,2 @@
>> version.py
>> -dir.py
>> +dirs.py
>> diff --git a/python/setup.py b/python/setup.py
>> index b7252800c1c1..d385d8372239 100644
>> --- a/python/setup.py
>> +++ b/python/setup.py
>> @@ -30,6 +30,15 @@ except IOError:
>>file=sys.stderr)
>> sys.exit(-1)
>>
>> +try:
>> +# Try to open generated ovs/dirs.py. However, in this case we
>> +# don't need to exec()
>> +open("ovs/dirs.py")
>> +except IOError:
>> +print("Ensure dirs.py is created by running make python/ovs/dirs.py",
>> + file=sys.stderr)
>> +sys.exit(-1)
>> +
>> ext_errors = (CCompilerError, DistutilsExecError, DistutilsPlatformError)
>> if sys.platform == 'win32':
>> ext_errors += (IOError, ValueError)
>> diff --git a/tests/automake.mk b/tests/automake.mk
>> index 677b99a6b487..3faa7395a157 100644
>> --- a/tests/automake.mk
>> +++ b/tests/a
[ovs-dev] [PATCH v3] python: Update build system to ensure dirs.py is created
Update build system to ensure dirs.py is created when it is a
dependency for a build target. Also, update setup.py to
check for that dependency.
Signed-off-by: Mark Gray
---
v2: Added v2 tag
v3: Updated as per Ilya's comments
lib/automake.mk | 2 +-
ovsdb/automake.mk | 2 +-
python/automake.mk| 24
python/ovs/.gitignore | 2 +-
python/setup.py | 9 +
5 files changed, 24 insertions(+), 15 deletions(-)
diff --git a/lib/automake.mk b/lib/automake.mk
index 8eeb6c3f676c..380a672287ac 100644
--- a/lib/automake.mk
+++ b/lib/automake.mk
@@ -575,7 +575,7 @@ MAN_FRAGMENTS += \
OVSIDL_BUILT += lib/vswitch-idl.c lib/vswitch-idl.h lib/vswitch-idl.ovsidl
EXTRA_DIST += lib/vswitch-idl.ann
-lib/vswitch-idl.ovsidl: vswitchd/vswitch.ovsschema lib/vswitch-idl.ann
python/ovs/dirs.py
+lib/vswitch-idl.ovsidl: vswitchd/vswitch.ovsschema lib/vswitch-idl.ann
$(AM_V_GEN)$(OVSDB_IDLC) annotate $(srcdir)/vswitchd/vswitch.ovsschema
$(srcdir)/lib/vswitch-idl.ann > $@.tmp && mv $@.tmp $@
lib/dirs.c: lib/dirs.c.in Makefile
diff --git a/ovsdb/automake.mk b/ovsdb/automake.mk
index b895f42925ef..d60f3f4ec8cb 100644
--- a/ovsdb/automake.mk
+++ b/ovsdb/automake.mk
@@ -106,7 +106,7 @@ CLEANFILES += $(OVSIDL_BUILT)
# However, current versions of Automake seem to output all variable
# assignments before any targets, so it doesn't seem to be a problem,
# at least for now.
-$(OVSIDL_BUILT): ovsdb/ovsdb-idlc.in
+$(OVSIDL_BUILT): ovsdb/ovsdb-idlc.in python/ovs/dirs.py
# ovsdb-doc
EXTRA_DIST += ovsdb/ovsdb-doc
diff --git a/python/automake.mk b/python/automake.mk
index c4382ec60928..767512f1757f 100644
--- a/python/automake.mk
+++ b/python/automake.mk
@@ -74,12 +74,12 @@ ovs-install-data-local:
$(MKDIR_P) python/ovs
sed \
-e '/^##/d' \
--e 's,[@]pkgdatadir[@],$(pkgdatadir),g' \
--e 's,[@]RUNDIR[@],$(RUNDIR),g' \
--e 's,[@]LOGDIR[@],$(LOGDIR),g' \
--e 's,[@]bindir[@],$(bindir),g' \
--e 's,[@]sysconfdir[@],$(sysconfdir),g' \
--e 's,[@]DBDIR[@],$(DBDIR),g' \
+ -e 's,[@]pkgdatadir[@],$(pkgdatadir),g' \
+ -e 's,[@]RUNDIR[@],$(RUNDIR),g' \
+ -e 's,[@]LOGDIR[@],$(LOGDIR),g' \
+ -e 's,[@]bindir[@],$(bindir),g' \
+ -e 's,[@]sysconfdir[@],$(sysconfdir),g' \
+ -e 's,[@]DBDIR[@],$(DBDIR),g' \
< $(srcdir)/python/ovs/dirs.py.template \
> python/ovs/dirs.py.tmp
$(MKDIR_P) $(DESTDIR)$(pkgdatadir)/python/ovs
@@ -107,12 +107,12 @@ ALL_LOCAL += $(srcdir)/python/ovs/dirs.py
$(srcdir)/python/ovs/dirs.py: python/ovs/dirs.py.template
$(AM_V_GEN)sed \
-e '/^##/d' \
--e 's,[@]pkgdatadir[@],$(pkgdatadir),g' \
--e 's,[@]RUNDIR[@],$(RUNDIR),g' \
--e 's,[@]LOGDIR[@],$(LOGDIR),g' \
--e 's,[@]bindir[@],$(bindir),g' \
--e 's,[@]sysconfdir[@],$(sysconfdir),g' \
--e 's,[@]DBDIR[@],$(sysconfdir)/openvswitch,g' \
+ -e 's,[@]pkgdatadir[@],$(pkgdatadir),g' \
+ -e 's,[@]RUNDIR[@],$(RUNDIR),g' \
+ -e 's,[@]LOGDIR[@],$(LOGDIR),g' \
+ -e 's,[@]bindir[@],$(bindir),g' \
+ -e 's,[@]sysconfdir[@],$(sysconfdir),g' \
+ -e 's,[@]DBDIR[@],$(sysconfdir)/openvswitch,g' \
< $? > $@.tmp && \
mv $@.tmp $@
EXTRA_DIST += python/ovs/dirs.py.template
diff --git a/python/ovs/.gitignore b/python/ovs/.gitignore
index 51030beca437..8bbcd824f472 100644
--- a/python/ovs/.gitignore
+++ b/python/ovs/.gitignore
@@ -1,2 +1,2 @@
version.py
-dir.py
+dirs.py
diff --git a/python/setup.py b/python/setup.py
index b7252800c1c1..d385d8372239 100644
--- a/python/setup.py
+++ b/python/setup.py
@@ -30,6 +30,15 @@ except IOError:
file=sys.stderr)
sys.exit(-1)
+try:
+# Try to open generated ovs/dirs.py. However, in this case we
+# don't need to exec()
+open("ovs/dirs.py")
+except IOError:
+print("Ensure dirs.py is created by running make python/ovs/dirs.py",
+ file=sys.stderr)
+sys.exit(-1)
+
ext_errors = (CCompilerError, DistutilsExecError, DistutilsPlatformError)
if sys.platform == 'win32':
ext_errors += (IOError, ValueError)
--
2.26.2
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] 【重要なお知らせ】カード情報更新のお知らせ
楽天カードからのお知らせ 楽天カードアプリ ｜ 楽天e-NAVI 【重要なお知らせ】カード情報更新のお知らせ 楽天市場のお客様 残念ながら、あなたのアカウントが 楽天会員のカード情報を更新できませんでした。 これは、カードが期限切れになったか、請求先住所が変更されたなど、さまざまな理由で発生する可能性があります。 アカウント情報の一部が誤っているため、お客様のアカウントを維持するために、楽天会員のカード情報を確認する必要があります。今アカウントを確認できます。 [AUTOVALS2] 楽天市場ログイン なお、24時間以内にご確認できない場合、誠に勝手ながら、アカウントをロックさせていただくことを警告いたします。どうぞよろしくお願いいたします。 お客様のセキュリティは弊社にとって非常に重要なものでこさいます。ご理解の程、よろしくお願い申し上げます。 本メール内のお客様の漢字氏名が正しく表記されない場合がございます。ご了承ください。 弊社からのメールを希望されない会員様へも重要なお知らせとしてお送りしております。 本メールアドレスは送信専用となり、返信はお受けしておりません。 [AUTOVALS3] 発行元：楽天カード株式会社 楽天カードアプリ ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH ovn v2] ovn-controller: Propagate nb_cfg to the local OVS DB.
On 11/19/20 8:31 AM, Numan Siddique wrote: > On Wed, Nov 18, 2020 at 6:27 PM Dumitru Ceara wrote: >> >> The NB.NB_Global.nb_cfg value gets propagated to >> Chassis_Private.nb_cfg (and then to NB.NB_Global.hv_cfg) as soon as >> ovn-controller has finished installing OVS flows corresponding to >> the NB DB state. >> >> However, if the CMS runs monitoring applications on the chassis itself, >> in order to detect that the NB changes have been applied, it has to >> connect to the NB/SB database. In a scaled deployment this additional >> connection might induce performance issues. >> >> In order to avoid that we now (also) propagate nb_cfg to the local OVS >> DB, in the record corresponding to the integration bridge in table >> Bridge, as external_id "ovn-nb-cfg". >> >> Signed-off-by: Dumitru Ceara > > Thanks for v2. I applied this patch to master. > Thanks! ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH ovn v7 5/5] ovn-northd-ddlog: New implementation of ovn-northd based on ddlog.
On 11/19/20 6:13 AM, Ben Pfaff wrote: > From: Leonid Ryzhyk > > This implementation is incremental, meaning that it only recalculates > what is needed for the southbound database when northbound changes > occur. It is expected to scale better than the C implementation, > for large deployments. (This may take testing and tuning to be > effective.) > > There are three tests that I'm having mysterious trouble getting > to work with DDlog. For now, I've marked the testsuite to skip > them unless RUN_ANYWAY=yes is set in the environment. > > Signed-off-by: Leonid Ryzhyk > Co-authored-by: Justin Pettit > Signed-off-by: Justin Pettit > Co-authored-by: Ben Pfaff > Signed-off-by: Ben Pfaff > Acked-by: Dumitru Ceara Hi Ben, This is not a review, just a note that my "Acked-by" should probably go to patch 2/5 "tests: Prepare for multiple northd types.". Unless I'm mistaken, I didn't review the last patch of the series yet, except the fact that I tried running the OVN tests. I'm not saying patch 5/5 "ovn-northd-ddlog: New implementation of ovn-northd based on ddlog." is not good, just that I didn't review it yet :) Thanks, Dumitru ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
