Re: [ovs-dev] [PATCH ovs v4] Documentation: Adding note about using the jemalloc library.

2024-02-07 Thread Frode Nordahl
On Mon, Feb 5, 2024 at 1:35 PM Roberto Bartzen Acosta via dev wrote: > > Updating the reference documentation with the inclusion of possible building > problems with libjemalloc and solution suggestions. > > Reported-at: > https://bugs.launchpad.net/ubuntu/+source/openvswitch/+bug/2015748 >

Re: [ovs-dev] [RFC ovn] northd.c: Fix direct access to SNATed networks.

2024-02-07 Thread Mark Michelson
I mentioned Ales in my notes but forgot to CC him in my reply. Whoops. I've added him now :) On 2/7/24 19:22, Mark Michelson wrote: Hi Martin, Thanks a bunch for your first OVN contribution. I have comments below. On 2/7/24 10:56, Martin Kalcok wrote: When a machine from an external network

Re: [ovs-dev] [RFC ovn] northd.c: Fix direct access to SNATed networks.

2024-02-07 Thread Mark Michelson
Hi Martin, Thanks a bunch for your first OVN contribution. I have comments below. On 2/7/24 10:56, Martin Kalcok wrote: When a machine from an external network tries to access machine in the OVN's internal network with SNAT enabled, using protocol like TCP, it receives connection reset after

Re: [ovs-dev] [PATCH] netdev-linux: Avoid deadlock in netdev_get_speed.

2024-02-07 Thread Ilya Maximets
On 2/7/24 22:07, Adrian Moreno wrote: > > > On 2/7/24 19:05, Ilya Maximets wrote: >> On 2/5/24 13:02, Adrian Moreno wrote: >>> netdev_linux_get_speed needs to lock netdev_linux->mutex, and so do the >>> internal tc operations. Therefore, the former cannot be called from the >>> latter. >>> >>>

Re: [ovs-dev] [PATCH] netdev-linux: Avoid deadlock in netdev_get_speed.

2024-02-07 Thread Adrian Moreno
On 2/7/24 19:05, Ilya Maximets wrote: On 2/5/24 13:02, Adrian Moreno wrote: netdev_linux_get_speed needs to lock netdev_linux->mutex, and so do the internal tc operations. Therefore, the former cannot be called from the latter. Create a lock-free version of netdev_linux_get_speed() and call

Re: [ovs-dev] [PATCH] netdev-linux: Avoid deadlock in netdev_get_speed.

2024-02-07 Thread Ilya Maximets
On 2/5/24 13:02, Adrian Moreno wrote: > netdev_linux_get_speed needs to lock netdev_linux->mutex, and so do the > internal tc operations. Therefore, the former cannot be called from the > latter. > > Create a lock-free version of netdev_linux_get_speed() and call it from > tc operations. > >

[ovs-dev] [PATCH v2 2/2] conntrack: Handle persistent selection for IP addresses.

2024-02-07 Thread Paolo Valerio
The patch, when 'persistent' flag is specified, makes the IP selection in a range persistent across reboots. Signed-off-by: Paolo Valerio --- NEWS | 3 ++- lib/conntrack.c | 27 +-- lib/conntrack.h | 1 + lib/dpif-netdev.c | 2 ++ 4 files changed, 26

[ovs-dev] [PATCH v2 1/2] conntrack: Handle random selection for port ranges.

2024-02-07 Thread Paolo Valerio
The userspace conntrack only supported hash for port selection. With the patch, both userspace and kernel datapath support the random flag. The default behavior remains the same, that is, if no flags are specified, hash is selected. Signed-off-by: Paolo Valerio ---

Re: [ovs-dev] [PATCH 2/2] conntrack: Handle persistent selection for IP addresses.

2024-02-07 Thread Paolo Valerio
Paolo Valerio writes: > The patch, when 'persistent' flag is specified, makes the IP selection > in a range persistent across reboots. > > Signed-off-by: Paolo Valerio > --- > NEWS | 3 ++- > lib/conntrack.c | 26 ++ > lib/conntrack.h | 1 + >

[ovs-dev] [PATCH ovn v5 2/2] northd: Explicitly handle SNAT for ICMP need frag.

2024-02-07 Thread Ales Musil
Considering following topology: client - sw0 - lrp0 - lr - lrp1 - sw1 - server sw0 in subnet 192.168.0.0/24 sw1 in subnet 172.168.0.0/24 SNAT configured for client gateway_mtu=1400 configured for lrp0 If we send UDP traffic from client to server and server responds with packet bigger than 1400

[ovs-dev] [PATCH ovn v5 0/2] Keep track of SNAT status for ICMP need frag

2024-02-07 Thread Ales Musil
The ICMP need frag could be generated after routing stage when the unSNAT already happened. Add flows that will ensure that we are keeping track of the CT state and do appropriate CT nat action later on. Because the ICMP traffic is related to already existing one in this case we can use adjusted

[ovs-dev] [PATCH ovn v5 1/2] actions: Adjust the ct_commit_nat action.

2024-02-07 Thread Ales Musil
The ct_commit nat was hardcoded to use DNAT zone in router pipeline. Extend it that it accepts two new arguments (snat/dnat) which will determine the zone for router pipeline. The switch pipeline has only one, so it resolves to the same for both arguments. In order to keep backward compatibility

Re: [ovs-dev] [PATCH master/branch-3.3] faq: Update DPDK releases for older branches.

2024-02-07 Thread Kevin Traynor
On 06/02/2024 12:28, Ilya Maximets wrote: > On 2/2/24 13:46, Kevin Traynor wrote: >> Branches 2.17/3.0/3.1/3.2 are using newer DPDK LTS releases. >> >> Update the faq. >> >> Signed-off-by: Kevin Traynor >> --- >> Documentation/faq/releases.rst | 8 >> 1 file changed, 4 insertions(+), 4

[ovs-dev] [PATCH 2/2] conntrack: Handle persistent selection for IP addresses.

2024-02-07 Thread Paolo Valerio
The patch, when 'persistent' flag is specified, makes the IP selection in a range persistent across reboots. Signed-off-by: Paolo Valerio --- NEWS | 3 ++- lib/conntrack.c | 26 ++ lib/conntrack.h | 1 + lib/dpif-netdev.c | 2 ++ 4 files changed, 27

[ovs-dev] [PATCH 1/2] conntrack: Handle random selection for port ranges.

2024-02-07 Thread Paolo Valerio
The userspace conntrack only supported hash for port selection. With the patch, both userspace and kernel datapath support the random flag. The default behavior remains the same, that is, if no flags are specified, hash is selected. Signed-off-by: Paolo Valerio ---

Re: [ovs-dev] [PATCH ovn v5 0/4] OVN-IC: Add basic sequence number status support.

2024-02-07 Thread Dumitru Ceara
On 1/24/24 15:27, Mohammad Heib wrote: > Currently, OVN-IC doesn't support a way to tell the end-user when their > changes > to the IC-NB database have propagated successfully to the IC-SB Database. > > This patch series adds basic support for the sequence number status protocol > that is

Re: [ovs-dev] [RFC ovn] northd.c: Fix direct access to SNATed networks.

2024-02-07 Thread 0-day Robot
Bleep bloop. Greetings Martin Kalcok, 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 is 88 characters long (recommended limit is 79) WARNING: Comment with 'xxx'

Re: [ovs-dev] [PATCH ovn v4 2/2] northd: Explicitly handle SNAT for ICMP need frag.

2024-02-07 Thread 0-day Robot
Bleep bloop. Greetings Ales Musil, 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. git-am: error: sha1 information is lacking or useless (tests/ovn.at). error: could not build fake ancestor

Re: [ovs-dev] [PATCH ovn v2 26/29] tests: Add macro for OFTABLE_MAC_CACHE_USE table number.

2024-02-07 Thread Mark Michelson
Thank you Ales and Xavier. I applied patches 1-26 to main as is. The patches to remove table numbers from comments can be uploaded as a separate series or part of v3 for patches 27-29. Mark Michelson On 2/6/24 10:01, Ales Musil wrote: On Tue, Feb 6, 2024 at 3:55 PM Xavier Simonart wrote:

[ovs-dev] [RFC ovn] northd.c: Fix direct access to SNATed networks.

2024-02-07 Thread Martin Kalcok
When a machine from an external network tries to access machine in the OVN's internal network with SNAT enabled, using protocol like TCP, it receives connection reset after first packets are successfully exchanged. This setup may be a bit unusual and requires that whatever is responsible for

[ovs-dev] [PATCH ovn v4 2/2] northd: Explicitly handle SNAT for ICMP need frag.

2024-02-07 Thread Ales Musil
Considering following topology: client - sw0 - lrp0 - lr - lrp1 - sw1 - server sw0 in subnet 192.168.0.0/24 sw1 in subnet 172.168.0.0/24 SNAT configured for client gateway_mtu=1400 configured for lrp0 If we send UDP traffic from client to server and server responds with packet bigger than 1400

[ovs-dev] [PATCH ovn v4 1/2] actions: Adjust the ct_commit_nat action.

2024-02-07 Thread Ales Musil
The ct_commit nat was hardcoded to use DNAT zone in router pipeline. Extend it that it accepts two new arguments (snat/dnat) which will determine the zone for router pipeline. The switch pipeline has only one, so it resolves to the same for both arguments. In order to keep backward compatibility

[ovs-dev] [PATCH ovn v4 0/2] Keep track of SNAT status for ICMP need frag

2024-02-07 Thread Ales Musil
The ICMP need frag could be generated after routing stage when the unSNAT already happened. Add flows that will ensure that we are keeping track of the CT state and do appropriate CT nat action later on. Because the ICMP traffic is related to already existing one in this case we can use adjusted

[ovs-dev] [PATCH ovn] tests: Fix macro OVN_CHECK_PACKETS_CONTAIN.

2024-02-07 Thread Xavier Simonart
The macro had two issues: - It never used the third (optional) argument (command such as trim_zeros). - The default command was wrong, causing the test to always succeed. Fixes: 9857ef8f61a0 ("tests: fixed multiple tests not properly waiting for packets to be received") Signed-off-by: Xavier

[ovs-dev] [PATCH net v2 0/2] net: openvswitch: limit the recursions from action sets

2024-02-07 Thread Aaron Conole
Open vSwitch module accepts actions as a list from the netlink socket and then creates a copy which it uses in the action set processing. During processing of the action list on a packet, the module keeps a count of the execution depth and exits processing if the action depth goes too high.

[ovs-dev] [PATCH net v2 2/2] selftests: openvswitch: Add validation for the recursion test

2024-02-07 Thread Aaron Conole
Add a test case into the netlink checks that will show the number of nested action recursions won't exceed 16. Going to 17 on a small clone call isn't enough to exhaust the stack on (most) systems, so it should be safe to run even on systems that don't have the fix applied. Signed-off-by: Aaron

[ovs-dev] [PATCH net v2 1/2] net: openvswitch: limit the number of recursions from action sets

2024-02-07 Thread Aaron Conole
The ovs module allows for some actions to recursively contain an action list for complex scenarios, such as sampling, checking lengths, etc. When these actions are copied into the internal flow table, they are evaluated to validate that such actions make sense, and these calls happen recursively.

Re: [ovs-dev] [PATCH ovs v4] Documentation: Adding note about using the jemalloc library.

2024-02-07 Thread Eelco Chaudron
On 5 Feb 2024, at 13:36, Roberto Bartzen Acosta via dev wrote: > Updating the reference documentation with the inclusion of possible building > problems with libjemalloc and solution suggestions. > > Reported-at: > https://bugs.launchpad.net/ubuntu/+source/openvswitch/+bug/2015748 >

Re: [ovs-dev] [PATCH v3 3/4] dp-packet: Include inner offsets in adjustments and checks.

2024-02-07 Thread Simon Horman
On Tue, Feb 06, 2024 at 11:15:24AM -0500, Mike Pattrick wrote: > Include inner offsets in functions where l3 and l4 offsets are either > modified or checked. > > Fixes: 084c8087292c ("userspace: Support VXLAN and GENEVE TSO.") > Signed-off-by: Mike Pattrick ... > diff --git

Re: [ovs-dev] [PATCH ovs v4] Documentation: Adding note about using the jemalloc library.

2024-02-07 Thread Simon Horman
On Mon, Feb 05, 2024 at 09:36:14AM -0300, Roberto Bartzen Acosta via dev wrote: > Updating the reference documentation with the inclusion of possible building > problems with libjemalloc and solution suggestions. > > Reported-at: >

Re: [ovs-dev] [PATCH] netdev-linux: Avoid deadlock in netdev_get_speed.

2024-02-07 Thread Simon Horman
On Mon, Feb 05, 2024 at 01:02:10PM +0100, Adrian Moreno wrote: > netdev_linux_get_speed needs to lock netdev_linux->mutex, and so do the > internal tc operations. Therefore, the former cannot be called from the > latter. > > Create a lock-free version of netdev_linux_get_speed() and call it from