On 3/7/24 21:59, Adrian Moreno wrote:
>
>
> On 3/7/24 17:54, Ilya Maximets wrote:
>> On 3/7/24 16:18, Adrian Moreno wrote:
>>> ** Background **
>>> Currently, OVS supports several packet sampling mechanisms (sFlow,
>>> per-bridge IPFIX, per-flow IPFIX). These end up being translated into a
>>>
On 3/7/24 18:08, Eric Garver wrote:
> The next commit will convert a dp feature from bool to atomic_bool. As
> such we have to add support to the macros and functions. We must pass by
> reference instead of pass by value because all the atomic operations
> require a reference.
>
> Signed-off-by:
On 3/7/24 18:08, Eric Garver wrote:
> Kernel support has been added for this action. As such, we need to probe
> the datapath for support.
>
> Signed-off-by: Eric Garver
> ---
> include/linux/openvswitch.h | 2 +-
> lib/dpif.c | 6 ---
> lib/dpif.h | 1 -
>
On Thu, Mar 07, 2024 at 08:35:30PM +0100, Ilya Maximets wrote:
> On 3/7/24 18:08, Eric Garver wrote:
> > Kernel support has been added for this action. As such, we need to probe
> > the datapath for support.
> >
> > Signed-off-by: Eric Garver
> > ---
> > include/linux/openvswitch.h | 2 +-
> >
On 3/7/24 17:54, Ilya Maximets wrote:
On 3/7/24 16:18, Adrian Moreno wrote:
** Background **
Currently, OVS supports several packet sampling mechanisms (sFlow,
per-bridge IPFIX, per-flow IPFIX). These end up being translated into a
userspace action that needs to be handled by ovs-vswitchd's
It's hard to debug situations where driver rejects packets for some
reason. Dumping out the mbuf should help with that.
Sample output looks like this:
|netdev_dpdk(pmd-c03/id:8)|DBG|ovs-p1: First invalid packet:
dump mbuf at 0x1180bce140, iova=0x2cb7ce400, buf_len=2176
pkt_len=64,
On 3/7/24 20:09, Ilya Maximets wrote:
> On 3/7/24 18:08, Eric Garver wrote:
>> v10:
>> - fix a sparse error in show_dp_feature_atomic_bool()
>> v9:
>> - new patch make get_datapath_cap() access support by pointer
>> - fix a clang warning in copy_support()
>> v8:
>> - new patch to support
On 3/7/24 18:08, Eric Garver wrote:
> v10:
> - fix a sparse error in show_dp_feature_atomic_bool()
> v9:
> - new patch make get_datapath_cap() access support by pointer
> - fix a clang warning in copy_support()
> v8:
> - new patch to support atomic_bool dpif field types
> - re-add
On 3/7/24 20:18, Ilya Maximets wrote:
> On 3/7/24 18:08, Eric Garver wrote:
>> The next commit will convert a dp feature from bool to atomic_bool. As
>> such we have to add support to the macros and functions. We must pass by
>> reference instead of pass by value because all the atomic operations
Bleep bloop. Greetings Yuhao zhou, 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: The subject summary should end with a dot.
Subject: ofproto: Fix mod flow table name
From: "zhouyuhao.philozhou"
When mod a flow table's name with table's prefix name, there
will be no change. Because when check whether the new and old
name are the same, only compare the length of the new name.
Case:
table 10: "good"
There will be no change if mod the table's name with "g"
On Thu, Mar 7, 2024, 5:50 AM Martin Kalcok
wrote:
> On Thu, Mar 7, 2024 at 1:26 AM Numan Siddique wrote:
>
> >
> >
> > On Wed, Mar 6, 2024 at 7:26 AM Martin Kalcok <
> martin.kal...@canonical.com>
> > wrote:
> >
> >> Hi Ales,
> >> Thank you for review and helpful comments. I'll update commit
This is prep for adding a different OVS_ACTION_ATTR_ enum value. This
action, OVS_ACTION_ATTR_DEC_TTL, is not actually implemented. However,
to make -Werror happy we must add a case to all existing switches.
Signed-off-by: Eric Garver
---
include/linux/openvswitch.h | 1 +
lib/dpif-netdev.c
The next commit will convert a dp feature from bool to atomic_bool. As
such we have to add support to the macros and functions. We must pass by
reference instead of pass by value because all the atomic operations
require a reference.
Signed-off-by: Eric Garver
---
ofproto/ofproto-dpif.c | 52
Kernel support has been added for this action. As such, we need to probe
the datapath for support.
Signed-off-by: Eric Garver
---
include/linux/openvswitch.h | 2 +-
lib/dpif.c | 6 ---
lib/dpif.h | 1 -
ofproto/ofproto-dpif.c | 89
This avoids copying the support struct onto the stack.
Signed-off-by: Eric Garver
---
ofproto/ofproto-dpif.c | 59 +-
1 file changed, 29 insertions(+), 30 deletions(-)
diff --git a/ofproto/ofproto-dpif.c b/ofproto/ofproto-dpif.c
index
Exercise the drop action in the datapath. This specific tests triggers
an xlate_error.
For the kernel datapath skb drop reasons can then be seen while this
test runs.
# perf trace -e skb:kfree_skb --filter="reason >= 0x3"
0.000 ping/1275884 skb:kfree_skb(skbaddr: 0x8acd76546000, \
v9:
- new patch make get_datapath_cap() access support by pointer
- fix a clang warning in copy_support()
v8:
- new patch to support atomic_bool dpif field types
- re-add re-probe of support
- use atomic_bool type for explicit_drop_action
v7:
- remove re-probe of support as Ilya is
Introduce the nexthop identifier in the ct_label.label field for
ecmp-symmetric replies connections. This field will be used by
ovn-controller to track ct entries and to flush them if requested by the
CMS (e.g. removing the related static routes).
Signed-off-by: Lorenzo Bianconi
---
Reported-at: https://issues.redhat.com/browse/FDP-56
Lorenzo Bianconi (3):
northd: Introduce ECMP_Nexthop table in SB db.
northd: Add nexhop id in ct_label.label.
ofctrl: Introduce ecmp_nexthop_monitor.
controller/ofctrl.c | 102 ++
controller/ofctrl.h | 2 +
Introduce ecmp_nexthop_monitor in ovn-controller in order to track and
flush ecmp-symmetric reply ct entires when requested by the CMS (e.g
removing the related static routes).
Signed-off-by: Lorenzo Bianconi
---
controller/ofctrl.c | 102 ++
controller/ofctrl.h |
Introduce ECMP_Nexthop table in the SB db in order to track active
ecmp-symmetric-reply connections and flush stale ones.
Signed-off-by: Lorenzo Bianconi
---
northd/en-northd.c | 4 ++
northd/inc-proc-northd.c | 8 +++-
northd/northd.c | 98
On 3/7/24 14:22, Kevin Traynor wrote:
> On 05/03/2024 17:31, Ilya Maximets wrote:
>> On 3/5/24 18:13, Kevin Traynor wrote:
>>> On 05/03/2024 15:22, Ilya Maximets wrote:
It's hard to debug situations where driver rejects packets for some
reason. Dumping out the mbuf should help with
On 05/03/2024 17:31, Ilya Maximets wrote:
> On 3/5/24 18:13, Kevin Traynor wrote:
>> On 05/03/2024 15:22, Ilya Maximets wrote:
>>> It's hard to debug situations where driver rejects packets for some
>>> reason. Dumping out the mbuf should help with debugging.
>>>
>>> Sample output looks like
On Thu, Mar 7, 2024 at 1:26 AM Numan Siddique wrote:
>
>
> On Wed, Mar 6, 2024 at 7:26 AM Martin Kalcok
> wrote:
>
>> Hi Ales,
>> Thank you for review and helpful comments. I'll update commit subjects
>> for this series in v2.
>>
>> On Wed, Mar 6, 2024 at 7:45 AM Ales Musil wrote:
>>
>>>
>>>
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.
checkpatch:
WARNING: The subject summary should end with a dot.
Subject: ofpbuf: Prevent undefined behavior
The new_buffer data pointer is NULL when the size of the cloned
buffer is 0. This is fine as there is no need to allocate space.
However, the cloned buffer header/msg might be the same pointer
as data. This causes undefined behavior by adding 0 to NULL pointer.
Check if the data buffer is not NULL
** Background **
Currently, OVS supports several packet sampling mechanisms (sFlow,
per-bridge IPFIX, per-flow IPFIX). These end up being translated into a
userspace action that needs to be handled by ovs-vswitchd's handler
threads only to be forwarded to some third party application that
will
actions.
Some userspace actions, such as the ones derived from OFP_CONTROLLER
action or slow path, have to be handled by ovs-vswitchd, so they are
unicasted through the netlink socket that corresponds.
However, some other userspace actions require little processing by
ovs-vswitchd and their end
If there are no listeneres in the multicast group, there is no need for
building the upcall packet. Exit early in that case.
Signed-off-by: Adrian Moreno
---
net/openvswitch/datapath.c | 4
1 file changed, 4 insertions(+)
diff --git a/net/openvswitch/datapath.c
The existing dp_upcall tracepoint was intented to provide visibility on
flow-misses (what we typically refer as upcalls). It's used to measure
things like upcall latency.
However, if a monitoring userspace action (such as IPFIX) is
multicasted, using the same tracepoint will only add confusion as
EDNS0ClientSubnet is quite a recent addition to scapy and not all
distros might already have a new enough version of scapy available.
Fixes: b7fe2c8b1b08 ("pinctrl: dns: Ignore additional records.")
Signed-off-by: Dumitru Ceara
---
tests/ovn-macros.at | 6 ++
tests/ovn.at| 2 +-
2
If we mix multicasted and unicasted statistics, there could be a serious
discrepancy between the stats reported by the kernel and the ones read
by userspace, leading to increased confusion.
Signed-off-by: Adrian Moreno
---
include/uapi/linux/openvswitch.h | 2 ++
net/openvswitch/datapath.c
On 3/7/24 16:18, Adrian Moreno wrote:
> ** Background **
> Currently, OVS supports several packet sampling mechanisms (sFlow,
> per-bridge IPFIX, per-flow IPFIX). These end up being translated into a
> userspace action that needs to be handled by ovs-vswitchd's handler
> threads only to be
This avoids copying the support struct onto the stack.
Signed-off-by: Eric Garver
---
ofproto/ofproto-dpif.c | 59 +-
1 file changed, 29 insertions(+), 30 deletions(-)
diff --git a/ofproto/ofproto-dpif.c b/ofproto/ofproto-dpif.c
index
Kernel support has been added for this action. As such, we need to probe
the datapath for support.
Signed-off-by: Eric Garver
---
include/linux/openvswitch.h | 2 +-
lib/dpif.c | 6 ---
lib/dpif.h | 1 -
ofproto/ofproto-dpif.c | 89
Exercise the drop action in the datapath. This specific tests triggers
an xlate_error.
For the kernel datapath skb drop reasons can then be seen while this
test runs.
# perf trace -e skb:kfree_skb --filter="reason >= 0x3"
0.000 ping/1275884 skb:kfree_skb(skbaddr: 0x8acd76546000, \
This is prep for adding a different OVS_ACTION_ATTR_ enum value. This
action, OVS_ACTION_ATTR_DEC_TTL, is not actually implemented. However,
to make -Werror happy we must add a case to all existing switches.
Signed-off-by: Eric Garver
---
include/linux/openvswitch.h | 1 +
lib/dpif-netdev.c
v10:
- fix a sparse error in show_dp_feature_atomic_bool()
v9:
- new patch make get_datapath_cap() access support by pointer
- fix a clang warning in copy_support()
v8:
- new patch to support atomic_bool dpif field types
- re-add re-probe of support
- use atomic_bool type for
The next commit will convert a dp feature from bool to atomic_bool. As
such we have to add support to the macros and functions. We must pass by
reference instead of pass by value because all the atomic operations
require a reference.
Signed-off-by: Eric Garver
---
ofproto/ofproto-dpif.c | 52
From: "zhouyuhao.philozhou"
Because when check whether the new and old name are the same, only
compare the length of the new name.
Case:
table 10: "good"
There will be no change if mod the table's name with "g" "go" "goo".
Signed-off-by: zhouyuhao.philozhou
---
ofproto/ofproto.c | 4
Open vSwitch supports the ability to invoke a controller action by way
of a sample action with a specified meter. In the normal case, this
sample action is transparently generated during xlate processing. However,
when executing via a continuation, the logic to generate the sample
action when
Bleep bloop. Greetings Yuhao zhou, 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: The subject, ': ', is over 70 characters, i.e., 132.
Subject: ofproto: Fix mod flow
43 matches
Mail list logo
