With some datapaths, read TC, it takes a bit longer to update the
OpenFlow statistics. Rather than adding an additional delay, try
to read the counters multiple times until we get the desired value.
Signed-off-by: Eelco Chaudron
Acked-by: Roi Dayan
---
tests/system-traffic.at | 18
I commented the three remaining failures when running tc with the
system-traffic tests. In addition I ran the following test to verify
we did not see any failures with recheck enabled:
for i in {1..50}; do make check-offloads || \
make check-offloads TESTSUITEFLAGS="--recheck" || break; \
Make the order of the Netlink attributes for odp_flow_key_from_flow__()
the same as the kernel will return them.
This will make sure the attributes displayed in the dpctl/dump-flows
output appear in the same order for all datapath.
Signed-off-by: Eelco Chaudron
Acked-by: Roi Dayan
---
If a tc flow was installed but has not yet been used, report it as such.
In addition, add a delay to the "IGMP - flood under normal action" test
case to make it work with many repetitions. This delay is also present
in other ICMP/IGMP tests.
f98e418fbdb6 ("tc: Add tc flower functions")
tc does not include ethernet header length in packet byte count.
This fix will allow the packets that go trough tc to be 14 bytes less.
This difference in the TC implementation is already described in
tc-offload.rst.
Signed-off-by: Eelco Chaudron
Acked-by: Roi Dayan
---
tc does not support conntrack ALGs. Even worse, with tc enabled, they
should not be used/configured at all. This is because even though TC
will ignore the rules with ALG configured, i.e., they will flow through
the kernel module, return traffic might flow through a tc conntrack
rule, and it will
The tc conntrack implementation does not support the timeout option.
The current implementation is silently ignoring the timeout option
by adding a general conntrack entry.
This patch will skip the related test by overriding the support macro.
Signed-off-by: Eelco Chaudron
Acked-by: Roi Dayan
Flush datapath flows as TC flows take some more time to be flushed out.
The flush speeds this up.
Signed-off-by: Eelco Chaudron
Acked-by: Roi Dayan
---
tests/system-traffic.at |7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/tests/system-traffic.at
tc was not setting the OVS_CT_ATTR_FORCE_COMMIT flag when a forced
commit was requested. This patch will fix this.
Fixes: 576126a931cd ("netdev-offload-tc: Add conntrack support")
Signed-off-by: Eelco Chaudron
Acked-by: Roi Dayan
---
lib/netdev-offload-tc.c | 13 +++--
1 file
TC flower does not allow the push of the implicit null labels (RFC3032).
Avoid the use of such labels in the MPLS test cases.
Signed-off-by: Eelco Chaudron
Acked-by: Roi Dayan
---
tests/system-traffic.at | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git
Include and run the system-traffic.at tests as part of the system offload
testsuite. Exclude all the tests that will not run without any special
modifications.
Signed-off-by: Eelco Chaudron
Acked-by: Roi Dayan
---
tests/automake.mk |3 ++
tests/ofproto-macros.at
This series makes it possible to include system-traffic.at tests into
"make check-offloads" tests.
The last patch of the series explains which tests are still not passing
and might need some more work.
I'll try to work on the remaining failing test cases or find someone
who can work on them.
Thank you Jakub, for your reminder. i will take care of the comment in the code
as well in the next submission
eddy
发件人: Jakub Kicinski
发送时间: 2023年2月2日 5:36
收件人: 陶 缘
抄送: Jiri Pirko ; net...@vger.kernel.org
; Pravin B Shelar ; David S. Miller
; Eric Dumazet ;
On Wed, 1 Feb 2023 21:35:15 -0800 Jakub Kicinski wrote:
> On Thu, 2 Feb 2023 05:09:51 + 陶 缘 wrote:
> > I guest you are pointing to the field "From: taoyuan_e...@hotmail.com" in
> > the patch header linked from "Headers show" section in the patch page
> >
> >
> >
On Thu, 2 Feb 2023 05:09:51 + 陶 缘 wrote:
> I guest you are pointing to the field "From: taoyuan_e...@hotmail.com" in the
> patch header linked from "Headers show" section in the patch page
>
>
>
Hi, Jiri:
I guest you are pointing to the field "From: taoyuan_e...@hotmail.com" in the
patch header linked from "Headers show" section in the patch page
https://patchwork.kernel.org/project/netdevbpf/patch/os3p286mb22954422e3dd09ff5fd6b091f5...@os3p286mb2295.jpnp286.prod.outlook.com/
I will
In ovn_igmp_group_get_ports(), it accesses a union member that should
exist only if the port is a LSP: port->peer->od->mcast_info.rtr.relay.
But in theory it is possible that the "port" is in fact a LRP, because
it is a result of ovn_port_find() with the port name coming from a SB DB
entry. So it
On Wed, Feb 1, 2023 at 1:38 AM Dumitru Ceara wrote:
>
> On 2/1/23 07:25, Han Zhou wrote:
> > Signed-off-by: Han Zhou
> > ---
>
> Hi Han,
>
> Thanks for the fix!
>
> > ovn-nb.xml | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/ovn-nb.xml b/ovn-nb.xml
> > index
Syzkaller reports a memory leak of new_flow in ovs_flow_cmd_new() as it is
not freed when an allocation of a key fails.
BUG: memory leak
unreferenced object 0x888116668000 (size 632):
comm "syz-executor231", pid 1090, jiffies 4294844701 (age 18.871s)
hex dump (first 32 bytes):
00 00
On Wed, Feb 01, 2023 at 07:28:09PM +0300, Fedor Pchelkin wrote:
> On 2/1/23 6:45 PM, Simon Horman wrote:
> > I see this would work by virtue of kfree(key) doing nothing
> > of key is NULL, the error case in question. And that otherwise key is
> > non-NULL if this path is hit.
> >
> > However, the
rte_vect.h pulls some AVX512 instrinsics headers added in GCC 12 [1]
trigger a lot of warnings:
libtool: compile: env "REAL_CC=ccache gcc" "CHECK=sparse -Wsparse-error
-I ../include/sparse -I ../include -m64 -I /usr/local/include
" cgcc -target=x86_64 -target=host_os_specs
On 2/1/23 6:45 PM, Simon Horman wrote:
I see this would work by virtue of kfree(key) doing nothing
of key is NULL, the error case in question. And that otherwise key is
non-NULL if this path is hit.
However, the idiomatic approach to error handling is for the error path
to unwind resource
While conntrack entries were flushed between the sub-tests, flows from
previous tests might still be present, causing conntrack entries to be
re-created.
Fixes: a0f82efdd9df ("northd: bypass connection tracking for stateless flows
when there are LB flows present")
Signed-off-by: Xavier Simonart
On Tue, Jan 31, 2023 at 10:19:39PM +0300, Fedor Pchelkin wrote:
> Syzkaller reports a memory leak of new_flow in ovs_flow_cmd_new() as it is
> not freed when an allocation of a key fails.
>
> BUG: memory leak
> unreferenced object 0x888116668000 (size 632):
> comm "syz-executor231", pid
Hi, Jiri:
I looked into v2 content, both "From" field and "Signed-off-by" field are
'Eddy Tao' now, in the CC list, 'Eddy Tao' was also
placed automatically/correctly
>>Hmm, I guess that the name should be rather "Dddy Taoyuan" ? Please fix, ==>
>>this is point 1 I guess and it has
Commit 08e9e5337383 fixed proper initialization of the dns-resolve
module, and made DNS resolution asynchronous.
A side effect of that change revealed a long standing logic bug
which broke ovsdb-server listener configuration using DNS names.
Previously this worked because the DNS resolution
Syzkaller reports a memory leak of new_flow in ovs_flow_cmd_new() as it is
not freed when an allocation of a key fails.
BUG: memory leak
unreferenced object 0x888116668000 (size 632):
comm "syz-executor231", pid 1090, jiffies 4294844701 (age 18.871s)
hex dump (first 32 bytes):
00 00
Wed, Feb 01, 2023 at 02:24:39PM CET, taoyuan_e...@hotmail.com wrote:
>From: Eddy Tao
>
>'struct cpumask cpu_used_mask' is embedded in struct sw_flow.
>However, its size is hardcoded to CONFIG_NR_CPUS bits, which can be
>8192 by default, it costs memory and slows down ovs_flow_alloc.
>This fix
From: Eddy Tao
'struct cpumask cpu_used_mask' is embedded in struct sw_flow.
However, its size is hardcoded to CONFIG_NR_CPUS bits, which can be
8192 by default, it costs memory and slows down ovs_flow_alloc.
This fix uses actual CPU number instead
Signed-off-by: Eddy Tao
---
Tue, Jan 31, 2023 at 02:58:22PM CET, taoyuan_e...@hotmail.com wrote:
>From: eddytaoyuan
>
>struct cpumask cpu_used_mask is directly embedded in struct sw_flow
>however, its size is hardcoded to CONFIG_NR_CPUS bits, which
>can be as large as 8192 by default, it cost memory and slows down
When a flow gets modified, i.e. the actions are changes, the tc layer will
remove, and re-add the flow. This is causing all the counters to be reset.
This patch will remember the previous tc counters and adjust any requests
for statistics. This is done in a similar way as the rte_flow
On 1 Feb 2023, at 12:02, Ilya Maximets wrote:
> On 1/31/23 15:38, Eelco Chaudron wrote:
>>
>>
>> On 31 Jan 2023, at 14:13, Ilya Maximets wrote:
>>
>>> On 1/13/23 13:57, Eelco Chaudron wrote:
When a flow gets modified, i.e. the actions are changes, the tc layer will
remove, and re-add
On 1/31/23 15:38, Eelco Chaudron wrote:
>
>
> On 31 Jan 2023, at 14:13, Ilya Maximets wrote:
>
>> On 1/13/23 13:57, Eelco Chaudron wrote:
>>> When a flow gets modified, i.e. the actions are changes, the tc layer will
>>> remove, and re-add the flow. This is causing all the counters to be reset.
On 2/1/23 07:33, taoyuan_e...@hotmail.com wrote:
> From: eddytaoyuan
>
> 'struct cpumask cpu_used_mask' is embedded in struct sw_flow.
> However, its size is hardcoded to CONFIG_NR_CPUS bits, which can be
> 8192 by default, it costs memory and slows down ovs_flow_alloc.
> This fix uses actual
From: eddytaoyuan
'struct cpumask cpu_used_mask' is embedded in struct sw_flow.
However, its size is hardcoded to CONFIG_NR_CPUS bits, which can be
8192 by default, it costs memory and slows down ovs_flow_alloc.
This fix uses actual CPU number instead
Signed-off-by: eddytaoyuan
---
On 2/1/23 07:25, Han Zhou wrote:
> Signed-off-by: Han Zhou
> ---
Hi Han,
Thanks for the fix!
> ovn-nb.xml | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/ovn-nb.xml b/ovn-nb.xml
> index 217eb877b055..929f4c966966 100644
> --- a/ovn-nb.xml
> +++ b/ovn-nb.xml
> @@
From: eddytaoyuan
struct cpumask cpu_used_mask is directly embedded in struct sw_flow
however, its size is hardcoded to CONFIG_NR_CPUS bits, which
can be as large as 8192 by default, it cost memory and slows down
ovs_flow_alloc, this fix used actual CPU number instead
Signed-off-by: eddytaoyuan
37 matches
Mail list logo