The new tables will be used in a later patch as follows:
table=37, OFTABLE_OUTPUT_INIT: becomes an initial entry point into the
egress pipeline that serves a semantic goal. (Not doing any actual
processing at the moment.)
table=38, OFTABLE_OUTPUT_LARGE_PKT_DETECT: detect "too-big" IP packets
and
This will be used in a later patch to calculate the effective interface
MTU after considering tunneling overhead.
NOTE: ideally, OVN would support Logical_Port MTU, in which case we
wouldn't have to track OVSDB for interfaces.
Signed-off-by: Ihar Hrachyshka
---
controller/binding.c|
When a multichassis port belongs to a switch with a localnet port,
packets originating or directed to the multichassis port are NOT sent
thorugh the localnet port. Instead, tunneling is enforced in-cluster to
guarantee delivery of all packets to all chassis of the port.
This behavior has an
This will allow all chassis hosting a port to extract interface MTU from
if-status-mgr. This will be used in a later patch to calculate the
effective path MTU for each port.
In addition, it's the right thing to do to claim and mark an interface
on all chassis as ovn-installed, even if the chassis
This series fixes a non-optimal behavior with some multichassis ports.
Specifically,
- when a multichassis port belongs to a switch that also has a localnet
port,
- because ingress and egress traffic for the port is funnelled through
tunnels to guarantee delivery of packets to all chassis
This will be used in a later patch to calculate tunneling overhead for
effective path MTU.
Acked-by: Dumitru Ceara
Signed-off-by: Ihar Hrachyshka
---
controller/local_data.c | 2 ++
controller/local_data.h | 1 +
2 files changed, 3 insertions(+)
diff --git a/controller/local_data.c
On 5/16/23 17:20, mit...@outlook.com wrote:
> From: Lin Huang
>
> OvS has supported packet-per-second policer which can be set at ingress
> and egress side in kernel datapath. But the userspace datapath doesn't
> support for ingress and egress packet-per-second policing now.
>
> So, this patch
The new tables will be used in a later patch as follows:
table=37, OFTABLE_OUTPUT_INIT: becomes an initial entry point into the
egress pipeline that serves a semantic goal. (Not doing any actual
processing at the moment.)
table=38, OFTABLE_OUTPUT_LARGE_PKT_DETECT: detect "too-big" IP packets
and
When a multichassis port belongs to a switch with a localnet port,
packets originating or directed to the multichassis port are NOT sent
thorugh the localnet port. Instead, tunneling is enforced in-cluster to
guarantee delivery of all packets to all chassis of the port.
This behavior has an
This will be used in a later patch to calculate the effective interface
MTU after considering tunneling overhead.
NOTE: ideally, OVN would support Logical_Port MTU, in which case we
wouldn't have to track OVSDB for interfaces.
Signed-off-by: Ihar Hrachyshka
---
controller/binding.c|
This series fixes a non-optimal behavior with some multichassis ports.
Specifically,
- when a multichassis port belongs to a switch that also has a localnet
port,
- because ingress and egress traffic for the port is funnelled through
tunnels to guarantee delivery of packets to all chassis
This will allow all chassis hosting a port to extract interface MTU from
if-status-mgr. This will be used in a later patch to calculate the
effective path MTU for each port.
In addition, it's the right thing to do to claim and mark an interface
on all chassis as ovn-installed, even if the chassis
This will be used in a later patch to calculate tunneling overhead for
effective path MTU.
Acked-by: Dumitru Ceara
Signed-off-by: Ihar Hrachyshka
---
controller/local_data.c | 2 ++
controller/local_data.h | 1 +
2 files changed, 3 insertions(+)
diff --git a/controller/local_data.c
On 5/23/23 20:51, Sayali Naval (sanaval) via dev wrote:
> Does anyone have any insights on the below?
>
> From: Sayali Naval (sanaval)
> Sent: Friday, May 12, 2023 11:10 AM
> To: d...@openvswitch.org
> Subject: [ovs-dev] ovs-vsctl Bridge IPFIX
On 5/23/23 16:16, Robin Jarry wrote:
> Aaron Conole, May 23, 2023 at 15:32:
>> I think one issue I have with this is that the name is a bit
>> misleading. Control plane, from OVS perspective, would be like OpenFlow
>> communications. This is more like a traffic steering mechanism.
>>
>> Maybe it
On 5/18/23 09:37, Peng He wrote:
> Hi, Paolo,
>
> IIRC, you have a revision version on these patches?
> I guess it should be closer to the upstream than mine?
I suppose, this one was the last revision of the patch:
On 5/23/23 00:16, Paolo Valerio wrote:
> Ilya Maximets writes:
>
>> On 5/15/23 17:22, Paolo Valerio wrote:
>>> If a packet originating from the controller recirculates after going
>>> through a patch port, it gets dropped with the following message:
>>>
>>>
Does anyone have any insights on the below?
From: Sayali Naval (sanaval)
Sent: Friday, May 12, 2023 11:10 AM
To: d...@openvswitch.org
Subject: [ovs-dev] ovs-vsctl Bridge IPFIX enable_input_sampling,
enable_ouput_sampling and enable_tunnel_sampling returning
On Wed, May 03, 2023 at 02:30:32AM +0800, James Raphael Tiovalen wrote:
> This commit adds various null pointer checks to some files in the `lib`
> and the `ovsdb` directories to fix several Coverity defects. These
> changes are grouped together as they perform similar checks, returning
> early or
On Mon, May 22, 2023 at 8:00 AM Dumitru Ceara wrote:
>
> On 5/17/23 21:34, Ihar Hrachyshka wrote:
> > On Tue, May 16, 2023 at 9:40 AM Dumitru Ceara wrote:
> >>
> >> On 5/3/23 22:13, Ihar Hrachyshka wrote:
> >>> This will be used in a later patch to calculate the effective interface
> >>> MTU
On Wed, May 03, 2023 at 02:30:30AM +0800, James Raphael Tiovalen wrote:
> This commit adds non-null pointer assertions in some code that performs
> some decisions based on old and new input ovsdb_rows.
>
> Signed-off-by: James Raphael Tiovalen
Reviewed-by: Simon Horman
The new tables will be used in a later patch as follows:
table=37, OFTABLE_OUTPUT_INIT: becomes an initial entry point into the
egress pipeline that serves a semantic goal. (Not doing any actual
processing at the moment.)
table=38, OFTABLE_OUTPUT_LARGE_PKT_DETECT: detect "too-big" IP packets
and
This will be used in a later patch to calculate the effective interface
MTU after considering tunneling overhead.
NOTE: ideally, OVN would support Logical_Port MTU, in which case we
wouldn't have to track OVSDB for interfaces.
Signed-off-by: Ihar Hrachyshka
---
controller/binding.c|
When a multichassis port belongs to a switch with a localnet port,
packets originating or directed to the multichassis port are NOT sent
thorugh the localnet port. Instead, tunneling is enforced in-cluster to
guarantee delivery of all packets to all chassis of the port.
This behavior has an
This will allow all chassis hosting a port to extract interface MTU from
if-status-mgr. This will be used in a later patch to calculate the
effective path MTU for each port.
In addition, it's the right thing to do to claim and mark an interface
on all chassis as ovn-installed, even if the chassis
This series fixes a non-optimal behavior with some multichassis ports.
Specifically,
- when a multichassis port belongs to a switch that also has a localnet
port,
- because ingress and egress traffic for the port is funnelled through
tunnels to guarantee delivery of packets to all chassis
This will be used in a later patch to calculate tunneling overhead for
effective path MTU.
Acked-by: Dumitru Ceara
Signed-off-by: Ihar Hrachyshka
---
controller/local_data.c | 2 ++
controller/local_data.h | 1 +
2 files changed, 3 insertions(+)
diff --git a/controller/local_data.c
On Wed, May 03, 2023 at 02:30:29AM +0800, James Raphael Tiovalen wrote:
> This commit adds a few null pointer assertions and checks to some return
> values of `ovsdb_table_schema_get_column`. If a null pointer is
> encountered in these blocks, either the assertion will fail or the
> control flow
On Wed, May 03, 2023 at 02:30:28AM +0800, James Raphael Tiovalen wrote:
> This commit adds assertions in the functions `shash_count`,
> `simap_count`, and `smap_count` to ensure that the corresponding input
> struct pointer is not NULL.
>
> This ensures that if the return values of `shash_sort`,
On Wed, May 03, 2023 at 02:30:27AM +0800, James Raphael Tiovalen wrote:
> This commit adds zero-initializations by changing `SFL_ALLOC` from
> `malloc` to `xzalloc`, adding a `memset` call to `sflAlloc`,
> initializing a `pollfd` struct variable with zeroes, and changing some
> calls to `xmalloc`
On Wed, May 03, 2023 at 02:30:27AM +0800, James Raphael Tiovalen wrote:
> This commit adds zero-initializations by changing `SFL_ALLOC` from
> `malloc` to `xzalloc`, adding a `memset` call to `sflAlloc`,
> initializing a `pollfd` struct variable with zeroes, and changing some
> calls to `xmalloc`
On Mon, May 15, 2023 at 11:23:56AM +0300, Roi Dayan via dev wrote:
> From: Gavin Li
>
> Add TC offload support for vxlan encap with gbp option
>
> Signed-off-by: Gavin Li
> Reviewed-by: Gavi Teitz
> Reviewed-by: Roi Dayan
Reviewed-by: Simon Horman
On Mon, May 15, 2023 at 11:23:54AM +0300, Roi Dayan via dev wrote:
> From: Gavin Li
>
> Add TC offload support for filtering vxlan tunnels with gbp option
>
> Signed-off-by: Gavin Li
> Reviewed-by: Gavi Teitz
> Reviewed-by: Roi Dayan
Reviewed-by: Simon Horman
On Mon, May 15, 2023 at 11:23:53AM +0300, Roi Dayan via dev wrote:
> From: Gavin Li
>
> Linux kernel netlink module added NLA_F_NESTED flag checking for nested
> netlink messages in 5.2. A nested message without the flag set will be
> treated as malformated one. The check is optional and is
Aaron Conole, May 23, 2023 at 15:32:
> I think one issue I have with this is that the name is a bit
> misleading. Control plane, from OVS perspective, would be like OpenFlow
> communications. This is more like a traffic steering mechanism.
>
> Maybe it would help to call it something like
On 23/05/2023 14:32, Aaron Conole wrote:
Robin Jarry writes:
Some control protocols are used to maintain link status between
forwarding engines (e.g. LACP). When the system is not sized properly,
the PMD threads may not be able to process all incoming traffic from the
configured Rx queues.
Robin Jarry writes:
> Some control protocols are used to maintain link status between
> forwarding engines (e.g. LACP). When the system is not sized properly,
> the PMD threads may not be able to process all incoming traffic from the
> configured Rx queues. When a signaling packet of such
The only way that stats->{n_packets,n_bytes} would decrease is due to an
overflow, or if there are bugs in how statistics are handled. In the
past, there were multiple issues that caused a jump backward. A
workaround was in place to set the statistics to 0 in that case. When
this happened while
On 5/22/23 21:25, Mark Michelson wrote:
> Hi Ihar,
>
Hi, Ihar, Mark,
> Acked-by: Mark Michelson
>
> I'm going to wait on merging this since I know others had looked at
> v1-v3, so I'm going to give them an opportunity to have another look if
> they want.
>
The series needs a non-trivial
On 5/18/23 12:56, Ihar Hrachyshka wrote:
> When a multichassis port belongs to a switch with a localnet port,
> packets originating or directed to the multichassis port are NOT sent
> thorugh the localnet port. Instead, tunneling is enforced in-cluster to
> guarantee delivery of all packets to all
On 5/18/23 12:56, Ihar Hrachyshka wrote:
> The new tables will be used in a later patch as follows:
>
> table=37, OFTABLE_OUTPUT_INIT: becomes an initial entry point into the
> egress pipeline that serves a semantic goal. (Not doing any actual
> processing at the moment.)
>
> table=38,
On 5/18/23 12:56, Ihar Hrachyshka wrote:
> This will be used in a later patch to calculate the effective interface
> MTU after considering tunneling overhead.
>
> NOTE: ideally, OVN would support Logical_Port MTU, in which case we
> wouldn't have to track OVSDB for interfaces.
>
> Signed-off-by:
The tc module combines the use of the `tc_transact` helper
function for communication with the in-kernel tc infrastructure
with assertions on the reply data by `ofpbuf_at_assert` on the
received data prior to further processing.
`tc_transact` in turn calls `nl_transact`, which via
The incremental processing is broken for addresses
that have mask which could "erase" portion of the address
itself e.g. 10.16.0.47/4, after applying the mask with token
parser the address becomes 0.0.0.0/4, which is fine for
logical flows. However, for the deletion/addition to database
we need
On 5/22/23 17:39, Ihar Hrachyshka wrote:
> On Mon, May 22, 2023 at 9:55 AM Dumitru Ceara wrote:
>>
>> On 5/22/23 15:42, Ihar Hrachyshka wrote:
>>> On Mon, May 22, 2023 at 7:55 AM Dumitru Ceara wrote:
On 5/17/23 18:46, Ihar Hrachyshka wrote:
> Thank you Dumitru! See below.
>
45 matches
Mail list logo
