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

In LR ingress stage LOOKUP_NEIGHBOR and LEARN_NEIGHBOR, the flag REGBIT_SKIP_LOOKUP_NEIGHBOR was used to indicate if mac-binding lookup can be skipped. This patch avoid using the bit by combining it with the REGBIT_LOOKUP_NEIGHBOR_RESULT bit, and assigning 1 to REGBIT_LOOKUP_NEIGHBOR_RESULT serves

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

Support a new logical router option "always_learn_from_arp_request" that controls behavior when handling ARP requests or IPv4 ND-NS packets. "true" - Always learn the MAC/IP binding and add a new MAC_Binding entry (default behavior) "false" - If there is a MAC_binding for that IP and the MAC is

[ovs-dev] [PATCH ovn 0/7] Avoid ARP flow explosion.

This patch series addresses the problem discussed in [0]. Below options need to be configured for the gateway routers: options:always_learn_from_arp_request = false options:dynamic_neigh_routers = true [0] - https://mail.openvswitch.org/pipermail/ovs-discuss/2020-May/049994.html Han Zhou (7):

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

The table id used in test is not the same as the one used in real implementation. Although it doesn't affect correctness, it may cause confusion when people are studying test cases. Signed-off-by: Han Zhou --- tests/ovn.at | 8 tests/test-ovn.c | 11 ++- 2 files changed,

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

Support option:dynamic_neigh_routers for logical routers, so that in particular use cases static neighbor flows are not prepopulated IP addresses belonging to neighbor router ports, to avoid flow exploding problem reported for ovn-kubernetes large scale setup. Reported-by: Girish Moodalbail

[ovs-dev] [PATCH ovn 4/7] actions: Implement new actions lookup_arp_ip and lookup_nd_ip.

lookup_arp_ip and lookup_nd_ip are added to lookup if an entry exists in MAC bindings for a given IP address, for IPv4 and IPv6 respectively. Signed-off-by: Han Zhou --- controller/lflow.c| 4 +- include/ovn/actions.h | 10 + lib/actions.c | 112

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

Update the reg9 bits according to current implementation. Fixes: 2dc7869436de ("ovn-northd: Address scale issues with DNAT flows.") Signed-off-by: Han Zhou --- northd/ovn-northd.8.xml | 16 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/northd/ovn-northd.8.xml

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

For the functions related to lookup_arp/lookup_nd, renaming them to avoid confusion, because those functions checks both mac and ip in mac-bindings. This patch renames them so that a future patch can add a function that only looks up by ip without confusing names. This patch also removes the

[ovs-dev] [PATCH v3] datapath-windows: Reset ct_mark/ct_label to support ALG

The ct_mark/ct_label setting on related connection keep the same behavior with Linux datapath. If one CT entry has parent/master entry, its ct_mark and ct_label should inherit from the corresponding part of parent/master entry at initialization. Signed-off-by: Jinjun Gao --- v3: Resolve Alin's

Re: [ovs-dev] [ovs-dev v2] datapath-windows: Reset ct_mark/ct_label to support ALG

Alin, thanks for review. I have updated the patch to resolve your comment and use RtlCopyMemory to replace memcpy. The PR also is updated: https://github.com/openvswitch/ovs/pull/324 . - Jinjun From: Alin Serdean Date: Thursday, July 23, 2020 at 3:47 AM To: Jinjun Gao ,

Re: [ovs-dev] OVN nb-db and sb-db out of sync

Hi, I see why sb-db broke at 1568th port-binding. The 1568th datapath-binding in sb-db references the same _uuid : 108cf745-db82-43c0-a9d3-afe27a41e4aa external_ids: {logical-switch="8a5d1d3c-e9fc-4cbe-a461-98ff838e6473", name=neutron-e907dc17-f1e8-4217-a37d-86e9a98c86c2,

[ovs-dev] Claves para una implementación efectiva

Buenos día Quise aprovechar la oportunidad de hacerte una invitación para tomar nuestro: Nombre: NOM 035. Claves para una implementación efectiva. Fecha: 13 de Agosto Horario: 10:00 am a 13:00 pm Formato: En línea con interacción en vivo. Lugar: En Vivo desde su computadora

Re: [ovs-dev] [PATCHv2] python: fixed package dependency

On 7/22/2020 2:25 PM, Toms Atteka wrote: Python3 does not have python3-twisted-web. Required codebase is inside python3-twisted. Signed-off-by: Toms Atteka --- debian/control | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/debian/control b/debian/control index

[ovs-dev] [PATCHv2] python: fixed package dependency

Python3 does not have python3-twisted-web. Required codebase is inside python3-twisted. Signed-off-by: Toms Atteka --- debian/control | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/debian/control b/debian/control index 0646b22a1..6420b9d3e 100644 --- a/debian/control +++

Re: [ovs-dev] [PATCH] python: fixed package dependency

Bleep bloop. Greetings Toms Atteka, 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 Toms Atteka needs to sign off. WARNING: Unexpected sign-offs from developers who

[ovs-dev] INFO: task hung in ovs_dp_masks_rebalance

Hello, syzbot found the following issue on: HEAD commit:fa56a987 Merge branch 'ionic-updates' git tree: net-next console output: https://syzkaller.appspot.com/x/log.txt?x=1105f05310 kernel config: https://syzkaller.appspot.com/x/.config?x=2b7b67c0c1819c87 dashboard link:

[ovs-dev] [PATCH v4] bfd: Support overlay BFD

Current OVS intercepts and processes all BFD packets, thus VM-2-VM BFD packets get lost and the recipient VM never sees them. This patch fixes it by only intercepting and processing BFD packets destined to a configured BFD instance, and other BFD packets are made available to the OVS flow table

Re: [ovs-dev] [ovs-dev v2] datapath-windows: Reset ct_mark/ct_label to support ALG

Thanks a lot for the patch. In general please prefer to use RtlCopyMemory instead of memcpy: https://community.osr.com/discussion/242667/rtlcopymemory-vs-memcpy Just a few more nits inlined. Alin. From: Jinjun Gao Sent: Monday, July 20, 2020 6:00 PM To:

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

Eelco Chaudron wrote: > This patch makes the masks cache size configurable, or with > a size of 0, disable it. > > Reviewed-by: Paolo Abeni > Signed-off-by: Eelco Chaudron > --- > include/uapi/linux/openvswitch.h |1 > net/openvswitch/datapath.c | 11 + >

[ovs-dev] [PATCH] python: fixed package dependency

From: Toms Atteka Python3 does not have python3-twisted-web. Required codebase is inside python3-twisted. Signed-off-by: Toms Atteka --- debian/control | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/debian/control b/debian/control index 0646b22a1..6420b9d3e 100644 ---

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

On Mon, Jul 13, 2020 at 11:56 AM Numan Siddique wrote: > +Daniel Alvarez Sanchez > +Lucas Alvares Gomes Martins > > > On Mon, Jul 13, 2020 at 11:29 AM Ankur Sharma > wrote: > >> Hi Numan, >> >> Thank you so much for the details. >> >> > Hi Ankur, > > Thanks for the detailed email. Your

[ovs-dev] [PATCH ovn 2/2] ovn-northd: Don't send the pkt to conntrack for NAT if its not destined for LB VIP.

From: Numan Siddique Presently when a logical switch has load balancer(s) associated to it, then the packet is still sent to conntrack with the action ct_lb on both the ingress and egress logical switch pipeline even if the destination IP is not LB VIP. This is because below logical flows are

[ovs-dev] [PATCH ovn 1/2] ovn-northd: Don't send the pkt to conntrack if it is to be routed in egress stage.

From: Numan Siddique If there is a logical port 'P1' with the IP - 10.0.0.3 and a logical port 'P2' with the IP 20.0.0.3 and if the logical switch of 'P1' has atleast one load balancer associated with it and atleast one ACL with allow-related action associated with it. Then for every packet

[ovs-dev] [PATCH v3] bfd: Support overlay BFD

Current OVS intercepts and processes all BFD packets, thus VM-2-VM BFD packets get lost and the recipient VM never sees them. This patch fixes it by only intercepting and processing BFD packets destined to a configured BFD instance, and other BFD packets are made available to the OVS flow table

Re: [ovs-dev] [PATCH v2] bfd: Support overlay BFD

You are correct, I will fix BFD config in v3. For the overlay BFD packet, we don't set up a port to handle packets targeted at 192.168.10.105. So ovs simply drops them. On Wed, Jul 22, 2020 at 11:26 AM William Tu wrote: > On Wed, Jul 22, 2020 at 11:02:32AM -0700, Yifeng Sun wrote: > > Thanks

[ovs-dev] OVN nb-db and sb-db out of sync

Hi, During a scaling test where 4000 networks are created from OpenStack, I see that nb-db and sb-db are out of sync. All 4000 logical switches and 8000 LS ports (GW port and service port of each network) are created in nb-db. In sb-db, only 1567 port-bindings, 4000 is expected. [root@ovn-db-2

Re: [ovs-dev] [PATCH v2] bfd: Support overlay BFD

On Wed, Jul 22, 2020 at 11:02:32AM -0700, Yifeng Sun wrote: > Thanks for reviewing. > > For these two packets: > > dnl outer IP: Source: 172.16.180.105 Destination: 172.16.180.106 > This one is normal BFD packet, bfd_should_process_flow should return > true, as used to. > > dnl inner IP:

Re: [ovs-dev] [PATCH v2] bfd: Support overlay BFD

Please discard my previous email, I misunderstood your question. The packet above is dnl outer IP: Source: 172.16.180.105 Destination: 172.16.180.106 dnl inner IP: Source: 192.168.10.104 Destination: 192.168.10.105 So the bfd_should_process_flow returns false. Yes, you are correct and

Re: [ovs-dev] [PATCH v2] bfd: Support overlay BFD

Thanks for reviewing. For these two packets: dnl outer IP: Source: 172.16.180.105 Destination: 172.16.180.106 This one is normal BFD packet, bfd_should_process_flow should return true, as used to. dnl inner IP: Source: 192.168.10.104 Destination: 192.168.10.105 This one is overlay BFD

Re: [ovs-dev] [PATCH v2] bfd: Support overlay BFD

On Wed, Jul 22, 2020 at 01:59:04AM -0700, Yifeng Sun wrote: > Current OVS intercepts and processes all BFD packets, thus VM-2-VM > BFD packets get lost and the recipient VM never sees them. > > This patch fixes it by only intercepting and processing BFD packets > destined to a configured BFD

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

Hi Eelco, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on net-next/master] url: https://github.com/0day-ci/linux/commits/Eelco-Chaudron/net-openvswitch-masks-cache-enhancements/20200722-163017 base: https://git.kernel.org/pub/scm/linux/kernel/git/davem

Re: [ovs-dev] [PATCH v2] bfd: Support overlay BFD

On Wed, Jul 22, 2020 at 01:59:04AM -0700, Yifeng Sun wrote: > Current OVS intercepts and processes all BFD packets, thus VM-2-VM > BFD packets get lost and the recipient VM never sees them. > > This patch fixes it by only intercepting and processing BFD packets > destined to a configured BFD

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

On 22 Jul 2020, at 17:21, Jakub Kicinski wrote: On Wed, 22 Jul 2020 10:27:52 +0200 Eelco Chaudron wrote: This patch makes the masks cache size configurable, or with a size of 0, disable it. Reviewed-by: Paolo Abeni Signed-off-by: Eelco Chaudron Hi Elco! This patch adds a bunch of new

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

On Wed, 22 Jul 2020 10:27:52 +0200 Eelco Chaudron wrote: > This patch makes the masks cache size configurable, or with > a size of 0, disable it. > > Reviewed-by: Paolo Abeni > Signed-off-by: Eelco Chaudron Hi Elco! This patch adds a bunch of new sparse warnings:

Re: [ovs-dev] [PATCH v2] dpif-netlink: distribute polling to discreet handlers

On Wed, Jul 22, 2020 at 1:27 AM Aaron Conole wrote: > To check: > > ip netns add left > ip netns add right > ip link add center-left type veth peer name left0 > ip link add center-right type veth peer name right0 > ip link set left0 netns left > ip link set right0 netns right Nit: ip

[ovs-dev] 1

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

[ovs-dev] [PATCH v2] bfd: Support overlay BFD

Current OVS intercepts and processes all BFD packets, thus VM-2-VM BFD packets get lost and the recipient VM never sees them. This patch fixes it by only intercepting and processing BFD packets destined to a configured BFD instance, and other BFD packets are made available to the OVS flow table

Re: [ovs-dev] [PATCH v3 3/4] netdev-offload: Add xdp flow api provider

On 2020/07/22 3:10, William Tu wrote: Thanks for the patch. My comments below: On Mon, Jun 29, 2020 at 8:30 AM Toshiaki Makita wrote: This provider offloads classifier to software XDP. It works only when a custom XDP object is loaded by afxdp netdev. The BPF program needs to implement

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

On 22 Jul 2020, at 10:27, Eelco Chaudron wrote: This patchset adds two enhancements to the Open vSwitch masks cache. Signed-off-by: Eelco Chaudron Eelco Chaudron (2): net: openvswitch: add masks cache hit counter net: openvswitch: make masks cache size configurable

[ovs-dev] [RFC PATCH 2/2] dpctl: dpif: allow viewing and configuring dp cache sizes

This patch adds a general way of viewing/configuring datapath cache sizes. With an implementation for the netlink interface. The ovs-dpctl/ovs-appctl show commands will display the current cache sizes configured: ovs-dpctl show system@ovs-system: lookups: hit:25 missed:63 lost:0 flows: 0

[ovs-dev] [RFC PATCH 0/2] dpctl: cache visibility/configuration enhancements

This RFC patchset adds two enhancements related to cache management to dpclt. It's marked RFC as the required kmod patches have just been sent upstream: https://lore.kernel.org/netdev/159540642765.619787.548452630292188.stgit@ebuild/T/#t NOTE: This RFC still needs a dpctl test suite

[ovs-dev] [RFC PATCH 1/2] dpctl: dpif: add kernel datapath cache hit output

This patch adds cache usage statistics to the output: $ ovs-dpctl show

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

Add a counter that counts the number of masks cache hits, and export it through the megaflow netlink statistics. Reviewed-by: Paolo Abeni Signed-off-by: Eelco Chaudron --- include/uapi/linux/openvswitch.h |2 +- net/openvswitch/datapath.c |5 - net/openvswitch/datapath.h

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

This patch makes the masks cache size configurable, or with a size of 0, disable it. Reviewed-by: Paolo Abeni Signed-off-by: Eelco Chaudron --- include/uapi/linux/openvswitch.h |1 net/openvswitch/datapath.c | 11 + net/openvswitch/flow_table.c | 86

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

This patchset adds two enhancements to the Open vSwitch masks cache. Signed-off-by: Eelco Chaudron Eelco Chaudron (2): net: openvswitch: add masks cache hit counter net: openvswitch: make masks cache size configurable include/uapi/linux/openvswitch.h |3 +

Re: [ovs-dev] [PATCH v3 3/4] netdev-offload: Add xdp flow api provider

On 2020/07/22 0:34, William Tu wrote: On Tue, Jul 7, 2020 at 2:07 AM Toshiaki Makita wrote: On 2020/06/30 0:30, Toshiaki Makita wrote: ... int netdev_afxdp_init(void) { libbpf_set_print(libbpf_print); -return 0; +return netdev_register_flow_api_provider(_offload_xdp);

Re: [ovs-dev] [PATCH v3 3/4] netdev-offload: Add xdp flow api provider

On 2020/07/22 0:38, Aaron Conole wrote: William Tu writes: On Tue, Jun 30, 2020 at 12:11 AM Toshiaki Makita wrote: On 2020/06/30 1:17, 0-day Robot wrote: Bleep bloop. Greetings Toshiaki Makita, I am a robot and I have tried out your patch. Thanks for your contribution. I encountered

[ovs-dev] N/A

I'm Mrs Nakielska Kate Magdalena from Poland base in Ukraine. Our business is lending and we have multiple lending operations in Europe,all round America, Asia and the United States. If you are interested in applying for a loan please send us the following information to get in touch with you: