Re: [ovs-dev] [PATCH v1] tests: fix python2 module not find error

Hi llya, This is what I get after a minor tweek : "except ImportError as err: print(err)" when Scapy is not present : No module named 'scapy' Traceback (most recent call last): File "./../mfex_fuzzy.py", line 10, in pktdump = PcapWriter(path, append=False, sync=True) NameError: name

Re: [ovs-dev] OVS has now branched for the 2.16 release.

On Fri, Jul 16, 2021 at 10:42:01PM +0200, Ilya Maximets wrote: > Hi, everyone. > > branch-2.16 was just created. Please, test it and report issues! > > Official release date according to our release process should be on > Monday, August 16th (1 month from now). > > Best regards, Ilya Maximets.

[ovs-dev] OVS has now branched for the 2.16 release.

Hi, everyone. branch-2.16 was just created. Please, test it and report issues! Official release date according to our release process should be on Monday, August 16th (1 month from now). Best regards, Ilya Maximets. ___ dev mailing list d...@openvswit

Re: [ovs-dev] [PATCH 0/2] Patches to branch for 2.16.

On 7/16/21 9:31 PM, Ilya Maximets wrote: > Ilya Maximets (2): > Prepare for 2.16.0. > Prepare for post-2.16.0 (2.16.90). > > Documentation/faq/releases.rst | 2 ++ > NEWS | 6 +- > configure.ac | 2 +- > debian/changelog | 10 ++

Re: [ovs-dev] [PATCH v2] bond: Fix broken rebalancing after link state changes.

On 7/16/21 1:51 AM, Ben Pfaff wrote: > On Tue, Jul 13, 2021 at 05:32:06PM +0200, Ilya Maximets wrote: >> There are 3 constraints for moving hashes from one member to another: >> >> 1. The load difference exceeds ~ 3% of the load of one member. >> 2. The difference in load between members exceed

Re: [ovs-dev] [PATCH v6 0/3] dpif-netlink: Introduce per-cpu upcall dispatching

On 16/07/2021 20:35, Ilya Maximets wrote: > On 7/16/21 9:07 PM, Ilya Maximets wrote: >> On 7/16/21 12:17 PM, Mark Gray wrote: >>> This series proposes a new method of distributing upcalls >>> to user space threads attempting to resolve a number of >>> issues with the current method. >>> >>> v2 - Re

Re: [ovs-dev] [PATCH 2/2] Prepare for post-2.16.0 (2.16.90).

Ilya Maximets writes: > Signed-off-by: Ilya Maximets > --- Acked-by: Aaron Conole ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH 1/2] Prepare for 2.16.0.

Ilya Maximets writes: > Signed-off-by: Ilya Maximets > --- Acked-by: Aaron Conole ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH v6 0/3] dpif-netlink: Introduce per-cpu upcall dispatching

On 7/16/21 9:07 PM, Ilya Maximets wrote: > On 7/16/21 12:17 PM, Mark Gray wrote: >> This series proposes a new method of distributing upcalls >> to user space threads attempting to resolve a number of >> issues with the current method. >> >> v2 - Rebase >> Address Flavio's comments >> v3 - Add

[ovs-dev] [PATCH 2/2] Prepare for post-2.16.0 (2.16.90).

Signed-off-by: Ilya Maximets --- NEWS | 4 configure.ac | 2 +- debian/changelog | 6 ++ 3 files changed, 11 insertions(+), 1 deletion(-) diff --git a/NEWS b/NEWS index 1064c4dfc..75045b67d 100644 --- a/NEWS +++ b/NEWS @@ -1,3 +1,7 @@ +Post-v2.16.0 +-

[ovs-dev] [PATCH 1/2] Prepare for 2.16.0.

Signed-off-by: Ilya Maximets --- Documentation/faq/releases.rst | 2 ++ NEWS | 2 +- configure.ac | 2 +- debian/changelog | 4 ++-- 4 files changed, 6 insertions(+), 4 deletions(-) diff --git a/Documentation/faq/releases.rst b/Documentat

[ovs-dev] [PATCH 0/2] Patches to branch for 2.16.

Ilya Maximets (2): Prepare for 2.16.0. Prepare for post-2.16.0 (2.16.90). Documentation/faq/releases.rst | 2 ++ NEWS | 6 +- configure.ac | 2 +- debian/changelog | 10 -- 4 files changed, 16 insertions(+), 4 deletions(

Re: [ovs-dev] [PATCH v6 0/3] dpif-netlink: Introduce per-cpu upcall dispatching

On 7/16/21 12:17 PM, Mark Gray wrote: > This series proposes a new method of distributing upcalls > to user space threads attempting to resolve a number of > issues with the current method. > > v2 - Rebase > Address Flavio's comments > v3 - Add man page to automake > v4 - Rebase and address F

Re: [ovs-dev] [PATCH RFC ovn 1/1] RFC: Logical flow generation in ovn-controller

On Fri, Jul 16, 2021 at 7:15 AM Numan Siddique wrote: > > On Mon, Jul 12, 2021 at 11:09 AM Mark Michelson wrote: > > > > Full disclosure: I have not looked at all the details in this patch, > > since it is quite large. However, I felt I should comment on the idea. > > Hi Mark, > > Thanks for the

Re: [ovs-dev] [PATCH v1] tests: fix python2 module not find error

On 7/16/21 8:15 PM, kumar Amber wrote: > This fixes the flake8 error on pyhton version older than 3.6 > as ModuleNotFoundError in not available before 3.6 and that is now > replaced to ImportError which is present in earlier versions. > > ../../tests/mfex_fuzzy.py:5:8: F821 undefined name 'ModuleN

[ovs-dev] [PATCH v1] tests: fix python2 module not find error

This fixes the flake8 error on pyhton version older than 3.6 as ModuleNotFoundError in not available before 3.6 and that is now replaced to ImportError which is present in earlier versions. ../../tests/mfex_fuzzy.py:5:8: F821 undefined name 'ModuleNotFoundError' 2653Makefile:5826: recipe for targe

Re: [ovs-dev] [PATCH v3] dpif-netdev: Report overhead busy cycles per pmd.

On Fri, Jul 16, 2021 at 7:30 PM Stokes, Ian wrote: > > > On 16/07/2021 17:21, David Marchand wrote: > > > Users complained that per rxq pmd usage was confusing: summing those > > > values per pmd would never reach 100% even if increasing traffic load > > > beyond pmd capacity. > > > > > > This is

Re: [ovs-dev] [PATCH net-next v2] openvswitch: Introduce per-cpu upcall dispatch

Hello: This patch was applied to netdev/net-next.git (refs/heads/master): On Thu, 15 Jul 2021 08:27:54 -0400 you wrote: > The Open vSwitch kernel module uses the upcall mechanism to send > packets from kernel space to user space when it misses in the kernel > space flow table. The upcall sends pa

Re: [ovs-dev] [PATCH v3] dpif-netdev: Report overhead busy cycles per pmd.

> On 16/07/2021 17:21, David Marchand wrote: > > Users complained that per rxq pmd usage was confusing: summing those > > values per pmd would never reach 100% even if increasing traffic load > > beyond pmd capacity. > > > > This is because the dpif-netdev/pmd-rxq-show command only reports "pure" >

Re: [ovs-dev] [PATCH v7 0/7] Rxq scheduling updates.

On 16/07/2021 17:39, Stokes, Ian wrote: >> The first two patches do not provide new functionality for the user >> (except the logs are reworked). They are reworking to make the >> rxq scheduling and PMD auto load balance code more modular for cleanup >> and to be used by subsequent patches. They ar

Re: [ovs-dev] [PATCH] Testing: Introduce "bring your own lab" as an additional test option

"Stokes, Ian" writes: >> Two big changes are announced here, and the first pertains to >> allowing other developers and labs to report patch status in the >> ozlabs patchwork UI to assist maintainers making decisions on >> patch inclusion. >> >> To make this as easy as possible, the robot will t

Re: [ovs-dev] [PATCH v3] dpif-netdev: Report overhead busy cycles per pmd.

On 16/07/2021 17:21, David Marchand wrote: > Users complained that per rxq pmd usage was confusing: summing those > values per pmd would never reach 100% even if increasing traffic load > beyond pmd capacity. > > This is because the dpif-netdev/pmd-rxq-show command only reports "pure" > rxq cycles

Re: [ovs-dev] [PATCH v2] [branch-2.13] conntrack: Document all-zero IP SNAT behavior and add a test case.

On 7/16/21 2:04 PM, Eelco Chaudron wrote: > Currently, conntrack in the kernel has an undocumented feature referred > to as all-zero IP address SNAT. Basically, when a source port > collision is detected during the commit, the source port will be > translated to an ephemeral port. If there is no co

Re: [ovs-dev] [PATCH v7 0/7] Rxq scheduling updates.

> The first two patches do not provide new functionality for the user > (except the logs are reworked). They are reworking to make the > rxq scheduling and PMD auto load balance code more modular for cleanup > and to be used by subsequent patches. They are also removing the code > duplication betwe

[ovs-dev] [PATCH ovn v3] northd: Process load balancer defrag flows once for all routers.

This allows creating the match strings for each LB VIP exactly once, instead of once per datapath as it was before this change, reducing CPU usage in the ovn-northd event processing loop. On a scaled ovn-kubernetes-like deployment for 120 nodes, with 120 gateway logical routers and 16K load balanc

[ovs-dev] [PATCH v3] dpif-netdev: Report overhead busy cycles per pmd.

Users complained that per rxq pmd usage was confusing: summing those values per pmd would never reach 100% even if increasing traffic load beyond pmd capacity. This is because the dpif-netdev/pmd-rxq-show command only reports "pure" rxq cycles while some cycles are used in the pmd mainloop and add

Re: [ovs-dev] [PATCH] Testing: Introduce "bring your own lab" as an additional test option

> Two big changes are announced here, and the first pertains to > allowing other developers and labs to report patch status in the > ozlabs patchwork UI to assist maintainers making decisions on > patch inclusion. > > To make this as easy as possible, the robot will take a known form > of email se

[ovs-dev] [PATCH v7 7/7] tests: Add new test for cross-numa pmd rxq assignments.

Add some tests to ensure that if there are numa local PMDs they are used for polling an rxq. Also check that if there are only numa non-local PMDs they will be used ito poll the rxq and but the user will be warned. Signed-off-by: Kevin Traynor Acked-by: Sunil Pai G Acked-by: David Marchand ---

[ovs-dev] [PATCH v7 6/7] dpif-netdev: Allow pin rxq and non-isolate PMD.

Pinning an rxq to a PMD with pmd-rxq-affinity may be done for various reasons such as reserving a full PMD for an rxq, or to ensure that multiple rxqs from a port are handled on different PMDs. Previously pmd-rxq-affinity always isolated the PMD so no other rxqs could be assigned to it by OVS. The

[ovs-dev] [PATCH v7 5/7] dpif-netdev: Add group rxq scheduling assignment type.

Add an rxq scheduling option that allows rxqs to be grouped on a pmd based purely on their load. The current default 'cycles' assignment sorts rxqs by measured processing load and then assigns them to a list of round robin PMDs. This helps to keep the rxqs that require most processing on different

[ovs-dev] [PATCH v7 4/7] dpif-netdev: Assign PMD for failed pinned rxqs.

Previously, if pmd-rxq-affinity was used to pin an rxq to a core that was not in pmd-cpu-mask the rxq was not polled for and the user received a warning. This meant that no traffic would be received from that rxq. Now that pinned and non-pinned rxqs are assigned to PMDs in a common call to rxq sch

[ovs-dev] [PATCH v7 3/7] dpif-netdev: Sort PMD list by core id for rxq scheduling.

The list of PMDs is round robined through for the selection when assigning an rxq to a PMD. The list is based on a hash map, so there is no defined order. It means the same set of PMDs may get assigned different rxqs on different runs for no reason other than how the PMDs are stored in the hash ma

[ovs-dev] [PATCH v7 2/7] dpif-netdev: Make PMD auto load balance use common rxq scheduling.

PMD auto load balance had its own separate implementation of the rxq scheduling that it used for dry runs. This was done because previously the rxq scheduling was not made reusable for a dry run. Apart from the code duplication (which is a good enough reason to replace it alone) this meant that if

[ovs-dev] [PATCH v7 1/7] dpif-netdev: Rework rxq scheduling code.

This reworks the current rxq scheduling code to break it into more generic and reusable pieces. The behaviour does not change from a user perspective, except the logs are updated to be more consistent. >From an implementation view, there are some changes with mind to extending functionality. The

[ovs-dev] [PATCH v7 0/7] Rxq scheduling updates.

The first two patches do not provide new functionality for the user (except the logs are reworked). They are reworking to make the rxq scheduling and PMD auto load balance code more modular for cleanup and to be used by subsequent patches. They are also removing the code duplication between them by

Re: [ovs-dev] [PATCH v6 0/7] Rxq scheduling updates.

On 16/07/2021 16:44, Stokes, Ian wrote: >>> The first two patches do not provide new functionality for the user >>> (except the logs are reworked). They are reworking to make the >>> rxq scheduling and PMD auto load balance code more modular for cleanup >>> and to be used by subsequent patches. The

Re: [ovs-dev] [PATCH v6 0/7] Rxq scheduling updates.

> > The first two patches do not provide new functionality for the user > > (except the logs are reworked). They are reworking to make the > > rxq scheduling and PMD auto load balance code more modular for cleanup > > and to be used by subsequent patches. They are also removing the code > > duplica

Re: [ovs-dev] [PATCH ovn v2] controller: Avoid unnecessary load balancer flow processing.

On Fri, Jul 16, 2021 at 09:43:17AM +0200, Dumitru Ceara wrote: > On 7/16/21 3:05 AM, Han Zhou wrote: > > On Thu, Jul 15, 2021 at 5:03 PM Ben Pfaff wrote: > > > >> On Mon, Jul 12, 2021 at 10:08:10AM +0200, Dumitru Ceara wrote: > >>> Whenever a Load_Balancer is updated, e.g., a VIP is added, the fo

Re: [ovs-dev] [PATCH v6 0/7] Rxq scheduling updates.

> The first two patches do not provide new functionality for the user > (except the logs are reworked). They are reworking to make the > rxq scheduling and PMD auto load balance code more modular for cleanup > and to be used by subsequent patches. They are also removing the code > duplication betwe

Re: [ovs-dev] |fail| pw1506184 [PATCH v6 1/7] dpif-netdev: Rework rxq scheduling code.

On 16/07/2021 16:23, Stokes, Ian wrote: >> On 7/16/21 5:15 PM, Kevin Traynor wrote: >>> On 16/07/2021 16:00, 0-day Robot wrote: From: ro...@bytheb.org Test-Label: github-robot Test-Status: fail http://patchwork.ozlabs.org/api/patches/1506184/ _github build: failed

Re: [ovs-dev] |fail| pw1506184 [PATCH v6 1/7] dpif-netdev: Rework rxq scheduling code.

> On 7/16/21 5:15 PM, Kevin Traynor wrote: > > On 16/07/2021 16:00, 0-day Robot wrote: > >> From: ro...@bytheb.org > >> > >> Test-Label: github-robot > >> Test-Status: fail > >> http://patchwork.ozlabs.org/api/patches/1506184/ > >> > >> _github build: failed_ > >> Build URL: https://github.com/ovsr

Re: [ovs-dev] |fail| pw1506184 [PATCH v6 1/7] dpif-netdev: Rework rxq scheduling code.

On 7/16/21 5:15 PM, Kevin Traynor wrote: > On 16/07/2021 16:00, 0-day Robot wrote: >> From: ro...@bytheb.org >> >> Test-Label: github-robot >> Test-Status: fail >> http://patchwork.ozlabs.org/api/patches/1506184/ >> >> _github build: failed_ >> Build URL: https://github.com/ovsrobot/ovs/actions/run

Re: [ovs-dev] |fail| pw1506184 [PATCH v6 1/7] dpif-netdev: Rework rxq scheduling code.

> On 16/07/2021 16:00, 0-day Robot wrote: > > From: ro...@bytheb.org > > > > Test-Label: github-robot > > Test-Status: fail > > http://patchwork.ozlabs.org/api/patches/1506184/ > > > > _github build: failed_ > > Build URL: https://github.com/ovsrobot/ovs/actions/runs/1037824643 > > Build Logs: > >

Re: [ovs-dev] |fail| pw1506184 [PATCH v6 1/7] dpif-netdev: Rework rxq scheduling code.

On 16/07/2021 16:00, 0-day Robot wrote: > From: ro...@bytheb.org > > Test-Label: github-robot > Test-Status: fail > http://patchwork.ozlabs.org/api/patches/1506184/ > > _github build: failed_ > Build URL: https://github.com/ovsrobot/ovs/actions/runs/1037824643 > Build Logs: >

Re: [ovs-dev] [ovn] branch-20.09 tests fail with OVS higher than 2.14.0

Hi, thanks Numan for your comments, I’ll try to address all points in appropriate patches. Some open questions is only about build/test options. Does OVN project need to run builds with: 1. --disable-ssl 2. -ljemalloc 3. different compilers 4. with and without address sanitisers ? Which is the

Re: [ovs-dev] [PATCH v11] ofproto-dpif: APIs and CLI option to add/delete static fdb entry

On 6/30/21 8:42 AM, Eelco Chaudron wrote: > > > On 29 Jun 2021, at 22:43, Vasu Dasari wrote: > >> Currently there is an option to add/flush/show ARP/ND neighbor. This covers >> L3 >> side. For L2 side, there is only fdb show command. This patch gives an >> option >> to add/del an fdb entry vi

Re: [ovs-dev] [PATCH v14 07/11] test/sytem-dpdk: Add unit test for mfex autovalidator

On 7/16/21 4:56 PM, Stokes, Ian wrote: >> On 7/15/21 6:06 PM, kumar Amber wrote: >>> From: Kumar Amber >>> >>> Tests: >>> 6: OVS-DPDK - MFEX Autovalidator >>> 7: OVS-DPDK - MFEX Autovalidator Fuzzy >>> 8: OVS-DPDK - MFEX Configuration >>> >>> Added a new directory to store the PCAP file used

Re: [ovs-dev] [ovn] branch-20.09 tests fail with OVS higher than 2.14.0

On Tue, Jul 13, 2021 at 2:00 PM Vladislav Odintsov wrote: > > Hi Dumitru, Numan, > > Regards, > Vladislav Odintsov > > > On 12 Jul 2021, at 21:39, Numan Siddique wrote: > > > > On Fri, Jul 9, 2021 at 9:01 AM Dumitru Ceara > > wrote: > >> > >> On 7/8/21 6:34 PM, Vladisla

Re: [ovs-dev] [PATCH v14 07/11] test/sytem-dpdk: Add unit test for mfex autovalidator

> On 7/15/21 6:06 PM, kumar Amber wrote: > > From: Kumar Amber > > > > Tests: > > 6: OVS-DPDK - MFEX Autovalidator > > 7: OVS-DPDK - MFEX Autovalidator Fuzzy > > 8: OVS-DPDK - MFEX Configuration > > > > Added a new directory to store the PCAP file used > > in the tests and a script to genera

Re: [ovs-dev] [PATCH v14 07/11] test/sytem-dpdk: Add unit test for mfex autovalidator

On 7/15/21 6:06 PM, kumar Amber wrote: > From: Kumar Amber > > Tests: > 6: OVS-DPDK - MFEX Autovalidator > 7: OVS-DPDK - MFEX Autovalidator Fuzzy > 8: OVS-DPDK - MFEX Configuration > > Added a new directory to store the PCAP file used > in the tests and a script to generate the fuzzy traff

Re: [ovs-dev] [PATCH ovn v3] northd: Fix defrag flows for duplicate vips

On Fri, Jul 16, 2021 at 8:07 AM Mark Gray wrote: > > When adding two SB flows with the same vip but different protocols, only > the most recent flow will be added due to the `if` statement: > > if (!sset_contains(&all_ips, lb_vip->vip_str)) { > sset_add(&all_ips, lb_vip

Re: [ovs-dev] [PATCH v3] [python] Don't mix system poll/monkeypatched select

On 7/1/21 8:27 AM, Terry Wilson wrote: > Sounds good to me. As you said before, the call to poll(0) itself doesn't > appear to block eventlet. Further inspection showed that the issue that we > were seeing was actually caused by cpu-bound code in python-ovs that was > blocking eventlet on connec

[ovs-dev] [PATCH v6 7/7] tests: Add new test for cross-numa pmd rxq assignments.

Add some tests to ensure that if there are numa local PMDs they are used for polling an rxq. Also check that if there are only numa non-local PMDs they will be used ito poll the rxq and but the user will be warned. Signed-off-by: Kevin Traynor Acked-by: Sunil Pai G Acked-by: David Marchand ---

Re: [ovs-dev] [PATCH v5 0/7] Rxq scheduling updates.

On 16/07/2021 15:02, Stokes, Ian wrote: >> The first two patches do not provide new functionality for the user >> (except the logs are reworked). They are reworking to make the >> rxq scheduling and PMD auto load balance code more modular for cleanup >> and to be used by subsequent patches. They ar

[ovs-dev] [PATCH v6 6/7] dpif-netdev: Allow pin rxq and non-isolate PMD.

Pinning an rxq to a PMD with pmd-rxq-affinity may be done for various reasons such as reserving a full PMD for an rxq, or to ensure that multiple rxqs from a port are handled on different PMDs. Previously pmd-rxq-affinity always isolated the PMD so no other rxqs could be assigned to it by OVS. The

[ovs-dev] [PATCH v6 5/7] dpif-netdev: Add group rxq scheduling assignment type.

Add an rxq scheduling option that allows rxqs to be grouped on a pmd based purely on their load. The current default 'cycles' assignment sorts rxqs by measured processing load and then assigns them to a list of round robin PMDs. This helps to keep the rxqs that require most processing on different

[ovs-dev] [PATCH v6 4/7] dpif-netdev: Assign PMD for failed pinned rxqs.

Previously, if pmd-rxq-affinity was used to pin an rxq to a core that was not in pmd-cpu-mask the rxq was not polled for and the user received a warning. This meant that no traffic would be received from that rxq. Now that pinned and non-pinned rxqs are assigned to PMDs in a common call to rxq sch

[ovs-dev] [PATCH v6 3/7] dpif-netdev: Sort PMD list by core id for rxq scheduling.

The list of PMDs is round robined through for the selection when assigning an rxq to a PMD. The list is based on a hash map, so there is no defined order. It means the same set of PMDs may get assigned different rxqs on different runs for no reason other than how the PMDs are stored in the hash ma

[ovs-dev] [PATCH v6 2/7] dpif-netdev: Make PMD auto load balance use common rxq scheduling.

PMD auto load balance had its own separate implementation of the rxq scheduling that it used for dry runs. This was done because previously the rxq scheduling was not made reusable for a dry run. Apart from the code duplication (which is a good enough reason to replace it alone) this meant that if

[ovs-dev] [PATCH v6 1/7] dpif-netdev: Rework rxq scheduling code.

This reworks the current rxq scheduling code to break it into more generic and reusable pieces. The behaviour does not change from a user perspective, except the logs are updated to be more consistent. >From an implementation view, there are some changes with mind to extending functionality. The

[ovs-dev] [PATCH v6 0/7] Rxq scheduling updates.

The first two patches do not provide new functionality for the user (except the logs are reworked). They are reworking to make the rxq scheduling and PMD auto load balance code more modular for cleanup and to be used by subsequent patches. They are also removing the code duplication between them by

Re: [ovs-dev] [PATCH RFC ovn 1/1] RFC: Logical flow generation in ovn-controller

On Mon, Jul 12, 2021 at 11:09 AM Mark Michelson wrote: > > Full disclosure: I have not looked at all the details in this patch, > since it is quite large. However, I felt I should comment on the idea. Hi Mark, Thanks for the review and the comments. > > The memory savings in ovn-northd and the

Re: [ovs-dev] [PATCH v5 0/7] Rxq scheduling updates.

> The first two patches do not provide new functionality for the user > (except the logs are reworked). They are reworking to make the > rxq scheduling and PMD auto load balance code more modular for cleanup > and to be used by subsequent patches. They are also removing the code > duplication betwe

Re: [ovs-dev] [PATCH v3 1/3] dpdk: Logs to announce removal of defaults for socket-mem and limit.

> On 16/07/2021 14:19, Stokes, Ian wrote: > >> On 15/07/2021 22:37, Rosemarie O'Riorden wrote: > >>> Deprecate current OVS provided defaults for DPDK socket-mem and > >>> socket-limit that are planned to be removed in OVS 2.17. At that point > >>> DPDK defaults will be used instead. Warnings have b

[ovs-dev] [PATCH v3 1/2] Optimize the poll loop for poll_immediate_wake()

From: Anton Ivanov If we are not obtaining any useful information out of the poll(), such as is a fd busy or not, we do not need to do a poll() if an immediate_wake() has been requested. This cuts out all the pollfd hash additions, forming the poll arguments and the actual poll() after a call to

[ovs-dev] [PATCH v3 2/2] Minimize the number of time calls in time_poll()

From: Anton Ivanov time_poll() makes an excessive number of time_msec() calls which incur a performance penalty. 1. Avoid time_msec() call for timeout calculation when time_poll() is asked to skip poll() 2. Reuse the time_msec() result from deadline calculation for last_wakeup and timeout calcu

Re: [ovs-dev] [PATCH v3 1/3] dpdk: Logs to announce removal of defaults for socket-mem and limit.

On 16/07/2021 14:19, Stokes, Ian wrote: >> On 15/07/2021 22:37, Rosemarie O'Riorden wrote: >>> Deprecate current OVS provided defaults for DPDK socket-mem and >>> socket-limit that are planned to be removed in OVS 2.17. At that point >>> DPDK defaults will be used instead. Warnings have been added

Re: [ovs-dev] [PATCH v2] flow: Count and dump invalid IP packets.

On 4/16/21 2:44 PM, Flavio Leitner wrote: > On Fri, Apr 16, 2021 at 02:06:31PM +0200, David Marchand wrote: >> Skipping further processing of invalid IP packets helps avoid crashes >> but it does not help to figure out if the malformed packets are still >> present on the network. >> >> Add coverage

Re: [ovs-dev] [PATCH v2 7/8] ovs-rcu: Remove unused perthread mutex

On 7/2/21 7:41 PM, Ben Pfaff wrote: > On Thu, May 20, 2021 at 03:35:51PM +0200, Gaetan Rivet wrote: >> A mutex is allocated, initialized and destroyed, without being >> used in the perthread structure. >> >> Signed-off-by: Gaetan Rivet > > This got independently reported by 贺鹏 . > > Acked-by: Be

Re: [ovs-dev] [PATCH v3 1/3] dpdk: Logs to announce removal of defaults for socket-mem and limit.

> On 15/07/2021 22:37, Rosemarie O'Riorden wrote: > > Deprecate current OVS provided defaults for DPDK socket-mem and > > socket-limit that are planned to be removed in OVS 2.17. At that point > > DPDK defaults will be used instead. Warnings have been added to alert > > users in advance. > > > > A

Re: [ovs-dev] [PATCH v2] Add ability to override default Release suffix in RPM packages

On 5/27/21 7:10 AM, Guzowski Adrian via dev wrote: > In some cases, like building OvS packages in Jenkins, it may be > useful to set a custom version suffix that will correspond with > job's build number, etc. Currently, version number is explicitly > set to 1. This change adds a define "release_nu

Re: [ovs-dev] [PATCH 1/1] [python] Add cooperative_yield() API method to Idl

On 7/1/21 8:19 PM, Terry Wilson wrote: > When using eventlet monkey_patch()'d code, greenthreads can be > blocked on connection for several seconds while the database > contents are parsed. Eventlet recommends adding a sleep(0) call > to cooperatively yield in cpu-bound code. asyncio code has > asy

Re: [ovs-dev] [PATCH] Update bundled sortedcontainers to 2.4.0

On 7/2/21 12:47 PM, Ilya Maximets wrote: > On 7/2/21 12:17 PM, Timothy Redaelli wrote: >> This is needed since the current bundled version doesn't work on Python >> 3.10+. > > Make sense. > > Terry, could you, please, take a look? > > I also wonder if we need to apply this patch to stable branch

Re: [ovs-dev] [PATCH] ci: Do not dump logs on error for GitHub Actions.

On 7/13/21 7:23 PM, Aaron Conole wrote: > David Marchand writes: > >> GHA webui directly focus on the last lines for a failing step. >> config and testsuite logs are attached as artifacts in GHA in case of >> failures, so dumping them just adds noise. >> Skip dumping those files. Travis is left u

Re: [ovs-dev] [PATCH V2 1/2] dpif-netdev: Do not execute packet recovery without experimental support

On 7/14/21 3:00 PM, Eli Britstein wrote: > rte_flow_get_restore_info() API is under experimental attribute. Using it > has a performance impact that can be avoided for non-experimental compilation. > > Do not call it without experimental support. > > Reported-by: Cian Ferriter > Signed-off-by: E

Re: [ovs-dev] [PATCH ovn v2] northd: Fix defrag flows for duplicate vips

On 16/07/2021 12:53, Dumitru Ceara wrote: > Acked-by: Dumitru Ceara Thanks and thanks for the testing. Glad to see a positive performance benefit! ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] [PATCH ovn v3] northd: Fix defrag flows for duplicate vips

When adding two SB flows with the same vip but different protocols, only the most recent flow will be added due to the `if` statement: if (!sset_contains(&all_ips, lb_vip->vip_str)) { sset_add(&all_ips, lb_vip->vip_str); This can cause unexpected behaviour when two loa

Re: [ovs-dev] [PATCH] [branch-2.13] conntrack: Document all-zero IP SNAT behavior and add a test case.

On 16 Jul 2021, at 13:37, Ilya Maximets wrote: > On 7/14/21 4:44 PM, Eelco Chaudron wrote: >> Currently, conntrack in the kernel has an undocumented feature referred >> to as all-zero IP address SNAT. Basically, when a source port >> collision is detected during the commit, the source port will

[ovs-dev] [PATCH v2] [branch-2.13] conntrack: Document all-zero IP SNAT behavior and add a test case.

Currently, conntrack in the kernel has an undocumented feature referred to as all-zero IP address SNAT. Basically, when a source port collision is detected during the commit, the source port will be translated to an ephemeral port. If there is no collision, no SNAT is performed. This patchset docu

[ovs-dev] [PATCH ovn v2 5/5] controller: Improve ct zone handling.

From: Numan Siddique Prior to this patch, ovn-controller generates a zone id for each OVS interface which has external_ids:iface-id set even if there is no corresponding logical port for it. This patch now changes the way we allocate the zone id. A zone id is allocated only if there is an OVS i

[ovs-dev] [PATCH ovn v2 4/5] I-P: Handle runtime data changes for plow_output engine.

From: Numan Siddique physical_run() maintains a local copy of local vif to ofports in a simap along with the chassis tunnel information. This patch removes this from the physical module and now stores it in the runtime_data engine node. This makes it easier to handle runtime data changes in pfl

Re: [ovs-dev] [PATCH ovn v2] northd: Fix defrag flows for duplicate vips

On 7/15/21 8:40 PM, Mark Gray wrote: > When adding two SB flows with the same vip but different protocols, only > the most recent flow will be added due to the `if` statement: > > if (!sset_contains(&all_ips, lb_vip->vip_str)) { > sset_add(&all_ips, lb_vip->vip_str); >

Re: [ovs-dev] [v5] dpif/dpcls: limit count subtable search info logs

> On Tue, Jul 13, 2021 at 07:55:32AM +0530, kumar Amber wrote: > > From: Harry van Haaren > > > > This commit avoids many instances of "using subtable X for miniflow (x,y)" > > in the ovs-vswitchd log when using the DPCLS Autovalidator. This occurs > > when no specialized subtable is found, and th

[ovs-dev] [PATCH ovn v2 3/5] binding: Track the changes of container lport when it's parent changes.

From: Numan Siddique When a container logical port's parent changes and if the parent logical port resides in the same chassis as the old parent, ovn-controller doesn't track that change in the 'tracked_dp_bindings'. At present this is not an issue because pflow_output engine handles this in the

[ovs-dev] [PATCH ovn v2 2/5] binding: Add the localport port binding in the binding_lport information.

From: Numan Siddique If there is an OVS interface present with the external_ids:iface-id set to a localport port binding, we create a 'struct local_binding' for this OVS interface but we do not associate the binding_lport to this local_binding. This patch now associates the binding_lport now. Fu

[ovs-dev] [PATCH ovn v2 1/5] controller: Move 'struct local_datapath' to a separate file.

From: Numan Siddique This would uncomplicate the binding.c code a bit. The tracking data and the related functions are also moved to the file - ldata.h. This would help in an upcoming patch. Signed-off-by: Numan Siddique --- controller/automake.mk | 4 +- controller/binding.c|

[ovs-dev] [PATCH ovn v2 0/5] pflow_output and ct_zone engine improvements.

From: Numan Siddique This patch series attempts to improve the handling of runtime_data changes in the engine nodes - ct_zones and pflow_output. It also attempts to improve the handling of ct_zones change in pflow_output engine. After this patch series, the amount of full recomputes of pflow_o

Re: [ovs-dev] [PATCH v5] conntrack: document all-zero IP SNAT behavior and add a test case

On 7/14/21 4:45 PM, Eelco Chaudron wrote: > > > On 9 Jul 2021, at 16:07, Ilya Maximets wrote: > >> On 7/9/21 10:29 AM, Eelco Chaudron wrote: >>> >>> >>> On 8 Jul 2021, at 21:23, Ilya Maximets wrote: >>> On 6/10/21 11:24 AM, Eelco Chaudron wrote: > Currently, conntrack in the kernel has

Re: [ovs-dev] [PATCH] [branch-2.13] conntrack: Document all-zero IP SNAT behavior and add a test case.

On 7/14/21 4:44 PM, Eelco Chaudron wrote: > Currently, conntrack in the kernel has an undocumented feature referred > to as all-zero IP address SNAT. Basically, when a source port > collision is detected during the commit, the source port will be > translated to an ephemeral port. If there is no co

Re: [ovs-dev] [PATCH v14 00/11] MFEX Infrastructure + Optimizations

> v14: > - fixed format and xmas order in patch 6 > - added additonal negative test-cases for mfex commands > - added core mask for configuration test case Hi all, thanks for all the work reviewing/testing. I've made the required updates for patches 3, 6 and 7 (mostly coding style and log message

Re: [ovs-dev] [PATCH v5 3/3] dpif-netlink: Introduce per-cpu upcall dispatch

On 15/07/2021 21:46, Aaron Conole wrote: > This could probably be written something like: > >} > >if (error) { >return error; >} else if (create) { >VLOG_INFO("Datapath dispatch mode: %s", > (dp_request.user_features & OVS_DP_F_

Re: [ovs-dev] [PATCH v3 2/3] dpdk: Remove default values for socket-mem and limit.

On 15/07/2021 22:37, Rosemarie O'Riorden wrote: > This change removes the default values for EAL args socket-mem and > socket-limit. As DPDK supports dynamic memory allocation, there is no > need to allocate a certain amount of memory on start-up, nor limit the > amount of memory available, if not

[ovs-dev] [PATCH v6 3/3] dpif-netlink: Introduce per-cpu upcall dispatch

The Open vSwitch kernel module uses the upcall mechanism to send packets from kernel space to user space when it misses in the kernel space flow table. The upcall sends packets via a Netlink socket. Currently, a Netlink socket is created for every vport. In this way, there is a 1:1 mapping between

[ovs-dev] [PATCH v6 2/3] dpif-netlink: fix report_loss() message

Fixes: 1579cf677fcb ("dpif-linux: Implement the API functions to allow multiple handler threads read upcall.") Signed-off-by: Mark Gray Acked-by: Flavio Leitner Acked-by: Aaron Conole --- Notes: v1 - Reworked based on Flavio's comments: * Added "Fixes" tag lib/dpif-netlink.c | 4

[ovs-dev] [PATCH v6 0/3] dpif-netlink: Introduce per-cpu upcall dispatching

This series proposes a new method of distributing upcalls to user space threads attempting to resolve a number of issues with the current method. v2 - Rebase Address Flavio's comments v3 - Add man page to automake v4 - Rebase and address Flavio's comments v5 - Rebase and address Flavio and Da

[ovs-dev] [PATCH v6 1/3] ofproto: change type of n_handlers and n_revalidators

'n_handlers' and 'n_revalidators' are declared as type 'size_t'. However, dpif_handlers_set() requires parameter 'n_handlers' as type 'uint32_t'. This patch fixes this type mismatch. Signed-off-by: Mark Gray Acked-by: Flavio Leitner Acked-by: Aaron Conole --- Notes: v1 - Reworked based on

Re: [ovs-dev] [PATCH v3 1/3] dpdk: Logs to announce removal of defaults for socket-mem and limit.

On 15/07/2021 22:37, Rosemarie O'Riorden wrote: > Deprecate current OVS provided defaults for DPDK socket-mem and > socket-limit that are planned to be removed in OVS 2.17. At that point > DPDK defaults will be used instead. Warnings have been added to alert > users in advance. > A few very minor

Re: [ovs-dev] [PATCH v5 1/3] ofproto: change type of n_handlers and n_revalidators

On 15/07/2021 18:31, Aaron Conole wrote: > Mark Gray writes: > >> 'n_handlers' and 'n_revalidators' are declared as type 'size_t'. >> However, dpif_handlers_set() requires parameter 'n_handlers' as >> type 'uint32_t'. This patch fixes this type mismatch. >> >> Signed-off-by: Mark Gray >> Acked-b

Re: [ovs-dev] [v15 06/10] dpif-netdev: Add a partial HWOL PMD statistic.

> -Original Message- > From: Flavio Leitner > Sent: Thursday 15 July 2021 19:58 > To: Ferriter, Cian > Cc: ovs-dev@openvswitch.org; i.maxim...@ovn.org > Subject: Re: [ovs-dev] [v15 06/10] dpif-netdev: Add a partial HWOL PMD > statistic. > > On Thu, Jul 15, 2021 at 01:39:04PM +, F

Re: [ovs-dev] [PATCH v14 10/11] dpif-netdev/mfex: Add AVX512 based optimized miniflow extract

Hi Eelco, Flavio, Thanks a lot for all the comments these would surely avoid bugs coming in future . We have more MFEX patches in stores hope to see your review on them as well in Future 😊 BR Amber > -Original Message- > From: Eelco Chaudron > Sent: Friday, July 16, 2021 2:52 PM > To:

  1   2   >