Re: [ovs-dev] [PATCH 1/2] netdev-offload-dpdk: Fix flushing of a physdev

>-Original Message- >From: David Marchand >Sent: Friday, 26 May 2023 17:48 >To: Eli Britstein >Cc: d...@openvswitch.org; Ilya Maximets ; >wuxi_...@163.com >Subject: Re: [ovs-dev] [PATCH 1/2] netdev-offload-dpdk: Fix flushing of a >physdev > >External email: Use caution opening links or

Re: [ovs-dev] [PATCH v4 3/3] netdev-offload-dpdk: use flow transfer proxy mechanism

>-Original Message- >From: Ivan Malov >Sent: Sunday, 4 June 2023 15:58 >To: Eli Britstein >Cc: ovs-dev@openvswitch.org; Ilya Maximets ; Ori >Kam ; David Marchand >Subject: RE: [PATCH v4 3/3] netdev-offload-dpdk: use flow transfer proxy >mechanism > >External email: Use caution

Re: [ovs-dev] [PATCH v3 7/7] tc: Add vxlan encap action with gbp option offload

On 5/26/2023 8:18 PM, Eelco Chaudron wrote: External email: Use caution opening links or attachments On 15 May 2023, at 10:23, Roi Dayan wrote: From: Gavin Li Add TC offload support for vxlan encap with gbp option Signed-off-by: Gavin Li Reviewed-by: Gavi Teitz Reviewed-by: Roi Dayan

Re: [ovs-dev] [PATCH v5] tc: fix crash on malformed reply from kernel.

On 6/5/23 23:45, Frode Nordahl wrote: > > > man. 5. jun. 2023, 23:02 skrev Ilya Maximets >: > > On 5/31/23 15:49, Frode Nordahl wrote: > > The tc module combines the use of the `tc_transact` helper > > function for communication with the in-kernel tc

Re: [ovs-dev] [PATCH v5] tc: fix crash on malformed reply from kernel.

man. 5. jun. 2023, 23:02 skrev Ilya Maximets : > On 5/31/23 15:49, Frode Nordahl wrote: > > The tc module combines the use of the `tc_transact` helper > > function for communication with the in-kernel tc infrastructure > > with assertions on the reply data by `ofpbuf_at_assert` on the > >

Re: [ovs-dev] [PATCH v5] tc: fix crash on malformed reply from kernel.

On 5/31/23 15:49, Frode Nordahl wrote: > The tc module combines the use of the `tc_transact` helper > function for communication with the in-kernel tc infrastructure > with assertions on the reply data by `ofpbuf_at_assert` on the > received data prior to further processing. > > With the presence

Re: [ovs-dev] [PATCH ovn] northd, controller: Add support for DHCPv6 FQDN option

On 6/2/23 09:45, Ales Musil wrote: On Fri, Jun 2, 2023 at 12:43 PM Ales Musil wrote: Add support for FQDN option (39), if specified the server can overwrite FQDN for the client. It behaves similarly to DHCP hostname option (12). Reported-at: https://bugzilla.redhat.com/2211890 I have

Re: [ovs-dev] [PATCH v2] conntrack: Fix icmp_id conflicts in snat

On Wed, Dec 14, 2022 at 10:50 PM wrote: > > From: wushaohua > > The icmp_id maybe conflicts in snat > Description: > If multiple devices send icmp packets with the same icmp_id, > the sip of the packets changes to the same source ip address after the snat > operation, > and the packets are sent

Re: [ovs-dev] [ovn] ha-chassis-group false positive failover

On Mon, Jun 5, 2023 at 8:58 AM Vladislav Odintsov wrote: > > Hi Dumitru, Ilya, Han, > > do you guys have any comments here? > I’m gonna start working on this change in near future... > > Thank you. > > On 17 May 2023, at 18:34, Numan Siddique wrote: > > On Wed, May 17, 2023 at 4:44 AM Vladislav

Re: [ovs-dev] [ovn] ha-chassis-group false positive failover

Hi Dumitru, Ilya, Han, do you guys have any comments here? I’m gonna start working on this change in near future... Thank you. > On 17 May 2023, at 18:34, Numan Siddique wrote: > > On Wed, May 17, 2023 at 4:44 AM Vladislav Odintsov > wrote: >> >> >> >>> On 16 May

Re: [ovs-dev] [PATCH net] net: openvswitch: fix upcall counter access before allocation

On 5 Jun 2023, at 15:07, Simon Horman wrote: > On Mon, Jun 05, 2023 at 02:54:35PM +0200, Eelco Chaudron wrote: >> >> >> On 5 Jun 2023, at 14:41, Simon Horman wrote: >> >>> On Mon, Jun 05, 2023 at 10:59:50AM +0200, Eelco Chaudron wrote: Currently, the per cpu upcall counters are allocated

[ovs-dev] [PATCH v2] seq: Make read of the current value atomic

Make the read of the current seq->value atomic, i.e., not needing to acquire the global mutex when reading it. On 64-bit systems, this incurs no overhead, and it will avoid the mutex and potentially a system call. For incrementing the value followed by waking up the threads, we are still taking

Re: [ovs-dev] [PATCH net] net: openvswitch: fix upcall counter access before allocation

On Mon, Jun 05, 2023 at 02:54:35PM +0200, Eelco Chaudron wrote: > > > On 5 Jun 2023, at 14:41, Simon Horman wrote: > > > On Mon, Jun 05, 2023 at 10:59:50AM +0200, Eelco Chaudron wrote: > >> Currently, the per cpu upcall counters are allocated after the vport is > >> created and inserted into

Re: [ovs-dev] [PATCH net] net: openvswitch: fix upcall counter access before allocation

On 5 Jun 2023, at 14:41, Simon Horman wrote: > On Mon, Jun 05, 2023 at 10:59:50AM +0200, Eelco Chaudron wrote: >> Currently, the per cpu upcall counters are allocated after the vport is >> created and inserted into the system. This could lead to the datapath >> accessing the counters before

Re: [ovs-dev] [PATCH net] net: openvswitch: fix upcall counter access before allocation

On Mon, Jun 05, 2023 at 10:59:50AM +0200, Eelco Chaudron wrote: > Currently, the per cpu upcall counters are allocated after the vport is > created and inserted into the system. This could lead to the datapath > accessing the counters before they are allocated resulting in a kernel > Oops. > >

[ovs-dev] [PATCH ovn] controller: make garp_max_timeout configurable

When using VLAN backed networks and OVN routers leveraging the 'ovn-chassis-mac-mappings' option for east-west traffic, the eth.src field is replaced by the chassis mac address in order to not expose the router mac address from different nodes and confuse the TOR switch. However doing so the TOR

[ovs-dev] [PATCH net] net: openvswitch: fix upcall counter access before allocation

Currently, the per cpu upcall counters are allocated after the vport is created and inserted into the system. This could lead to the datapath accessing the counters before they are allocated resulting in a kernel Oops. Here is an example: PID: 59693TASK: 0005f4f51500 CPU: 0

Re: [ovs-dev] [PATCH ovn v2 05/14] northd: Avoid triggering unnecesary recompute for nb_global changes.

On Fri, Jun 2, 2023 at 8:05 AM Numan Siddique wrote: > > On Fri, Jun 2, 2023 at 12:13 AM Han Zhou wrote: > > > > For changes such as nb_cfg related columns, don't trigger recompute. > > > > Signed-off-by: Han Zhou > > Reviewed-by: Ales Musil > > Acked-by: Numan Siddique > > Numan > Thanks

Re: [ovs-dev] [PATCH ovn v2 04/14] ovn.at: Fix test case: delete mac bindings.

On Fri, Jun 2, 2023 at 8:02 AM Numan Siddique wrote: > > On Fri, Jun 2, 2023 at 12:12 AM Han Zhou wrote: > > > > MAC_Binding table is to store neighbour cache for logical router > > datapaths to resolve unknown IP addresses to MAC. The datapath field is > > always logical router and the

Re: [ovs-dev] [PATCH ovn v2 03/14] inc-proc-eng.h: Refactor I-P engine node macros.

On Fri, Jun 2, 2023 at 8:01 AM Numan Siddique wrote: > > On Fri, Jun 2, 2023 at 12:12 AM Han Zhou wrote: > > > > Refactor so that ENGINE_NODE_WITH_CLEAR_TRACK_DATA_IS_VALID can be used outside > > of functions. > > > > Signed-off-by: Han Zhou > > Reviewed-by: Ales Musil > > Acked-by: Numan

Re: [ovs-dev] [PATCH ovn v2 02/14] northd: Enable persistence of logical flows between engine runs.

On Fri, Jun 2, 2023 at 7:56 AM Numan Siddique wrote: > > On Fri, Jun 2, 2023 at 12:12 AM Han Zhou wrote: > > > > This patch ensures logical flows remain persistent between engine runs, > > given there are no changes. In case of any change, it will deconstruct > > and reconstruct the hmap during

Re: [ovs-dev] [PATCH ovn v2 01/14] northd: Remove bfd_connections from northd_data.

On Fri, Jun 2, 2023 at 7:39 AM Numan Siddique wrote: > > On Fri, Jun 2, 2023 at 12:12 AM Han Zhou wrote: > > > > bfd_connections isn't related to the I-P engine node "northd". So move > > it from the northd_data to a local variable of en_lflow_run(). > > > > Signed-off-by: Han Zhou > >

Re: [ovs-dev] [PATCH 0/7] Improve linux QoS for exotic and fast links

On 6/5/23 08:22, Adrian Moreno wrote: On 6/2/23 16:13, Adrian Moreno wrote: There are currently two issues that limit our ability to configure QoS on certain cards in linux: 1) Firstly, the maximum link speed (which is used as maximum rate in some tc classes), is obtained from netdev

Re: [ovs-dev] [PATCH 0/7] Improve linux QoS for exotic and fast links

On 6/2/23 16:13, Adrian Moreno wrote: There are currently two issues that limit our ability to configure QoS on certain cards in linux: 1) Firstly, the maximum link speed (which is used as maximum rate in some tc classes), is obtained from netdev feature bits. This is quite problematic because