Re: [ovs-dev] [PATCH ovn v2] controller: Fix wrong controller action definition

On Thu, Aug 18, 2022 at 7:40 AM Mark Michelson wrote: > > Thanks for the fix, Ales. > > Acked-by: Mark Michelson > > On 8/18/22 05:41, Ales Musil wrote: > > The controller action had a wrong wrong userdata_len due to > > missing substraction of previous data len. The pointer to oc > > was not

Re: [ovs-dev] [PATCH ovn] physical.c: Fix heap-buffer-overflow.

On Thu, Aug 18, 2022 at 10:20 PM Ales Musil wrote: > > > > On Fri, Aug 19, 2022 at 4:08 AM Han Zhou wrote: >> >> Fix the problem introduced by commit e52c245136, reported by ASAN for test case: >> "options:activation-strategy for logical port" >> >> ==1480622==ERROR: AddressSanitizer:

Re: [ovs-dev] [PATCH ovn] physical.c: Fix heap-buffer-overflow.

On Fri, Aug 19, 2022 at 4:08 AM Han Zhou wrote: > Fix the problem introduced by commit e52c245136, reported by ASAN for test > case: > "options:activation-strategy for logical port" > > ==1480622==ERROR: AddressSanitizer: heap-buffer-overflow on address > 0x6110c7d0 at pc 0x004fbd91 bp

Re: [ovs-dev] [Patch ovn] physical.c: Fix bug of wrong use in vm migration

On Wed, Aug 17, 2022 at 7:23 PM Numan Siddique wrote: > > On Thu, Aug 18, 2022 at 5:55 AM Mark Michelson wrote: > > > > Thanks for finding and fixing this! > > > > Acked-by: Mark Michelson > > Thanks. I applied this patch to the main branch, > > Numan > A heap-buffer-overflow is detected by

[ovs-dev] [PATCH ovn] physical.c: Fix heap-buffer-overflow.

Fix the problem introduced by commit e52c245136, reported by ASAN for test case: "options:activation-strategy for logical port" ==1480622==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x6110c7d0 at pc 0x004fbd91 bp 0x7ffec4244630 sp 0x7ffec4243de0 READ of size 168 at

Re: [ovs-dev] [PATCH ovn] northd: support vtep LSP-attached LS to use L3 services

On Thu, Aug 18, 2022 at 12:50 PM Vladislav Odintsov wrote: > > > Regards, > Vladislav Odintsov > > On 18 Aug 2022, at 20:07, Han Zhou wrote: > > > > On Thu, Aug 18, 2022 at 8:54 AM Vladislav Odintsov > wrote: > >> Hi Han, >> >> As I could understand, admission control flows were introduced for

Re: [ovs-dev] [PATCH ovn v3 2/5] binding.c: Missing local_datapath update in runtime_data port_binding handler.

On Thu, Aug 18, 2022 at 5:21 PM Han Zhou wrote: > > When handling port_binding changes, it is possible that new > local_datapaths are added, and the fields of the local_datapath, such as > localnet_port, external_ports, etc. need to be updated for the newly > added local_datapaths. > > This

Re: [ovs-dev] [PATCH v6 ovn 2/2] controller: throttle port claim attempts

On Thu, Aug 18, 2022 at 3:00 PM Han Zhou wrote: > > > > On Wed, Aug 17, 2022 at 10:27 AM Ihar Hrachyshka wrote: > > > > Thanks for bringing this up to Mark and Han. I just posted 22.06 and > > 22.03 branch backport series in case they are ok'ed to go. > > > > Ihar > > > > On Sun, Aug 14, 2022 at

Re: [ovs-dev] [PATCH ovn v2 2/4] ovn-controller: Add a generic way to check if the daemon started recently.

On Wed, Aug 17, 2022 at 8:27 AM Dumitru Ceara wrote: > > On 7/25/22 23:34, Han Zhou wrote: > > In some cases we need to know if ovn-controller started long enough and > > has enough iterations of input processing, primarily to ensure it has > > downloaded and handled a complete initial view of

Re: [ovs-dev] [PATCH ovn v2 1/4] binding.c: Missing local_datapath update in runtime_data port_binding handler.

On Wed, Aug 17, 2022 at 8:27 AM Dumitru Ceara wrote: > > On 7/25/22 23:34, Han Zhou wrote: > > When handling port_binding changes, it is possible that new > > local_datapaths are added, and the fields of the local_datapath, such as > > localnet_port, external_ports, etc. need to be updated for

Re: [ovs-dev] [PATCH ovn v2 4/4] vif-plug.c: Use daemon_started_recently() to replace the prime counter.

On Wed, Aug 17, 2022 at 8:27 AM Dumitru Ceara wrote: > > On 8/9/22 08:46, Frode Nordahl wrote: > > On Sat, Aug 6, 2022 at 1:49 AM Han Zhou wrote: > >> > >> > >> > >> On Thu, Aug 4, 2022 at 7:09 AM Dumitru Ceara wrote: > >>> > >>> On 7/25/22 23:34, Han Zhou wrote: > Also remove the reset

[ovs-dev] [PATCH ovn v3 4/5] patch.c: Avoid patch interface deletion & recreation during restart.

When ovn-controller is restarted, it may need multiple iterations of main loop before completely download all related data from SB DB, especially when ovn-monitor-all=false, so after restart, before it sees the related localnet ports from SB DB, it treats the related patch ports on the chassis as

[ovs-dev] [PATCH ovn v3 5/5] vif-plug.c: Use daemon_started_recently() to replace the prime counter.

Also remove the reset mechanism when DB is reconnected, because at DB reconnection the data in IDL would not reset. Signed-off-by: Han Zhou Acked-by: Dumitru Ceara Acked-by: Frode Nordahl --- controller/ovn-controller.c | 1 - controller/vif-plug.c | 20 ++--

[ovs-dev] [PATCH ovn v3 3/5] ovn-controller: Add a generic way to check if the daemon started recently.

In some cases we need to know if ovn-controller started long enough and has enough iterations of input processing, primarily to ensure it has downloaded and handled a complete initial view of the SB DB (and of course the local OVS DB), so that it won't delete things too early by mistake based on

[ovs-dev] [PATCH ovn v3 2/5] binding.c: Missing local_datapath update in runtime_data port_binding handler.

When handling port_binding changes, it is possible that new local_datapaths are added, and the fields of the local_datapath, such as localnet_port, external_ports, etc. need to be updated for the newly added local_datapaths. This problem doesn't happen in most cases because the changes that

[ovs-dev] [PATCH ovn v3 0/5] Avoid unnecessary deletion & recreation during restart.

When ovn-controller is restarted, it may need multiple iterations of main loop before completely download all related data from SB DB, especially when ovn-monitor-all=false, so after restart, before it sees the related localnet ports from SB DB, it treats the related patch ports on the chassis as

[ovs-dev] [PATCH ovn v3 1/5] binding.c: Avoid checking OVSDB tracking status in handle_updated_port.

xxx_is_deleted() is an interface that is expected to be used for OVSDB tracked changes only, but handle_updated_port() function handles both tracked and untracked rows. It may happen to behave as expected in this case but it is risky if the OVSDB IDL implementation changes. Fixes: 3103487e087b

Re: [ovs-dev] [PATCH v6 ovn 2/2] controller: throttle port claim attempts

On Wed, Aug 17, 2022 at 10:27 AM Ihar Hrachyshka wrote: > > Thanks for bringing this up to Mark and Han. I just posted 22.06 and > 22.03 branch backport series in case they are ok'ed to go. > > Ihar > > On Sun, Aug 14, 2022 at 8:53 PM Numan Siddique wrote: > > > > On Thu, Aug 11, 2022 at 4:07 AM

Re: [ovs-dev] [PATCH ovn] northd: Increase the MAC binding removal delay

Thanks, I applied this change to main. On 8/18/22 05:03, Dumitru Ceara wrote: On 8/18/22 08:24, Ales Musil wrote: Reported-at: https://bugzilla.redhat.com/2084668 Signed-off-by: Ales Musil --- After going through the discussion here [0] again, I agree with Han: Acked-by: Dumitru Ceara

Re: [ovs-dev] [PATCH ovn] northd: support vtep LSP-attached LS to use L3 services

Regards, Vladislav Odintsov > On 18 Aug 2022, at 20:07, Han Zhou wrote: > > > > On Thu, Aug 18, 2022 at 8:54 AM Vladislav Odintsov > wrote: > Hi Han, > > As I could understand, admission control flows were introduced for > "gateway/outside" LSs, with GW LRPs. >

Re: [ovs-dev] [PATCH ovn] tests: fix multiple flaky test cases

Thanks Xavier. Acked-by: Mark Michelson On 8/18/22 09:59, Xavier Simonart wrote: - ovn-controller incremental processing - ovn-ic -- port-bindings deletion upon TS deletion - IP packet buffering - ovn-controller-vtep - hv flows - external logical port - ovn-northd pause and resume - ACLs on

Re: [ovs-dev] [PATCH ovn v3] binding.c: update ld->peers when lsp type updated

Hi Mark, Thank you for reviewing the patch. actually, the test here is less interested in the type update but more in the LSP deletion from the ld->peer_ports list i don't have a way to see if the ld->n_peer_ports updated properly from the tests units when we change the port type, but i know that

Re: [ovs-dev] [PATCH ovn] pinctrl fix missing packets (e.g. icmp)

Hi Xavier. I think the only foolproof way to get the seq logic right in pinctrl is to perform all of the processing of pinctrl_handler (including reading the seq and waiting on the seq) with the pinctrl_mutex locked. However, this could cause a lot of waiting that we'd like to avoid. I think

Re: [ovs-dev] [PATCH ovn v3] binding.c: update ld->peers when lsp type updated

Hi Mohammad. The code changes look good, but I'm a bit confused about what the test case is intending to prove. It updates the type of the LSP, but there is no check to ensure that the change was successful, as far as I can tell. On 8/16/22 06:56, Mohammad Heib wrote: The

Re: [ovs-dev] [PATCH ovn] northd: support vtep LSP-attached LS to use L3 services

On Thu, Aug 18, 2022 at 8:54 AM Vladislav Odintsov wrote: > Hi Han, > > As I could understand, admission control flows were introduced for > "gateway/outside" LSs, with GW LRPs. > The scenario, which was covered with this change shouldn’t overlap with a > "gateway/outside" LS scenario: > User

Re: [ovs-dev] [PATCH ovn] northd: support vtep LSP-attached LS to use L3 services

Hi Han, As I could understand, admission control flows were introduced for "gateway/outside" LSs, with GW LRPs. The scenario, which was covered with this change shouldn’t overlap with a "gateway/outside" LS scenario: User creates an LS, adds normal VIF ports (VMs) to LS and additionally he may

Re: [ovs-dev] [PATCH ovn] northd: support vtep LSP-attached LS to use L3 services

On Mon, Aug 15, 2022 at 10:01 PM Odintsov Vladislav wrote: > > Thanks Numan. > > regards, > Vladislav Odintsov > > > On 16 Aug 2022, at 04:56, Numan Siddique wrote: > > > > On Tue, Aug 16, 2022 at 12:19 AM Vladislav Odintsov wrote: > >> > >> If LRP's logical switch has attached LSP of vtep

Re: [ovs-dev] [PATCH ovn v2] controller: Fix wrong controller action definition

Thanks for the fix, Ales. Acked-by: Mark Michelson On 8/18/22 05:41, Ales Musil wrote: The controller action had a wrong wrong userdata_len due to missing substraction of previous data len. The pointer to oc was not moved correctly so it could in theory point to wrong memory. In order to fix

[ovs-dev] [PATCH ovn] pinctrl fix missing packets (e.g. icmp)

seq_read should be used before processing any changes. If buffered_mac_bindings is updated by pinctrl_run while pinctrl_handler is running, but before seq_read, pinctrl_handler was not being woken up (until another event wakes it). This could cause icmp packets to be missing or delayed until the

[ovs-dev] [PATCH ovn] tests: fix multiple flaky test cases

- ovn-controller incremental processing - ovn-ic -- port-bindings deletion upon TS deletion - IP packet buffering - ovn-controller-vtep - hv flows - external logical port - ovn-northd pause and resume - ACLs on Port Groups - DSCP marking and meter check - Stateless Floating IP - ovn-controller -

Re: [ovs-dev] [PATCH net-next 0/1] openvswitch: allow specifying ifindex of new interfaces

On 8/18/22 14:06, Ilya Maximets wrote: On 8/18/22 01:11, Andrey Zhadchenko wrote: On 8/18/22 01:15, Ilya Maximets wrote: On 8/17/22 22:35, Andrey Zhadchenko wrote: On 8/17/22 21:19, Ilya Maximets wrote: On 8/17/22 14:49, Andrey Zhadchenko via dev wrote: Hi! CRIU currently do not

Re: [ovs-dev] [PATCH v1 1/1] datapath-windows: support meter action initial version

Hi Alin, I have sent all the latest patch to patchlist, hope you noticed it. Regards Dejing From: Alin-Gabriel Serdean Date: Tuesday, August 16, 2022 at 6:19 PM To: Dejing Liu , 'Alin-Gabriel Serdean' , d...@openvswitch.org Cc: Frank Guo , Wilson Peng , Lina Li Subject: RE: [ovs-dev]

[ovs-dev] [PATCH v2 1/1] datapath-windows: support meter action initial version

From: ldejing This patch implemented meter action, currently, meter only support drop method and only support one band. The overall implementation is, when a packet comes in, it will first lookup meter according to the meter id, then get the band->rates and delta time since last access the same

Re: [ovs-dev] [PATCH net-next 0/1] openvswitch: allow specifying ifindex of new interfaces

On 8/18/22 01:11, Andrey Zhadchenko wrote: > > > On 8/18/22 01:15, Ilya Maximets wrote: >> On 8/17/22 22:35, Andrey Zhadchenko wrote: >>> >>> >>> On 8/17/22 21:19, Ilya Maximets wrote: On 8/17/22 14:49, Andrey Zhadchenko via dev wrote: > Hi! > > CRIU currently do not support

Re: [ovs-dev] [PATCH ovn] controller: Fix wrong userdata_len for controller action

On Thu, Aug 18, 2022 at 10:58 AM Dumitru Ceara wrote: > On 8/18/22 08:19, Ales Musil wrote: > > The controller action had a wrong wrong userdata_len due to > > missing substraction of previous data len. At the same time > > use stack as ofpbuf as it is likely that all the data > > for rarp

[ovs-dev] [PATCH ovn v2] controller: Fix wrong controller action definition

The controller action had a wrong wrong userdata_len due to missing substraction of previous data len. The pointer to oc was not moved correctly so it could in theory point to wrong memory. In order to fix that expose encode_start_controller_op and encode_finish_controller_op which are helper

Re: [ovs-dev] [PATCH ovn] northd: Increase the MAC binding removal delay

On 8/18/22 08:24, Ales Musil wrote: > Reported-at: https://bugzilla.redhat.com/2084668 > Signed-off-by: Ales Musil > --- After going through the discussion here [0] again, I agree with Han: Acked-by: Dumitru Ceara Thanks! [0]

Re: [ovs-dev] [PATCH ovn] controller: Fix wrong userdata_len for controller action

On 8/18/22 08:19, Ales Musil wrote: > The controller action had a wrong wrong userdata_len due to > missing substraction of previous data len. At the same time > use stack as ofpbuf as it is likely that all the data > for rarp actiovation strategy will fit into that buffer > without additional

Re: [ovs-dev] dest mac in fast datapath does not act as expected

thanks! upgrade to ovs version 2.12.1 fix my problem. At 2022-08-17 18:49:46, "Ilya Maximets" wrote: >On 8/17/22 11:32, ychen wrote: >> hi, >>when we send 2 packets with different dest mac in 10s(fast datapath flow >> aging time), with the same userspace flow action, but

Re: [ovs-dev] [PATCH v2 1/1] datapath-windows: support meter action initial version

References: <20220818062439.39211-1-svc.ovs-commun...@vmware.com> Bleep bloop. Greetings ldejing, I am a robot and I have tried out your patch. Thanks for your contribution. I encountered some error that I wasn't expecting. See the details below. checkpatch: ERROR: Author ldejing needs

[ovs-dev] [PATCH v2 1/1] datapath-windows: support meter action initial version

From: ldejing This patch implemented meter action, currently, meter only support drop method and only support one band. The overall implementation is, when a packet comes in, it will first lookup meter according to the meter id, then get the band->rates and delta time since last access the same

[ovs-dev] [PATCH ovn] northd: Increase the MAC binding removal delay

Reported-at: https://bugzilla.redhat.com/2084668 Signed-off-by: Ales Musil --- northd/mac-binding-aging.c | 2 +- ovn-nb.xml | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/northd/mac-binding-aging.c b/northd/mac-binding-aging.c index 4a2dfbbf8..0196a116b

[ovs-dev] [PATCH ovn] controller: Fix wrong userdata_len for controller action

The controller action had a wrong wrong userdata_len due to missing substraction of previous data len. At the same time use stack as ofpbuf as it is likely that all the data for rarp actiovation strategy will fit into that buffer without additional allocations. Fixes: e52c2451 ("physical.c: Fix