It's PR: Bugfix of meter_set crash. by batmancn · Pull Request #425 ·
openvswitch/ovs (github.com) <https://github.com/openvswitch/ovs/pull/425>
Simon Jones
Simon Jones 于2024年6月17日周一 15:35写道：
> This patch:
> ```
> $ git diff
> diff --git a/lib/netdev-offload-tc.c b/
fig->bands || config->n_bands < 1 ||
config->bands[0].type != OFPMBT13_DROP) {
```
Simon Jones
Simon Jones 于2024年6月17日周一 15:30写道：
> I use this patch to try to fix BUG, I test several times, it's OK
> ```
> [root@bogon yusur_ovs]# git diff
> diff --git a/lib/n
, );
+if (!init)
+return 0;
+else
+VLOG_WARN("Do not call meter_set before init.");
if (!config->bands || config->n_bands < 1 ||
config->bands[0].type != OFPMBT13_DROP) {
```
----
Simon Jones
Simon Jones 于2024年6月17日周一 11:13写道：
> I found
BUG.
Happens when ovs-vswitchd restart.
As bridge/port/meter is all stored in ovsdb.
If meter configure called before port configure, then rfa->flow_api->meter_set
will be called before rfa->flow_api->init_flow_api.
Then BUG happens.
```
----
Simon Jones
Simon Jones 于2024年6月17日周一 1
ave BUG.
So I think I should add some check...
Simon Jones
Simon Jones 于2024年6月17日周一 10:06写道：
> Oh, I'm using ovs-2.17.2, and I found that there is no .meter_set api
> implement in ovs-dpdk, which means only one .meter_set implement in TC.
> ```
> const struct net
netdev_get_name(netdev), rfa->flow_api->type);
```
Simon Jones
Simon Jones 于2024年6月14日周五 19:25写道：
> Maybe reason is this:
> ```
> @netdev_offload_tc and @netdev_offload_dpdk will always be register.
> Then the @meter_set api will be called.
> The @meter_set c
>type);
}
VLOG_INFO("%s: No suitable flow API found.", netdev_get_name(netdev));
return -1;
}
ONLY one type of rfa->flow_api->init_flow_api (DPDK or TC) could be called.
Because after one called, then return 0.
```
So I suggest to just remove 'return 0'.
Like thi
,dl_dst=00:00:00:00:03:01,nw_src=10.0.0.3,nw_dst=10.0.0.2,nw_tos=0,nw_ecn=0,nw_ttl=62,tp_src=0,tp_dst=0,tcp_flags=0
bridge("br-int")
thaw
Resuming from table 3
3. ip,metadata=0x2,in_port=3,dl_dst=00:00:00:00:03:01,nw_dst=10.0.0.2,
priority 30
clone(ct
ib/id-pool.c:112
the @pool param is NULL.
This is happened ONLY when @netdev_tc_init_flow_api is NOT called.
But in code, ONLY after @netdev_tc_init_flow_api is called, the
@handle_meter_mod could works on netdev with system type.
```
3. My question:
- How this BUG happen?
- Is there pat
-vswitchd interrupt to process request_mtu.
???
Simon Jones
Ilya Maximets 于2024年5月31日周五 17:43写道：
> On 5/31/24 04:00, Simon Jones wrote:
> > Hi all,
> >
> > I'm using ovs-dpdk(ovs:2.17.1, dpdk:21.11.1).
> > Now I found a BUG that ovs crash and could NOT fix agai
question
```
- Is this a BUG which has already been resolved? If it is, which commit?
- How to resolve this BUG?
```
Thanks~
Simon Jones
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Is this BUG has been fixed? Fixed in which commit?
Thanks~
Simon Jones
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
`
I found the cause is:
```
if (upcall.ukey && !ukey_install(udpif, upcall.ukey)) {
failed
```
and the log is :
```
WARN|upcall_cb failure: ukey installation fails
```
My question is:
1. Is this a fixed bug? If it is, which commit?
2. Is this a bug shoulf fix
.
Thank you~
Simon Jones
Simon Jones 于2023年10月27日周五 17:51写道：
> Hi all,
>
> I'm using ovs-dpdk version 2.17.1.
>
> Now I found ovs-ofctl replace xxx will cause flow_mod even if openflow is
> same.
>
> Detail:
> ```
> [root@localhost ~]# cat flows
> in_port="
NOT controlled by us.
Which means the command is NOT controlled by us.
But the ovs-ofctl and ovs-vswitchd is code by us.
So how to deal with this?
Is a good idea to change the behavior of fte_version_equals
- ofpacts_equal_stringwise, which could process all version?
Thank you~
Simon Jones
__
OK.
At last, I think this patch is done, nothing need I do. Is that?
Simon Jones
Ilya Maximets 于2023年8月3日周四 22:46写道：
> On 7/28/23 03:41, Simon Jones wrote:
> > From: Simon Jones
> >
> > ovs-tcpdump: clear auto-assigned ipv6 address of mirror port
>
From: Simon Jones
ovs-tcpdump: clear auto-assigned ipv6 address of mirror port
ovs-tcpdump will add mipxxx NIC, and on some systems this NIC has IPv6
address by default. For vxlan topology, mipxxx, which has IPv6
address, will be treated as tunnel port, and will got error actions.
Prevent
ok～
Simon Jones
Aaron Conole 于2023年7月27日周四 22:32写道：
> Simon Jones writes:
>
> > Hi Aaron,
> >
> > Thanks for your suggestion. This is my opinion as below.
> >
> >
> > Simon Jones
> >
> > Aaron Conole 于2023年7月20日周四 23:41写道：
&
Hi Aaron,
Thanks for your suggestion. This is my opinion as below.
Simon Jones
Aaron Conole 于2023年7月20日周四 23:41写道：
> Hi Simon,
>
> Thanks for the contribution!
>
> Simon Jones writes:
>
> > From: simon
> >
> > Fix bug of ovs-tcpdump, wh
ok ~
Many thanks for suggestion, I will fix these ~
Simon Jones
Simon Horman 于2023年7月27日周四 01:09写道：
> On Thu, Jul 20, 2023 at 11:38:41AM -0400, Aaron Conole wrote:
> > Hi Simon,
> >
> > Thanks for the contribution!
> >
> > Simon Jones writes:
> >
From: simon
Fix bug of ovs-tcpdump, which will cause megaflow action wrong.
As use ovs-tcpdump will add mipxxx NIC, and this NIC has IPv6 address by
default.
For vxlan topology, mipxxx will be treated as tunnel port, and will got
error actions.
For detail discuss, refer:
Ok, I will fix these.
Simon Jones
Ilya Maximets 于2023年7月4日周二 21:35写道：
> On 7/3/23 05:46, 冮晔维 wrote:
> > From: gangyewei
>
> Hi. Thanks for the update! Please, add a version number while
> sending new versions though, e.g. [PATCH v2]. Otherwise, it's
> hard t
Ok, thanks for the clarification.
I will modify and send this patch again by another email named as gangyewei.
Simon Jones
Ilya Maximets 于2023年6月29日周四 22:55写道：
> On 6/28/23 03:12, Simon Jones wrote:
> > This patch is same as MR: https://github.com/openvswitch/ovs
pipe.wait()
+
def _remove_dst_if_linux(tap_name):
_doexec(
--
2.24.3 (Apple Git-128)
----
Simon Jones
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
This bug is fixed in https://github.com/openvswitch/ovs/pull/415
Simon Jones
Simon Jones 于2023年6月15日周四 21:51写道：
> Add
> ： ovs-disc...@openvswitch.org
> ----
> Simon Jones
>
>
> Simon Jones 于2023年6月15日周四 21:48写道：
>
>> I found only vxlan topology has
Add
： ovs-disc...@openvswitch.org
Simon Jones
Simon Jones 于2023年6月15日周四 21:48写道：
> I found only vxlan topology has this bug.
>
> Other topology such as use patch port , no bug.
> ----
> Simon Jones
>
>
> Simon Jones 于2023年6月9日周五 15:20写道：
>
>> The rea
I found only vxlan topology has this bug.
Other topology such as use patch port , no bug.
Simon Jones
Simon Jones 于2023年6月9日周五 15:20写道：
> The reason why HOST-2 got DUP ICMP reply is HOST-1 got DUP ICMP request.
> The reason HOST-1 got DUP ICMP request is two tnl_pop(2) in a
The reason why HOST-2 got DUP ICMP reply is HOST-1 got DUP ICMP request.
The reason HOST-1 got DUP ICMP request is two tnl_pop(2) in actions in
megaflow-2.
So I have only 1 question:
Why megaflow-2 on HOST-1 has two tnl_pop(2) in actions ?
Simon Jones
Simon Jones 于2023年6月9日周五 11:45写道
=64 time=1.037 ms (DUP!)
64 bytes from 1.1.1.1: icmp_seq=15 ttl=64 time=0.965 ms
```
Additional, after I stop ovs-tcpdump or link down mip0(ip link set mip0
down), there is no DUP IMCP reply.
** 3. Here I have 2 questions **
1. Why megaflow-2 on HOST-1 has two tnl_pop(2) in actions ?
2. Why there
thread will create on
other core. And if port-1, port-2 down, remove pmd thread from core-1,
core-2 , and then create pmd thread from core-1. Like so on.
Is there some good idea about this ? Or some good design of other software
to solve this?
Thank you ~!
Simon Jones
,ct_zone(0),ct_mark(0),ct_label(0),recirc_id(0),dp_hash(0),in_port(1),packet_type(ns=0,id=0),eth(src=3e:cd:a3:ec:55:f3,dst=01:00:5e:00:00:16),eth_type(0x0800),ipv4(src=10.33.0.76,dst=224.0.0.22,proto=2,tos=0,ttl=1,frag=no)
```
So what's root cause of this BUG?
Is someone got same BUG?
Thank you~
--
BTW, if this is not problem?
As there are 8 core, pmd takes only 1 core.
So who has also run ovs-dpdk, what's your top result?
Simon Jones
Simon Jones 于2021年10月9日周六 下午2:35写道：
> This is perf result, it shows mlx5_rx_burst_vec function is called
> frequently. But there is no
s] [k] tracesys
> |
> --0.95%--tracesys
>
> 0.73% 0.56% pmd-c01/id:7 libpthread-2.17.so [.] __pthread_once
> |
> --0.56%--0x18
>|
> --0.55%--ofp_to_string__
>
(ov
fig: {dpdk-extra=" --proc-type primary ",
dpdk-hugepage-dir="/dev/hugepages", dpdk-init=True, dpdk-lcore-mask="0x1",
dpdk-mem-channels="4", dpdk-socket-mem="1024", pmd-cpu-mask="0x2"}
ovs_version : []
ssl : []
34 matches
Mail list logo
