Re: [ovs-dev] [PATCH ovn 4/5] northd: Move port group processing to its own I-P node.

On Thu, Aug 10, 2023 at 5:45 AM Dumitru Ceara wrote: > > For now it's still a node recompute for every port group change. It > doesn't trigger northd recompute anymore though. > > A follow up commit will add incremental processing of NB.Port_Group > changes. > > Signed-off-by: Dumitru Ceara > --

Re: [ovs-dev] [PATCH ovn 3/5] northd: Move port group processing to its separate module.

On Thu, Aug 10, 2023 at 5:45 AM Dumitru Ceara wrote: > > No functional differences in this commit, just abstract out the > processing a bit. > > Signed-off-by: Dumitru Ceara > --- > northd/automake.mk |2 > northd/en-port-group.c | 237 ++ > n

Re: [ovs-dev] [PATCH ovn 2/5] northd: Merge port group related structures.

On Mon, Aug 21, 2023 at 11:23 PM Ales Musil wrote: > > > > On Thu, Aug 10, 2023 at 2:44 PM Dumitru Ceara wrote: >> >> There's currently no need to store both 'ovn_ls_port_group' >> and 'ovn_port_group_ls' so just use the first type. >> >> Signed-off-by: Dumitru Ceara > > > Hi Dumitru, > > I have

[ovs-dev] [RFC OVN] DHCP Proxy Agent support for overlay subnets

This patch contains changes to enable DHCP Proxy Agent support for overlay subnets. NOTE: - - This patch is not complete, sending this to get the initial feedback about the approach taken. USE CASE: -- - Enable IP address assignment for overlay subnets from the centralized DHCP

[ovs-dev] [PATCH v5] ofproto-dpif-xlate: Don't reinstall removed XC_LEARN rule

When the a revalidator thread is updating statistics for an XC_LEARN xcache entry in xlate_push_stats_entry it uses ofproto_flow_mod_learn. The revalidator will update stats for rules even if they are in a removed state or marked as invisible. However, ofproto_flow_mod_learn will detect if a flow h

Re: [ovs-dev] [PATCH RFC] conntrack: Remove nat_conn introducing key directionality.

Paolo Valerio writes: > From: hepeng > > The patch avoids the extra allocation for nat_conn. > Currently, when doing NAT, the userspace conntrack will use an extra > conn for the two directions in a flow. However, each conn has actually > the two keys for both orig and rev directions. This patch

Re: [ovs-dev] [PATCH 0/4] Fix -std=c99 builds.

On 22 Aug 2023, at 12:35, Ilya Maximets wrote: > It should generally be possible to build OVS with just C99. > We do need some POSIX extensions, e.g. support for RW locks, > but we should not require any GNU extensions or features > from later C standards. > > Ilya Maximets (4): > compiler.h:

Re: [ovs-dev] [PATCH] netdev-dpdk: Clear IP packet type when no offload is requested.

On Tue, Aug 22, 2023 at 4:11 AM David Marchand wrote: > > OVS current sets RTE_MBUF_F_TX_IPV[46] flags in early stages of the > packet reception and keeps track of the IP packet type as the packet > goes through OVS pipeline. > When a packet leaves OVS and hits a DPDK driver, OVS may not request I

Re: [ovs-dev] [PATCH ovn v2 5/5] ovn-nbctl: Prevent sync exiting early on nb_cfg overflow

On 8/22/23 01:38, Ales Musil wrote: On Mon, Aug 21, 2023 at 8:00 PM Mark Michelson > wrote: Hi Ales, I agree with this change, and for the code itself, Acked-by: Mark Michelson mailto:mmich...@redhat.com>> However, I'm curious why this is grouped

[ovs-dev] [PATCH 4/4] ci: Add jobs to test -std=c99 builds.

It should generally be possible to build OVS with mostly c99 standard and without GNU extensions. It's not a pure c99 build, because some non-standard features from POSIX variants are always enabled if available via AC_USE_SYSTEM_EXTENSIONS. Without them we'll not have some essentials like RW loc

[ovs-dev] [PATCH 3/4] tests: Fix order of includes in barrier/id-fpool/mpsc-queue tests.

config.h must be included first, because it affects all the later included headers, even the system ones. Also, struct timeval requires inclusion of sys/time.h. This fixes the build with CC=clang CFLAGS='-std=c99 -fgnuc-version=0' Fixes: aec1081c7df3 ("tests: Add ovs-barrier unit test.") Fixes:

[ovs-dev] [PATCH 2/4] sflow: Always enable _BSD_SOURCE.

sFlow library is using BSD-style types like u_char that require _BSD_SOURCE to be defined. Also adding _DEFAULT_SOURCE, because _BSD_SOURCE cannot be used without it with glibc > 2.19: error: "_BSD_SOURCE and _SVID_SOURCE are deprecated, use _DEFAULT_SOURCE" Signed-off-by: Ilya Maxim

[ovs-dev] [PATCH 1/4] compiler.h: Don't use asm and typeof with non-GNU compilers.

'asm' is a GNU extension. Compilers without GNU extensions do not understand it: dpif-netdev-perf.h:225:5: error: use of undeclared identifier 'asm' asm volatile("rdtsc" : "=a" (l), "=d" (h)); Redefining asm as __asm__ for non-C++ compilers that do not have it defined. While at it, also

[ovs-dev] [PATCH 0/4] Fix -std=c99 builds.

It should generally be possible to build OVS with just C99. We do need some POSIX extensions, e.g. support for RW locks, but we should not require any GNU extensions or features from later C standards. Ilya Maximets (4): compiler.h: Don't use asm and typeof with non-GNU compilers. sflow: Alway

Re: [ovs-dev] [RFC] netdev: Disable Tx offloads.

On 22 Aug 2023, at 11:28, David Marchand wrote: > Following support of L3 and L4 checksum offloading, some bugs have been > raised in different DPDK drivers. So to clarify this a bit more we see issues with OVS 3.2 and the i40e vf driver and net/tap driver. Mike can you take a look at this p

[ovs-dev] [RFC] netdev: Disable Tx offloads.

Following support of L3 and L4 checksum offloading, some bugs have been raised in different DPDK drivers. When faced with such bugs, a OVS user can't do anything but wait for a DPDK fix (which can take some time to make it to the LTS releases). Make it possible for the user to disable some Tx offl

Re: [ovs-dev] [PATCH] lib/fatal-signal: Drop logging of failed dummy backtrace.

On Tue, Aug 22, 2023 at 10:40 AM Frode Nordahl wrote: > Some systems may provide backtrace() in libc but for some reason > not provide any frames when attempting to use it. > > On those systems the fatal_signal_init() function currently logs > this debug message: "Capturing of dummy backtrace has

[ovs-dev] [PATCH] lib/fatal-signal: Drop logging of failed dummy backtrace.

Some systems may provide backtrace() in libc but for some reason not provide any frames when attempting to use it. On those systems the fatal_signal_init() function currently logs this debug message: "Capturing of dummy backtrace has failed." A consequence of this logging may be false negative te

Re: [ovs-dev] [PATCH] netdev-dpdk: Clear IP packet type when no offload is requested.

Bleep bloop. Greetings David Marchand, 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: Line lacks whitespace around operator #31 FILE: lib/netdev-dpdk.c:2434: mbuf

[ovs-dev] [PATCH] netdev-dpdk: Clear IP packet type when no offload is requested.

OVS current sets RTE_MBUF_F_TX_IPV[46] flags in early stages of the packet reception and keeps track of the IP packet type as the packet goes through OVS pipeline. When a packet leaves OVS and hits a DPDK driver, OVS may not request IP checksum offloading but leaves one of this packet type flag in