Pinning an rxq to a PMD with pmd-rxq-affinity may be done for
various reasons such as reserving a full PMD for an rxq, or to
ensure that multiple rxqs from a port are handled on different PMDs.
Previously pmd-rxq-affinity always isolated the PMD so no other rxqs
could be assigned to it by OVS. The
Previously, if pmd-rxq-affinity was used to pin an rxq to
a core that was not in pmd-cpu-mask the rxq was not polled
and the user received a warning.
Now that pinned and non-pinned rxqs are assigned to PMDs in
a common call to rxq scheduling, if an invalid core is
selected in pmd-rxq-affinity the
Add an rxq scheduling option that allows rxqs to be grouped
on a pmd based purely on their load.
The current default 'cycles' assignment sorts rxqs by measured
processing load and then assigns them to a list of round robin PMDs.
This helps to keep the rxqs that require most processing on different
PMD auto load balance had its own separate implementation of the
rxq scheduling that it used for dry runs. This was done because
previously the rxq scheduling was not reusable for a dry run.
Apart from the code duplication (which is a good enough reason
to replace it alone) this meant that if any
This reworks the current rxq scheduling code to break it into more
generic and reusable pieces.
The behaviour does not change from a user perspective, except the logs
are updated to be more consistent.
>From an implementation view, there are some changes with mind to adding
functionality and reus
The first two patches do not provide new functionality for the user
(except the logs are reworked). They are reworking to make the
rxq scheduling and PMD auto load balance code more modular for cleanup
and to be used by subsequent patches. They are also removing the code
duplication between them by
On 6/2/2021 3:00 PM, Toms Atteka wrote:
This optimization caused FLOW_TNL_F_UDPIF flag not to be used in
hash calculation for geneve tunnel when revalidating flows which
resulted in different cache hash values and incorrect behaviour.
Added test to prevent regression.
Reported-at: https://gi
Inspried by:
3b6362d64e86b northd: Avoid memory reallocation while building lb rules.
Signed-off-by: Dan Williams
---
NOTE: this is driven by visual inspection not perf data. But it
shouldn't be worse than current code and should be better for
large numbers of ACLs I think.
northd/ovn-northd.c
> Here is a patch with both a test and a fix.
Hi. Thanks for working n this!
CC: ovs-dev
> Not submitting as a formal
> patch because I would like some feedback on whether 1) maintainers feel
> this is worth fixing and
I can reproduce the crash with your test. Basically, actions in userspace
ovn-trace does not set translated ip address for ct_dnat()
actions when tracing. This causes the trace to end prematurely.
This can be tested with the following or an equivalent for IPv6:
ovn-nbctl ls-add sw0
ovn-nbctl lsp-add sw0 sw0-port1
ovn-nbctl lsp-set-addresses sw0-port1 "50:54:00:00:00:01
Add a rule to drop traffic from a distributed NAT if the virtual
port has not claimed yet becaused otherwise the traffic will be
centralized misconfiguring the TOR switch.
https://bugzilla.redhat.com/show_bug.cgi?id=1952961
Signed-off-by: Lorenzo Bianconi
---
northd/ovn-northd.c | 23 +++
This is benign but AddressSanitizer was complaining about it:
Direct leak of 40 byte(s) in 1 object(s) allocated from:
#0 0x7fa93cd6d667 in __interceptor_malloc (/lib64/libasan.so.6+0xb0667)
#1 0x1be8d3e in xmalloc__ lib/util.c:137
#2 0x1be8e1a in xmalloc lib/util.c:172
#3 0x1b799d
On 6/4/21 6:11 PM, Mark Gray wrote:
> On 04/06/2021 16:11, Dumitru Ceara wrote:
>> On 6/4/21 4:51 PM, Mark Gray wrote:
>>> On 03/06/2021 16:06, Dumitru Ceara wrote:
Assuming a load balancer, LB1, with:
- VIP: 42.42.42.42:4242
- backend: 42.42.42.1:2121
A client might connec
On 04/06/2021 16:11, Dumitru Ceara wrote:
> On 6/4/21 4:51 PM, Mark Gray wrote:
>> On 03/06/2021 16:06, Dumitru Ceara wrote:
>>> Assuming a load balancer, LB1, with:
>>> - VIP: 42.42.42.42:4242
>>> - backend: 42.42.42.1:2121
>>>
>>> A client might connect to the backend either directly or through t
On 6/4/21 5:55 PM, Mark Gray wrote:
> On 03/06/2021 16:05, Dumitru Ceara wrote:
>> Automatically create an OVS Datapath record if none exists for the
>> current br-int datapath type.
>>
>> Add a 'features' module to track which OVS features are available in
>> the datapath currently being used. Fo
On 04/06/2021 15:59, Dumitru Ceara wrote:
> On 6/4/21 4:50 PM, Mark Gray wrote:
>> On 03/06/2021 16:05, Dumitru Ceara wrote:
>>> This depends on the following OVS patch to be accepted:
>>>
>>> https://patchwork.ozlabs.org/project/openvswitch/patch/162264080113.315078.1220132318734842720.stgit@ebuil
On 04/06/2021 16:03, Dumitru Ceara wrote:
> On 6/4/21 4:50 PM, Mark Gray wrote:
>> On 03/06/2021 16:05, Dumitru Ceara wrote:
>>> This ensures the datapath type is properly set for the bridge.
>>
>> I don't understand how this causes a problem? Can you provide additional
>> context?
>
> br-int and
On 03/06/2021 16:05, Dumitru Ceara wrote:
> Automatically create an OVS Datapath record if none exists for the
> current br-int datapath type.
>
> Add a 'features' module to track which OVS features are available in
> the datapath currently being used. For now, only ct_zero_snat is
> tracked, all
On 6/4/21 4:51 PM, Mark Gray wrote:
> On 03/06/2021 16:06, Dumitru Ceara wrote:
>> Assuming a load balancer, LB1, with:
>> - VIP: 42.42.42.42:4242
>> - backend: 42.42.42.1:2121
>>
>> A client might connect to the backend either directly or through the
>> VIP. If the first connection is via the VIP
On 6/4/21 4:50 PM, Mark Gray wrote:
> On 03/06/2021 16:05, Dumitru Ceara wrote:
>> This ensures the datapath type is properly set for the bridge.
>
> I don't understand how this causes a problem? Can you provide additional
> context?
br-int and br-ex are patched together by ovn-controller. They
On 6/4/21 4:51 PM, Mark Gray wrote:
> On 03/06/2021 16:05, Dumitru Ceara wrote:
>> Bump the OVS submodule to include the following patches:
>> dd0f59783e39 ("ofproto: Fix p otential NULL dereference in
>> ofproto_get_datapath_cap().")
>> a4b04276ab59 ("ofproto: Fix potential NULL dereference i
On 6/4/21 4:50 PM, Mark Gray wrote:
> On 03/06/2021 16:05, Dumitru Ceara wrote:
>> This depends on the following OVS patch to be accepted:
>>
>> https://patchwork.ozlabs.org/project/openvswitch/patch/162264080113.315078.1220132318734842720.stgit@ebuild/
>
> Just to be clear, will this break OVN wi
On 6/4/21 4:34 PM, Dan Williams wrote:
> On Fri, 2021-06-04 at 12:00 +0200, Dumitru Ceara wrote:
>> Due to a bug in glibc [0], M_TRIM_THRESHOLD (default 128KB) is not
>> honored. The lflow cache is one of the largest memory consumers in
>> ovn-controller and it used to trim memory whenever the cac
On 03/06/2021 16:06, Dumitru Ceara wrote:
> Assuming a load balancer, LB1, with:
> - VIP: 42.42.42.42:4242
> - backend: 42.42.42.1:2121
>
> A client might connect to the backend either directly or through the
> VIP. If the first connection is via the VIP and the second connection
> is direct but
From 07ecd5d00f82658e094132102575d8d576161a6b Mon Sep 17 00:00:00 2001
From: Brendan Doyle
Date: Fri, 28 May 2021 10:01:17 -0700
Subject: [PATCH ovn] ovn-northd.c: Add proxy ARP support to OVN
This patch provides the ability to configure proxy ARP IPs on a Logical
Switch Router port. The IPs are
On 03/06/2021 16:05, Dumitru Ceara wrote:
> Bump the OVS submodule to include the following patches:
> dd0f59783e39 ("ofproto: Fix p otential NULL dereference in
> ofproto_get_datapath_cap().")
> a4b04276ab59 ("ofproto: Fix potential NULL dereference in
> ofproto_ct_*_zone_timeout_policy().")
On 03/06/2021 16:05, Dumitru Ceara wrote:
> This ensures the datapath type is properly set for the bridge.
I don't understand how this causes a problem? Can you provide additional
context?
>
> a8362ff85dee ("northd: Fix the missing force_snat_for_lb flows when router_ip
> is configured.")
> Sig
On 03/06/2021 16:05, Dumitru Ceara wrote:
> This depends on the following OVS patch to be accepted:
>
> https://patchwork.ozlabs.org/project/openvswitch/patch/162264080113.315078.1220132318734842720.stgit@ebuild/
Just to be clear, will this break OVN without the above patch? Can this
be applied w
On 5/27/21 3:28 PM, Ilya Maximets wrote:
> This patch set adds new stream provider and other functionality in
> order to record all the incoming data on all the steams (ssl, tcp,
> unixctl) of openvswitch library based applications and replay these
> streams later for debugging purposes or performa
On 5/27/21 3:29 PM, Ilya Maximets wrote:
> For debugging purposes it is useful to be able to record all the
> incoming transactions and commands and replay them locally under
> debugger or with additional logging enabled. This patch introduces
> ability to record all the incoming stream data and r
On Fri, 2021-06-04 at 12:00 +0200, Dumitru Ceara wrote:
> Due to a bug in glibc [0], M_TRIM_THRESHOLD (default 128KB) is not
> honored. The lflow cache is one of the largest memory consumers in
> ovn-controller and it used to trim memory whenever the cache was
> flushed. However, that required pe
Hi,
On Thu, May 20, 2021 at 08:48:53AM -0700, Marcelo Ricardo Leitner wrote:
> Hi,
>
> On Mon, May 17, 2021 at 01:18:53PM +0200, Simon Horman wrote:
...
> > @@ -2593,24 +2601,50 @@ tc_matchall_fill_police(uint32_t kbits_rate,
> > uint32_t kbits_burst)
> > }
> >
> > static void
> > -nl_msg_pu
On 5/28/21 9:23 PM, Han Zhou wrote:
> If a lflow has an lport name in the match, but when the lflow is
> processed the port-binding is not seen by ovn-controller, the
> corresponding openflow will not be created. Later if the port-binding is
> created/monitored by ovn-controller, the lflow is not r
On 5/28/21 9:23 PM, Han Zhou wrote:
> This patch removes the workaround when adding multicast group related
> lflows, because the multicast group dependency problem is fixed in
> ovn-controller in the previous commit.
>
> This patch also removes the UniqueFlow/AnnotatedFlow usage in northd
> DDlog
On 5/28/21 9:23 PM, Han Zhou wrote:
> Multicast group changes are handled for physical flows in I-P, but not
> handled for logical flows. Although logical flow doesn't care about the
> content of a multicast group, the existance of it matters for logical
> flow processing. If the multicast group is
On 5/28/21 9:23 PM, Han Zhou wrote:
> The series fixes incremental processing for missing dependency handling for
> multicast group and logical port binding changes when computing logical flows.
> It also removes the workaround in northd that was required due to the missing
> dependency handling. I
On 27 May 2021, at 21:15, Aaron Conole wrote:
> This makes openvswitch module use the event tracing framework
> to log the upcall interface and action execution pipeline. When
> using openvswitch as the packet forwarding engine, some types of
> debugging are made possible simply by using the ov
On 03/06/2021 16:59, Dan Williams wrote:
On Wed, 2021-06-02 at 17:02 +0100, Brendan Doyle wrote:
From a9d3140845175edb7644b2d0d82a95bd6cf94662 Mon Sep 17 00:00:00 2001
From: Brendan Doyle
Date: Fri, 28 May 2021 10:01:17 -0700
Subject: [PATCH ovn] ovn-northd.c: Add proxy ARP support to OVN
Due to a bug in glibc [0], M_TRIM_THRESHOLD (default 128KB) is not
honored. The lflow cache is one of the largest memory consumers in
ovn-controller and it used to trim memory whenever the cache was
flushed. However, that required periodic intervention from the CMS
side.
Instead, we now automati
Add a test to ensure that rxq assignment to pmds can be done when
there are non-contiguous numa nodes.
Signed-off-by: Kevin Traynor
---
tests/pmd.at | 38 --
1 file changed, 36 insertions(+), 2 deletions(-)
diff --git a/tests/pmd.at b/tests/pmd.at
index 3e6d6
On 25/05/2021 20:27, David Wilder wrote:
> If not supplied by the user --socket-mem and --socket-limit EAL options
> are set to a default value based system topology. The assumption that
> numa nodes must be numbered contiguously is removed by this change.
>
> These options can be seen in the ovs-
On 25/05/2021 20:27, David Wilder wrote:
> This change removes the assumption that numa nodes and cores are numbered
> contiguously in linux. This change is required to support some Power
> systems.
>
> An additional check has been added to verify that cores are online,
> offline cores result in
On 03/06/2021 23:50, Lorenzo Bianconi wrote:
> This series respin CoPP support introduced here [0] by Dumitru rebasing on top
> of ovn master branch and adding some missing meters (e.g. bfd or acl reject).
> The main goal of this series is to continue the discussion about the proposed
> approach an
43 matches
Mail list logo
