[ovs-dev] Fwd: [PATCH] build: check libibverbs deps before linking with dpdk

-- Forwarded message - 发件人： Harold Huang Date: 2021年11月10日周三 下午8:53 Subject: Re: [ovs-dev] [PATCH] build: check libibverbs deps before linking with dpdk To: David Marchand Yes, I know it because it has other mlx5 drivers. But the mlx5 is indeed skipped because I do not install

[ovs-dev] [PATCH ovn] ovn-nbctl: Fix lrp-set-gateway-chassis.

Currently this command assumes that if the gateway_chassis record with expected name exists it is set to the logical port, so once the record is found it not set to the lrp again. However, this assumption is not always true. An example is that when combined with a lrp-del and then lrp-add

[ovs-dev] [PATCH ovn] northd: fix ttl exceeded with FIP

Properly manage ttl exceeded ICMP error messages when traffic is directed to a FIP. The issue can be verified running traceroute from an external device to a FIP: $traceroute -I -z 1 -n Fix ttl exceeded priority respect to ping responder. Related bz:

Re: [ovs-dev] [ovn] chassis with VXLAN breaks setup which is using OVN-IC

Hi Ihar, also it seems that the test, which was added in a mentioned commit, is flaky. I continuously see 2 or 3 runs of 10 are failed on my dev VM. With verbose logging fail looks like this: 103. ovn.at:3708: testing VXLAN check port/datapath key space limits -- ovn-northd

Re: [ovs-dev] [PATCH ovn v2] nb: Add support for gateway_mtu_bypass.

On Wed, Nov 10, 2021 at 12:24 PM Numan Siddique wrote: > > On Wed, Nov 10, 2021 at 5:19 AM Dumitru Ceara wrote: > > > > On 11/9/21 8:24 PM, Numan Siddique wrote: > > > On Fri, Nov 5, 2021 at 5:21 AM Dumitru Ceara wrote: > > >> > > >> There are various costs (e.g., not being able to perform

[ovs-dev] Regarding the performance issues reported during today's OVS+DPDK meeting.

Hi, Harsha. I was thinking about 3x performance drop due to enabling of experimental API that you reported during the meeting today. I just want to clarify one thing to be sure that you're not making the same mistake as I did. If you're just building OVS without specifying CFLAGS, binaries will

Re: [ovs-dev] [PATCH ovn v2] nb: Add support for gateway_mtu_bypass.

On Wed, Nov 10, 2021 at 5:19 AM Dumitru Ceara wrote: > > On 11/9/21 8:24 PM, Numan Siddique wrote: > > On Fri, Nov 5, 2021 at 5:21 AM Dumitru Ceara wrote: > >> > >> There are various costs (e.g., not being able to perform hardware > >> offload in some cases) when using check_pkt_larger() so the

[ovs-dev] [PATCH dpdk-latest v8] dpdk: Support running PMD threads on any core.

Previously in OVS, a PMD thread running on cpu X used lcore X. This assumption limited OVS to run PMD threads on physical cpu < RTE_MAX_LCORE. DPDK 20.08 introduced a new API that associates a non-EAL thread to a free lcore. This new API does not change the thread characteristics (like CPU

Re: [ovs-dev] [PATCH] ofproto-dpif-xlate: support meter action in a group bucket

References: <2020162134.19132-1-simon.hor...@corigine.com> Bleep bloop. Greetings Simon Horman, 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: WARNING: Unexpected

[ovs-dev] [PATCH/RFC 7/7] dpif-netlink: add offloaded meter stats dump in dpif_netlink_meter_get_stats

From: Tianyu Yuan Since previous ovs meter only supported dumping meter stats in non-offload datapath, the dpif_netlink_meter_transact_offloaded is introduced in dpif_netlink_meter_get_stats, in order to ckech meter stats in offloaded datapath through sending and receiving corresponding netlink

[ovs-dev] [PATCH/RFC 6/7] ofproto-dpif: add offloaded meter revalidatation

From: Baowen Zheng When meter deleted the deletion of the corresponding TC police action, used to facilitate offload via OVS-TC, may fail. This is occurs when the TC police action instance still in use by a TC flower classifiers (flows added to the TC datapath). In this commit, i add a

[ovs-dev] [PATCH/RFC 5/7] dpif: replace n_handlers with n_handlers_

From: Tianyu Yuan A following commit will include "ofproto-dpif.h" in "dpif-netlink.c", in order to use "struct dpif_backer". However this method will result in the declaration of ‘n_handlers’ shadowing a global declaration. Address this by replacing n_handlers with n_handlers_ in relavant

[ovs-dev] [PATCH/RFC 4/7] dpif-netlink: delete TC police action instance when deleting meter instance

From: Baowen Zheng Delete the corresponding TC police action when deleting a meter. This is part of adding support for hardware offload of meters via OVS-TC. The delete may failed if there is filter rule is refered to this action. Signed-off-by: Baowen Zheng Signed-off-by: Tianyu Yuan

[ovs-dev] [PATCH/RFC 3/7] netdev-offload-tc: get police action for meter configuration

From: Tianyu Yuan Retrieve configuration of meter actions in TC flower classifiers (flows in the TC datapath). These actions are TC police action instances referred to by index. Signed-off-by: Tianyu Yuan Signed-off-by: Simon Horman --- lib/netdev-offload-tc.c | 5 + lib/tc.c

[ovs-dev] [PATCH/RFC 2/7] netdev-offload-tc: support offload of meter action

From: Tianyu Yuan Support offload of OF meter action using TC police actions. The TC police action instances are created when meters are configured and referred to here, in TC flower classifiers (flows) that use meter actions, by index. Signed-off-by: Tianyu Yuan Signed-off-by: Simon Horman

[ovs-dev] [PATCH/RFC 1/7] dpif-netlink: add support for offload of meters

From: Baowen Zheng Allow hardware offload of meters via OVS-TC by reflecting meter configuration into the TC datapath as TC police actions whose lifecycle is independent of flows. A follow-up patch will make use of such TC policer action instances by referring to them by index in TC flower

[ovs-dev] [PATCH/RFC 0/7] Allow offload of OpenFlow Meters via TC

Hi, we have been working on enhancing the upstream Linux kernel to allow hardware offload of TC police action instances whose lifecycle is independent of classifiers. The motivation for this work is to provide a mechanism for hardware offload of OpenFlow meters by OVS via TC. This patchset

[ovs-dev] [PATCH] ofproto-dpif-xlate: support meter action in a group bucket

From: Louis Peens This patch is used to make a group bucket support a meter action. When receiving action=meter: we need to: 1) accept this - pre-patch effectively only set_actions are supported 2) use this id to lookup the meter that was added 3) populate the provider id into the ofpact_meter

Re: [ovs-dev] [PATCH v7] Encap & Decap actions for MPLS packet type.

On Fri, Nov 05, 2021 at 03:05:54PM +0100, Ilya Maximets wrote: > On 10/12/21 06:23, Martin Varghese wrote: > > From: Martin Varghese > > Hi, Martin. Thanks for working on this! > > I didn't review most of the logic of the action itself, but see some > comments inline. > > Bets regards, Ilya

[ovs-dev] [PATCH ovn] controller I-P: Add missing FDB flows when a datapath is added locally.

From: Numan Siddique Reported-at: https://bugzilla.redhat.com/show_bug.cgi?id=1983111 Fixes: dd94f1266ca4("northd: MAC learning: Add logical flows for fdb.") Signed-off-by: Numan Siddique --- controller/lflow.c | 12 controller/lflow.h | 1 +

Re: [ovs-dev] [PATCH v1] checkpatch: Detect "trojan source" attack

On Wed, Nov 10, 2021 at 6:30 AM Gaëtan Rivet wrote: > > On Tue, Nov 2, 2021, at 19:43, Mike Pattrick wrote: > > Recently there has been a lot of press about the "trojan source" attack, > > where Unicode characters are used to obfuscate the true functionality of > > code. This attack didn't effect

Re: [ovs-dev] [PATCH dpdk-latest v3 0/5] Fixes for DPDK v21.11

On Wed, Nov 10, 2021 at 3:19 PM Stokes, Ian wrote: > Thanks for the series. Looks good on the github actions to myself. I'd like > to get OVS up and running on validation with rc2 so I've pushed the series to > dpdk-latest and rebased. > > Folks on the Intel side will be carrying out mode

Re: [ovs-dev] [PATCH dpdk-latest v3 0/5] Fixes for DPDK v21.11

> On Wed, Nov 10, 2021 at 1:15 PM Stokes, Ian wrote: > > > Changes since v2: > > > - restored patch1, > > > > > > > > > David Marchand (5): > > > netdev-dpdk: Remove access to DPDK internals. > > > netdev-dpdk: Remove unused attribute from rte_flow rule. > > > netdev-dpdk: Fix mbuf macros

[ovs-dev] CloudNetEngine open source OVS system and performance test suite

Hello folks, CloudNetEngine is very pleased to open source our test suite CNE-OVS-SIT under Apache-2.0 License. The suite is for OVS end-to-end system and performance tests, and mainly focus on userspace datapath, i.e. OVS-DPDK. The suite covers a variety of datapath functions: VLAN, tunnels,

Re: [ovs-dev] [PATCH] build: check libibverbs deps before linking with dpdk

On Wed, Nov 10, 2021 at 1:16 PM Harold Huang wrote: > > Hi, Maximets, > > I have found this build error message in both dpdk 20.11.3 and > 20.11.1. I did not make any change to dpdk. I use the following > command to build dpdk: > > meson builddir && cd builddir && meson configure >

Re: [ovs-dev] [PATCH dpdk-latest v3 0/5] Fixes for DPDK v21.11

On Wed, Nov 10, 2021 at 1:15 PM Stokes, Ian wrote: > > Changes since v2: > > - restored patch1, > > > > > > David Marchand (5): > > netdev-dpdk: Remove access to DPDK internals. > > netdev-dpdk: Remove unused attribute from rte_flow rule. > > netdev-dpdk: Fix mbuf macros namespace with

Re: [ovs-dev] [PATCH] build: check libibverbs deps before linking with dpdk

Hi, Maximets, I have found this build error message in both dpdk 20.11.3 and 20.11.1. I did not make any change to dpdk. I use the following command to build dpdk: meson builddir && cd builddir && meson configure --prefix=/usr/local -Dexamples='' -Dtests=false -Denable_kmods=false

Re: [ovs-dev] [PATCH dpdk-latest v3 0/5] Fixes for DPDK v21.11

> Hello Ian, > > This series applies on a dpdk-latest branch rebased on current master [1]. > It builds and passes checks in GHA, see [2]. > > Fyi, the lcore API is marked stable, I'll repost my patch for OVS as a > followup of this series. > > v21.11-rc2 was tagged last night. > > There will

Re: [ovs-dev] [PATCH] build: check libibverbs deps before linking with dpdk

On 11/10/21 05:10, Harold Huang wrote: > When I build ovs-dpdk without mlx4/mlx5 driver, the configure log is as > follows: > > checking for DPDK... yes > checking for faulty pkg-config version... no > checking for rte_config.h... yes > checking whether RTE_LIBRTE_VHOST_NUMA is declared... yes >

Re: [ovs-dev] [PATCH] build: check libibverbs deps before linking with dpdk

Hi, Sunil, I try it and it has fixed the puzzling error message. Thanks Pai G, Sunil 于2021年11月10日周三 下午6:12写道： > > Hi Huang, > > > > Thanks for the patch. > > The problem is a bit more generic i.e not restrcited to MLX4/MLX5. > > Could you try this patch instead ? >

Re: [ovs-dev] [PATCH v1] checkpatch: Detect "trojan source" attack

On Tue, Nov 2, 2021, at 19:43, Mike Pattrick wrote: > Recently there has been a lot of press about the "trojan source" attack, > where Unicode characters are used to obfuscate the true functionality of > code. This attack didn't effect OVS, but adding the check here will help > guard against it

[ovs-dev] [PATCH v2 4/4] Tunnel: Snoop ingress packets and update neigh cache if needed.

In case of native tunnel with bfd enabled, if the MAC address of the remote end's interface changes (e.g. because it got rebooted, and the MAC address is allocated dynamically), the BFD session will never be re-established. This happens because the local tunnel neigh entry doesn't get updated,

[ovs-dev] [PATCH v2 3/4] Native tunnel: Do not refresh the entry while revalidating.

This is a minor issue but visible e.g. when you try to flush the neigh cache while the ARP flow is still present in the datapath, triggering the revalidation of the datapath flows which subsequently refreshes/adds the entry in the cache. Signed-off-by: Paolo Valerio --- v2: - renamed update ->

[ovs-dev] [PATCH v2 2/4] Native tunnel: Add tnl/neigh/aging command.

with the command is now possible to change the aging time of the cache entries. For the existing entries the aging time is updated only if the current expiration is greater than the new one. In any case, the next refresh will set it to the new value. This is intended mostly for debugging

[ovs-dev] [PATCH v2 1/4] Native tunnel: Read/write expires atomically.

Expires is modified in different threads (revalidator, pmd-rx, bfd-tx). It's better to use atomics for such potentially parallel write. Signed-off-by: Paolo Valerio --- v2: - modified commit description - added _MS suffix to NEIGH_ENTRY_DEFAULT_IDLE_TIME - renamed local variable expired ->

[ovs-dev] [PATCH v2 0/4] Native tunnel: Update neigh entries in tnl termination.

v2: - rebased against master - turned 'ageing' -> 'aging' - further details of v1 -> v2 respin has been added to each patch The series is composed of the following patches: #1: Expires is modified in different contexts (revalidator, pmd-rx, bfd-tx). It's probably not very racy for many

Re: [ovs-dev] [PATCH 0/4] Native tunnel: Update neigh entries in tnl termination.

Missed the v2 tag. Going to resend adding it. Sorry for the noise. Paolo Valerio writes: > v2: > - rebased against master > - turned 'ageing' -> 'aging' > - further details of v1 -> v2 respin has been added > to each patch > > The series is composed of the following patches: > > #1: Expires

Re: [ovs-dev] [PATCH ovn v2] nb: Add support for gateway_mtu_bypass.

On 11/9/21 8:24 PM, Numan Siddique wrote: > On Fri, Nov 5, 2021 at 5:21 AM Dumitru Ceara wrote: >> >> There are various costs (e.g., not being able to perform hardware >> offload in some cases) when using check_pkt_larger() so the CMS >> can now limit the impact by bypassing the packet length

Re: [ovs-dev] [PATCH] build: check libibverbs deps before linking with dpdk

Hi Huang, Thanks for the patch. The problem is a bit more generic i.e not restrcited to MLX4/MLX5. Could you try this patch instead ? http://patchwork.ozlabs.org/project/openvswitch/patch/2020100744.204072-1-sunil.pa...@intel.com/ Thanks and regards, Sunil

[ovs-dev] [PATCH v1] acinclude: Provide error info when linking fails with DPDK.

Currently the configure script provides no infomation but to update the pkg-config path on failure to link with DPDK. Fix this to provide more information to the user on failure. Before: checking whether linking with dpdk works... no configure: error: Could not find DPDK library in default search