The comment is misleading. The conjunctive match IDs always starts from
1 instead of 0.
Signed-off-by: Han Zhou
---
lib/expr.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/expr.c b/lib/expr.c
index 47ef6108e..caae0d4b2 100644
--- a/lib/expr.c
+++ b/lib/expr.c
@@
This is not needed any more and force_crossproduct is always false.
Signed-off-by: Han Zhou
---
lib/expr.c | 15 +--
1 file changed, 1 insertion(+), 14 deletions(-)
diff --git a/lib/expr.c b/lib/expr.c
index 47ef6108e..77c67cde4 100644
--- a/lib/expr.c
+++ b/lib/expr.c
@@ -33,19
> -Original Message-
> From: Ilya Maximets
> Sent: Wednesday, March 30, 2022 1:45 AM
> To: Morten Brørup ; Richardson, Bruce
>
> Cc: i.maxim...@ovn.org; Maxime Coquelin ;
> Van Haaren, Harry ; Pai G, Sunil
> ; Stokes, Ian ; Hu, Jiayu
> ; Ferriter, Cian ; ovs-
> d...@openvswitch.org;
Hi Mark,
I've redesigned the whole thing to reuse options:requested-chassis
(which is now comma separated list of chassis); db wise it's also
backwards compatible (additional chassis are still tracked in a separate
additional_chassis field, which is a list of chassis ids). The patch
series
When chassis-mirroring-enabled is set, controller will not enforce
tunneling for localnet-attached switches. This may be useful when the
network used to deliver tunnel packets doesn't have MTU headway to
redirect all packets originally sent through localnet port.
Signed-off-by: Ihar Hrachyshka
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
Signed-off-by: Ihar Hrachyshka
---
NEWS | 3 +++
1 file changed, 3 insertions(+)
diff --git a/NEWS b/NEWS
index 3e8358723..944401c5c 100644
--- a/NEWS
+++ b/NEWS
@@ -4,6 +4,9 @@ Post v22.03.0
different OVN Interconnection availability zones.
- Replaced the usage of masked ct_label by
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.
It takes some time for vswitchd to remove the blocking flows, so we need
to wait for the flow_mod message handled before reinjecting the received
RARP packet into the pipeline.
Use a barrier to indicate the message processed by vswitchd.
Signed-off-by: Ihar Hrachyshka
---
controller/pinctrl.c
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
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 ++
This helper prepares a 'match' struct to match against a datapath and
a port key. All existing spots in the file that use such a 'match'
struct were updated. It will also be reused later.
Signed-off-by: Ihar Hrachyshka
---
controller/physical.c | 65 +++
Signed-off-by: Ihar Hrachyshka
---
controller/physical.c | 50 ---
1 file changed, 19 insertions(+), 31 deletions(-)
diff --git a/controller/physical.c b/controller/physical.c
index 1c31741ea..0426098b2 100644
--- a/controller/physical.c
+++
Right now consider_port_binding first extracts *a* tunnel for a
chassis, then later in put_remote_port_redirect_overlay it fetches
*the* proper tunnel before configuring encapsulation.
Instead of doing it in two steps, just extract the proper tunnel info
earlier.
Signed-off-by: Ihar Hrachyshka
Next patches will need the same functionality while passing a
different chassis / encap configuration that is not the primary for a
port binding.
Signed-off-by: Ihar Hrachyshka
---
controller/physical.c | 13 ++---
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git
The ovn_port_update_sbrec function became too long, and the next
patches will touch the code to update chassis mapping for ports. This
patch prepares for the next step.
Signed-off-by: Ihar Hrachyshka
---
northd/northd.c | 62 -
1 file changed, 36
This function will be reused later.
Signed-off-by: Ihar Hrachyshka
---
northd/northd.c | 21 +++--
1 file changed, 15 insertions(+), 6 deletions(-)
diff --git a/northd/northd.c b/northd/northd.c
index 2fb0a93c2..17af42ac4 100644
--- a/northd/northd.c
+++ b/northd/northd.c
@@
This tiny helper will be reused later.
Signed-off-by: Ihar Hrachyshka
---
controller/physical.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/controller/physical.c b/controller/physical.c
index 02fcd5ea8..51901395d 100644
--- a/controller/physical.c
+++
This version of the series switched to supporting multiple chassis set in
requested-chassis option. This allows for more than two chassis
specified for the same port.
Also, this series includes a patch that allows to disable tunneling
enforcement for ports with multiple chassis set in
On Tue, Mar 29, 2022 at 2:20 PM Numan Siddique wrote:
>
> On Mon, Mar 28, 2022 at 1:40 AM Han Zhou wrote:
> >
> > Some NICs support HW offloading for datapath flows, but masked access to
> > the 128-bit ct_label field may prevent a flow being offloaded due to HW
> > limitations. OVN's use of
On Tue, Mar 29, 2022 at 5:43 PM Han Zhou wrote:
>
> On Tue, Mar 29, 2022 at 2:19 PM Numan Siddique wrote:
> >
> > On Mon, Mar 28, 2022 at 1:48 AM Han Zhou wrote:
> > >
> > > Add an engine node en_northd_internal_version as an input to
> > > en_lflow_output. When this node is updated, it
On Tue, Mar 29, 2022 at 2:19 PM Numan Siddique wrote:
>
> On Mon, Mar 28, 2022 at 1:48 AM Han Zhou wrote:
> >
> > Add an engine node en_northd_internal_version as an input to
> > en_lflow_output. When this node is updated, it triggers a recompute for
> > en_lflow_output. This node adds SB_Global
On Mon, Mar 28, 2022 at 1:40 AM Han Zhou wrote:
>
> Some NICs support HW offloading for datapath flows, but masked access to
> the 128-bit ct_label field may prevent a flow being offloaded due to HW
> limitations. OVN's use of ct_label currently includes:
> - ct_label.blocked (1 bit)
> -
On Mon, Mar 28, 2022 at 1:48 AM Han Zhou wrote:
>
> Add an engine node en_northd_internal_version as an input to
> en_lflow_output. When this node is updated, it triggers a recompute for
> en_lflow_output. This node adds SB_Global as its only input, and it is
> updated only when SB_Global's
On Tue, Mar 29, 2022 at 4:18 PM Mark Michelson wrote:
>
> At one point in the test, we expect that the output of `ovn-nbctl
> copp-list` will produce:
>
> arp: meter0
> igmp: meter0
>
> However, the output is created by walking a hashmap, and the ordering of
> the items in the hashmap appears not
Bleep bloop. Greetings Mark Michelson, 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
At one point in the test, we expect that the output of `ovn-nbctl
copp-list` will produce:
arp: meter0
igmp: meter0
However, the output is created by walking a hashmap, and the ordering of
the items in the hashmap appears not to always be the same. On many
builds, I see the test fail, with the
> From: Van Haaren, Harry [mailto:harry.van.haa...@intel.com]
> Sent: Tuesday, 29 March 2022 19.46
>
> > From: Morten Brørup
> > Sent: Tuesday, March 29, 2022 6:14 PM
> >
> > > From: Bruce Richardson [mailto:bruce.richard...@intel.com]
> > > Sent: Tuesday, 29 March 2022 19.03
> > >
> > > On Tue,
> From: Ilya Maximets [mailto:i.maxim...@ovn.org]
> Sent: Tuesday, 29 March 2022 19.45
>
> On 3/29/22 19:13, Morten Brørup wrote:
> >> From: Bruce Richardson [mailto:bruce.richard...@intel.com]
> >> Sent: Tuesday, 29 March 2022 19.03
> >>
> >> On Tue, Mar 29, 2022 at 06:45:19PM +0200, Morten
On Mon, Mar 21, 2022 at 9:46 AM Ilya Maximets wrote:
>
> On 3/18/22 22:34, Toms Atteka wrote:
> > IPv6 extension headers carry optional internet layer information
> > and are placed between the fixed header and the upper-layer
> > protocol header.
> >
> > This change adds a new OpenFlow field
Signed-off-by: Rosemarie O'Riorden
---
.mailmap| 1 +
AUTHORS.rst | 2 +-
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/.mailmap b/.mailmap
index 6cefe3cd4..4773c4a24 100644
--- a/.mailmap
+++ b/.mailmap
@@ -72,6 +72,7 @@ Robert Åkerblom-Andersson
Romain Lenglet
> -Original Message-
> From: Morten Brørup
> Sent: Tuesday, March 29, 2022 6:14 PM
> To: Richardson, Bruce
> Cc: Maxime Coquelin ; Van Haaren, Harry
> ; Pai G, Sunil ; Stokes,
> Ian
> ; Hu, Jiayu ; Ferriter, Cian
> ; Ilya Maximets ; ovs-
> d...@openvswitch.org; d...@dpdk.org; Mcnamara,
On 3/29/22 19:13, Morten Brørup wrote:
>> From: Bruce Richardson [mailto:bruce.richard...@intel.com]
>> Sent: Tuesday, 29 March 2022 19.03
>>
>> On Tue, Mar 29, 2022 at 06:45:19PM +0200, Morten Brørup wrote:
From: Maxime Coquelin [mailto:maxime.coque...@redhat.com]
Sent: Tuesday, 29
Bleep bloop. Greetings Rosemarie O'Riorden, 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:
ERROR: Author Rosemarie O'Riorden needs to sign off.
Lines checked: 39, Warnings: 0,
> From: Bruce Richardson [mailto:bruce.richard...@intel.com]
> Sent: Tuesday, 29 March 2022 19.03
>
> On Tue, Mar 29, 2022 at 06:45:19PM +0200, Morten Brørup wrote:
> > > From: Maxime Coquelin [mailto:maxime.coque...@redhat.com]
> > > Sent: Tuesday, 29 March 2022 18.24
> > >
> > > Hi Morten,
> >
---
.mailmap| 1 +
AUTHORS.rst | 2 +-
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/.mailmap b/.mailmap
index 6cefe3cd4..4773c4a24 100644
--- a/.mailmap
+++ b/.mailmap
@@ -72,6 +72,7 @@ Robert Åkerblom-Andersson
Romain Lenglet
Romain Lenglet
+Rosemarie O'Riorden
On Tue, Mar 29, 2022 at 06:45:19PM +0200, Morten Brørup wrote:
> > From: Maxime Coquelin [mailto:maxime.coque...@redhat.com]
> > Sent: Tuesday, 29 March 2022 18.24
> >
> > Hi Morten,
> >
> > On 3/29/22 16:44, Morten Brørup wrote:
> > >> From: Van Haaren, Harry [mailto:harry.van.haa...@intel.com]
To parse a json string prior to this change, json_lex_input is called
with each character of the string. If the character needs to be copied
to the buffer, it is copied individually. This is an expensive
operation, as often there are multiple characters in a row
that need to be copied, and copying
> From: Maxime Coquelin [mailto:maxime.coque...@redhat.com]
> Sent: Tuesday, 29 March 2022 18.24
>
> Hi Morten,
>
> On 3/29/22 16:44, Morten Brørup wrote:
> >> From: Van Haaren, Harry [mailto:harry.van.haa...@intel.com]
> >> Sent: Tuesday, 29 March 2022 15.02
> >>
> >>> From: Morten Brørup
>
Hi Morten,
On 3/29/22 16:44, Morten Brørup wrote:
From: Van Haaren, Harry [mailto:harry.van.haa...@intel.com]
Sent: Tuesday, 29 March 2022 15.02
From: Morten Brørup
Sent: Tuesday, March 29, 2022 1:51 PM
Having thought more about it, I think that a completely different architectural
> From: Van Haaren, Harry [mailto:harry.van.haa...@intel.com]
> Sent: Tuesday, 29 March 2022 15.02
>
> > From: Morten Brørup
> > Sent: Tuesday, March 29, 2022 1:51 PM
> >
> > Having thought more about it, I think that a completely different
> > architectural approach is required:
> >
> >
Having thought more about it, I think that a completely different architectural
approach is required:
Many of the DPDK Ethernet PMDs implement a variety of RX and TX packet burst
functions, each optimized for different CPU vector instruction sets. The
availability of a DMA engine should be
On 3/29/22 16:24, Mark Michelson wrote:
> I pushed this change to main, branch-22.03, and branch-21.12. Thanks
> Dumitru and Lorenzo.
>
Thanks!
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
I pushed this change to main, branch-22.03, and branch-21.12. Thanks
Dumitru and Lorenzo.
On 3/29/22 05:28, Lorenzo Bianconi wrote:
The 'reason' was computed only when logging at level DBG. However, if a
node takes more than 'engine_compute_log_timeout_msec' to recompute, the
log is generated
From: Dumitru Ceara
This is a backport of d7514abe117. Its original commit message is
below, including the original sign-offs and acks.
-
It's useful to differentiate between ingress and egress pipelines in the
ACL logs. To achieve this we determine the direction by
From: Dumitru Ceara
This is a backport of d7514abe117. Its original commit message is
below, including the original sign-offs and acks.
-
It's useful to differentiate between ingress and egress pipelines in the
ACL logs. To achieve this we determine the direction by
When a nat rule is configured in stateless mode there is a 1:1 mapping
between external_ip and logical_ip. Do not modify dst/src ips in
S_ROUTER_IN_UNSNAT/S_ROUTER_OUT_UNDNAT stages for stateless nat entries
since they will be properly modified in S_ROUTER_IN_DNAT/S_ROUTER_OUT_SNAT
stages.
This
Previously logging about rxq scheduling was done in a code branch with
the selection of the PMD thread core after checking that a numa was
selected.
By splitting out the logging from the PMD thread core selection, it can
simplify the code complexity and make it more extendable for future
This splits up the looping through each PMD thread core on a numa node
with the check to compare cycles or rxqs.
This is done so in future the compare could be reused with any group
of PMD thread cores.
There is no user visibile change in behaviour.
Signed-off-by: Kevin Traynor
---
These are intended to reduce code complexity a bit and make the
code more extensible for additional features like cross-numa
polling [0].
There is not change in behaviour.
Note, 2/2 will need to be rebased when the fix [1] is applied.
GHA:
Hello all,
I have tested GTP Encapsulation & Decapsulation, as well the GTP recirculation
cases.
I would kindly ask you to share your thoughts on the following change:
out_port = odp_port;
if (ovs_native_tunneling_is_on(ctx->xbridge->ofproto)) {
xlate_report(ctx,
Hi Morten,
That's *exactly* how this architecture is designed & implemented.
1. The DMA configuration and initialization is up to the application (OVS).
2. The VHost library is passed the DMA-dev ID, and its new async rx/tx APIs,
and uses the DMA device to accelerate the copy.
Looking
Hello all,
>From "https://mail.openvswitch.org/pipermail/ovs-dev/2019-December/365944.html;
I see. So in this case, I image OVS works like this
0) create gtpu0 (teid=10) and gtpu1 (teid=11) tunnel ports
and GTP-U packets arrives at an port
1) OVS decaps the rx packet, forwards to gtpu0 dev
On 2/25/22 13:29, Marcelo Ricardo Leitner wrote:
> On Thu, Feb 24, 2022 at 03:20:23PM +0100, Eelco Chaudron wrote:
>>
>>
>> On 23 Feb 2022, at 17:23, Marcelo Ricardo Leitner wrote:
>>
>>> On Tue, Feb 22, 2022 at 04:26:10PM +0100, Eelco Chaudron wrote:
This patch checks for none offloadable
Hello
Looking at the following commit:
https://mail.openvswitch.org/pipermail/ovs-dev/2019-December/365389.html
I see that @William thought of this issue and excluded GTP from adding the
additional encapsulation issue in 2019.
I am currently wondering, why this is not in the OVS 2.14 that I am
Modified the dplcs info-get command output to include
the count for different dpcls implementations.
$ovs-appctl dpif-netdev/subtable-lookup-prio-get
Available dpcls implementations:
autovalidator (Use count: 1, Priority: 5)
generic (Use count: 0, Priority: 1)
avx512_gather (Use count: 0,
Hello Ilya,
Thank you for your response and informing other developers.
Using "Clear Actions" instruction to reset the stack of actions, or trying to
somehow reset the packet did not solve the issue.
I think, it would be cumbersome and not very performant, to route the packet
out and then
On 3/29/22 11:39, Dincer Beken wrote:
> Hello again,
>
>
>
> If the packet is recirculated back, and if it is a stripped-off L3 packet
> (GTP decapsulation), OvS does not recognize it as a former GTP packet and
> appends add the pending encapsulation flag on top of it. But the must be
>
On Tue, Mar 29, 2022 at 11:25:38AM +0200, Eelco Chaudron wrote:
>
>
> On 29 Mar 2022, at 10:37, Tao Liu wrote:
>
> > On Mon, Mar 28, 2022 at 04:08:29PM +0200, Eelco Chaudron wrote:
> >> On Mon, Mar 28, 2022 at 3:15 PM Eelco Chaudron wrote:
> >>
> >>>
> >>>
> >>> On 25 Mar 2022, at 18:05, Tao
OVS commit 1cc618c32524 ("ovsdb-idl: Fix atomicity of writes that
don't change a column's value.") [0] explains why writes that don't
change a column's value cannot be optimized out early if the column is
read/write.
In northd, most tables have change tracking enabled, making all their
columns
Hello again,
If the packet is recirculated back, and if it is a stripped-off L3 packet (GTP
decapsulation), OvS does not recognize it as a former GTP packet and appends
add the pending encapsulation flag on top of it. But the must be encapsulated
with GTP first, and the ETH header will be
On 3/25/22 16:08, Dumitru Ceara wrote:
> OVS commit 1cc618c32524 ("ovsdb-idl: Fix atomicity of writes that
> don't change a column's value.") [0] explains why writes that don't
> change a column's value cannot be optimized out early if the column is
> read/write.
>
> In northd, most tables have
> The 'reason' was computed only when logging at level DBG. However, if a
> node takes more than 'engine_compute_log_timeout_msec' to recompute, the
> log is generated at level INFO, resulting in:
>
> inc_proc_eng|INFO|node: northd, recompute ((null))
>
> We now unconditionally compute
On 29 Mar 2022, at 10:37, Tao Liu wrote:
> On Mon, Mar 28, 2022 at 04:08:29PM +0200, Eelco Chaudron wrote:
>> On Mon, Mar 28, 2022 at 3:15 PM Eelco Chaudron wrote:
>>
>>>
>>>
>>> On 25 Mar 2022, at 18:05, Tao Liu wrote:
>>>
On Fri, Mar 25, 2022 at 12:08:20PM +0100, Eelco Chaudron wrote:
The 'reason' was computed only when logging at level DBG. However, if a
node takes more than 'engine_compute_log_timeout_msec' to recompute, the
log is generated at level INFO, resulting in:
inc_proc_eng|INFO|node: northd, recompute ((null))
We now unconditionally compute 'reason'. In theory
On Mon, Mar 28, 2022 at 04:08:29PM +0200, Eelco Chaudron wrote:
> On Mon, Mar 28, 2022 at 3:15 PM Eelco Chaudron wrote:
>
> >
> >
> > On 25 Mar 2022, at 18:05, Tao Liu wrote:
> >
> > > On Fri, Mar 25, 2022 at 12:08:20PM +0100, Eelco Chaudron wrote:
> > >>
> > >>
> > >> On 22 Mar 2022, at 13:04,
67 matches
Mail list logo
