For packets which don't already have a hash calculated,
miniflow_hash_5tuple() calculates the hash of a packet
using the previously built miniflow.
This commit adds IPv6 profile specific hashing which
uses fixed offsets into the packet to improve hashing
performance.
Signed-off-by: Kumar Amber
-
Add AVX512 Ipv6 optimized profile for vlan/IPv6/UDP and
vlan/IPv6/TCP, IPv6/UDP and IPv6/TCP.
MFEX autovalidaton test-case already has the IPv6 support for
validating against the scalar mfex.
Signed-off-by: Kumar Amber
Signed-off-by: Harry van Haaren
Co-authored-by: Harry van Haaren
---
v7:
-
The patch removes magic numbers pkt offsets and
minimum packet lenght and instead calculate it at
compile time.
Signed-off-by: Kumar Amber
---
lib/dpif-netdev-extract-avx512.c | 28
1 file changed, 20 insertions(+), 8 deletions(-)
diff --git a/lib/dpif-netdev-extrac
The patch removes magic numbers from miniflow_bits
and calculates the bits at compile time. This also
makes it easier to handle any ABI changes.
Signed-off-by: Kumar Amber
---
lib/dpif-netdev-extract-avx512.c | 21 +
1 file changed, 17 insertions(+), 4 deletions(-)
diff --gi
The patchset introuduces IPv6 optimized MFEX profiles
with AVX512 which can deliver upto 20% to 30% gain in
performance over the existing scalar data-path.
Hashing Optimization are also included which can further
improve performance by approximately 10%.
The patch also removes the magic numbers f
On Wed, May 4, 2022 at 9:05 AM Venugopal Iyer wrote:
>
> Changes look good to me Han.
>
> thanks!
>
> -venu
>
Thanks Venu. I merged to main and backported to branch-22.03.
Han
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailma
On Wed, May 4, 2022 at 4:22 PM Han Zhou wrote:
>
>
>
> On Wed, May 4, 2022 at 3:44 PM Numan Siddique wrote:
> >
> > On Tue, May 3, 2022 at 7:32 PM Han Zhou wrote:
> > >
> > > On Thu, Apr 28, 2022 at 9:36 AM Dumitru Ceara
wrote:
> > > >
> > > > This uses the newly added ovsdb_idl_set_write_chang
Hello Alin,
Alin-Gabriel Serdean writes:
> Signed-off-by: Alin-Gabriel Serdean
> ---
> Documentation/howto/qos.rst | 8
> .../internals/contributing/documentation-style.rst| 2 +-
> Documentation/topics/testing.rst | 2 +-
If multiple distributed gateway ports (DGP) are configured on a
logical router, "gateway_port" column needs to be set for NAT entries
of the logical router for the rules to be applied, as part of commit
2d942be (northd: Add support for NAT with multiple DGP).
This patch updates the behavior by inf
On 28/04/2022 17:12, lin huang wrote:
Hi Kevin,
Hi Lin,
I don't see this issue locally. Not sure what I am missing.
# /root/ovs/utilities/ovs-vsctl --no-wait set open_vSwitch .
other_config:pmd-auto-lb-rebal-interval="-0"
# 2022-04-28T14:01:07Z|00359|dpif_netdev|INFO|PMD auto load balance
From: wenxu
In case almost or all available ports are taken, clash resolution can
take a very long time, resulting in pmd lockup.
This can happen when many to-be-natted hosts connect to same
destination:port (e.g. a proxy) and all connections pass the same SNAT.
Pick a random offset in the acce
From: wenxu
Removing the IP iterations, and just picking the IP address
with the hash base on the least-used src-ip/dst-ip/proto triple.
Signed-off-by: wenxu
Acked-by: Paolo Valerio
---
lib/conntrack.c | 86 +
1 file changed, 13 insertio
When multiple chassis are set in requested-chassis, port binding is
configured in multiple cluster locations. In case of live migration
scenario, only one of the locations run a workload at a particular
point in time. Yet, it's expected that the workload may switch to
running at an additional chass
When options:activation-strategy is set to "rarp" for LSP, when used in
combination with multiple chassis names listed in
options:requested-chassis, additional chassis will install special flows
that would block all ingress and egress traffic for the port until a
special activation event happens.
When the option is set to a comma separated list of chassis names, OVN
will attempt to bind the port at any number of other locations in
addition to the main chassis.
This is useful in live migration scenarios where it's important to
prepare the environment for workloads to move to, avoiding costl
In a future patch, there will be a scenario where the same port has
attachments at multiple (specifically, 2) chassis, so make sure that
'up' property is updated by the main chassis only.
Signed-off-by: Ihar Hrachyshka
---
controller/binding.c| 10 +++---
controller/binding.h
A next patch may need to clone packets to another chassis as part of
"port migration" procedure, but only if they haven't originated at
another chassis. This LOCAL_ONLY tag will enforce the requirement.
Signed-off-by: Ihar Hrachyshka
---
controller/physical.c | 1 +
controller/pinctrl.c | 2 ++
Hi,
this is just a rebase of v5 (had to reconcile with the code that unsets
encap in south db.)
===
v6: rebased, solved git conflicts.
v5: moved activation flows from table=8 to table=0.
v5: removed pause=true from rarp activation flow since we don't rely on
continuations.
v5: make rarp hand
we...@chinatelecom.cn writes:
> From: wenxu
>
> In case almost or all available ports are taken, clash resolution can
> take a very long time, resulting in soft lockup.
>
> This can happen when many to-be-natted hosts connect to same
> destination:port (e.g. a proxy) and all connections pass the
we...@chinatelecom.cn writes:
> From: wenxu
>
> Removing the IP iterations, and just picking the IP address
> with the hash base on the least-used src-ip/dst-ip/proto triple.
>
> Signed-off-by: wenxu
> ---
> lib/conntrack.c | 80
> -
> 1
While becoming a follower, the leader completes all the current
'in-flight' commands, so the higher layers can re-try corresponding
transactions when the new leader is elected. However, most of these
commands are already sent to followers as append requests, hence they
will actually be committed b
On 28/03/2022 15:17, David Marchand wrote:
This is a RFC about trying to save some power, by putting the PMD threads
CPU to sleep in some circumstances.
This is probably not a full solution, but sending this to get
feedback.
Hi David,
Thanks for working on this. Initial comments below. I thin
Hi Cian,
Few comments inline.
> diff --git a/acinclude.m4 b/acinclude.m4 index 61e88105f..7b2889a40 100644
> --- a/acinclude.m4
> +++ b/acinclude.m4
> @@ -73,16 +73,13 @@ AC_DEFUN([OVS_CHECK_DPIF_AVX512_DEFAULT], [
>
> dnl OVS_CHECK_AVX512
> dnl
> -dnl Checks if compiler and binutils support
On 4/12/22 13:49, Christophe Fontaine wrote:
This config param allows the delivery of broadcast and multicast packets
to the secondary interface of non-lacp bonds, equivalent to the option
"all_slaves_active" for kernel bonds.
Reported-at: https://bugzilla.redhat.com/show_bug.cgi?id=1720935
Si
On 5/4/22 18:51, num...@ovn.org wrote:
From: Numan Siddique
ovsdb-server already supports specifying the uuid in the insert
transaction by the client. But the C IDL client library was
missing this feature. This patch adds this support.
For each schema table, a new function is generated -
i
On 5/4/22 18:53, Numan Siddique wrote:
On Tue, Apr 26, 2022 at 7:39 AM Adrian Moreno wrote:
Hi Numan,
Apart from a couple of small coments below, I'm wondering if this is a good time
to surface this to ovs-*ctl commands. What do you think?
Hi Adrian,
Thanks for the review. I thought abo
From: wenxu
Removing the IP iterations, and just picking the IP address
with the hash base on the least-used src-ip/dst-ip/proto triple.
Signed-off-by: wenxu
---
lib/conntrack.c | 80 -
1 file changed, 10 insertions(+), 70 deletions(-)
d
From: wenxu
In case almost or all available ports are taken, clash resolution can
take a very long time, resulting in soft lockup.
This can happen when many to-be-natted hosts connect to same
destination:port (e.g. a proxy) and all connections pass the same SNAT.
Pick a random offset in the acc
wenxu writes:
> On 2022/5/5 0:55, Paolo Valerio wrote:
>> Hello wenxu,
>>
>> Overall, I'm ok with the change. I think we should consider the case of
>> , e.g. ICMP (identifier), as in that scenario, the avoidance is solely
>> based on the randomness of the originating ends. Probably we may want t
> -Original Message-
> From: Ilya Maximets
> Sent: Wednesday 4 May 2022 22:31
> To: Ferriter, Cian ; ovs-dev@openvswitch.org
> Cc: i.maxim...@ovn.org
> Subject: Re: [ovs-dev] [PATCH] Documentation: Clarify QEMU version
> requirement.
>
> On 4/26/22 18:25, Cian Ferriter wrote:
> > The
On 2022/5/5 0:55, Paolo Valerio wrote:
> Hello wenxu,
>
> Overall, I'm ok with the change. I think we should consider the case of
> , e.g. ICMP (identifier), as in that scenario, the avoidance is solely
> based on the randomness of the originating ends. Probably we may want to
> consider solving a
31 matches
Mail list logo
