[ovs-discuss] high cpu usage when use ovs
when i usage ovs for overlay network with geneve protocol, the topo is like bellow. two physic nodes, node1 and node2. in node1 i have network namespace vm1, its ip is 192.168.100.10. in node2 i have network namespace vm2, its ip is 192.168.100.20. in vm1 i start iperf3 server, in vm2 i start iperf3 as client. and get result is: # iperf3 -c 192.168.100.10 -t 2 Connecting to host 172.20.0.4, port 5201 [ 4] local 172.20.0.5 port 35272 connected to 172.20.0.4 port 5201 [ ID] Interval Transfer Bandwidth Retr Cwnd [ 4] 0.00-1.00 sec 322 MBytes 2.70 Gbits/sec0231 KBytes [ 4] 1.00-2.00 sec 320 MBytes 2.68 Gbits/sec2237 KBytes - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bandwidth Retr [ 4] 0.00-2.00 sec 642 MBytes 2.69 Gbits/sec2 sender [ 4] 0.00-2.00 sec 640 MBytes 2.68 Gbits/sec receiver iperf Done. as the physic network is 10G bw. when i see the cpu usage in node1, i get the result is: %Cpu18 : 0.7 us, 0.0 sy, 0.0 ni, 99.0 id, 0.3 wa, 0.0 hi, 0.0 si, 0.0 st %Cpu19 : 0.3 us, 0.0 sy, 0.0 ni, 99.7 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st %Cpu20 : 0.0 us, 0.3 sy, 0.0 ni, 0.7 id, 0.0 wa, 0.0 hi, 99.0 si, 0.0 st %Cpu21 : 0.3 us, 22.1 sy, 0.0 ni, 52.9 id, 0.0 wa, 0.0 hi, 24.7 si, 0.0 st %Cpu22 : 0.3 us, 1.7 sy, 0.0 ni, 95.7 id, 0.0 wa, 0.0 hi, 2.3 si, 0.0 st as we can see, the 20s cpu has be full. the thread of resource is: 132 root 20 0 0 0 0 R 90.0 0.0 0:52.96 ksoftirqd/20 9588 root 20 09756 2456 2212 S 51.8 0.0 7:59.99 iperf3 as we can see, ksoftirqd/20 use 100% of the cpu. i can not understand why ksoftirqd/20 use the full of the cpu? btw, i use the openvswitch.ko build from ovs tree of version 2.11.2. in home dir of ovs tree: # ll datapath/linux/openvswitch.ko -rw-r--r-- 1 root root 14056752 Nov 7 11:26 datapath/linux/openvswitch.ko anyone can give me some suggestions? ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
[ovs-discuss] Re： Re：Re： [HELP] Question about icmp pkt marked Invalid by userspace conntrack
Hi Darrell: Sorry, I forgot to tell you the attached flow is based on VM tx direction rate limit. So the datapath action order is conntrack -> meter -> forward decision -> output, For the VM rx direction rate limit, the datapath flow is as below, please help to check, thank you! Also, for the same flow table and meter configuration, the kernel datapath rate limit is more accurate than userspace datapath. For VM rx direction rate limit: ct_state(-new+est-rel-rpl-inv+trk),ct_label(0/0x1),recirc_id(0x29),in_port(5),packet_type(ns=0,id=0),eth(src=fa:16:3e:33:02:d8,dst=fa:16:3e:12:d7:77),eth_type(0x0800),ipv4(dst=192.168.1.10/255.255.255.248,proto=6,frag=no),tcp_flags(ack), packets:1031455, bytes:1481163900, used:0.149s, flags:., actions:ct(zone=4),recirc(0x2a) ct_state(-new+est-rel-rpl-inv+trk),ct_label(0/0x1),recirc_id(0x2a),in_port(5),packet_type(ns=0,id=0),eth(src=fa:16:3e:33:02:d8,dst=fa:16:3e:12:d7:77),eth_type(0x0800),ipv4(src=192.168.1.8,dst=192.168.1.10,proto=6,frag=no), packets:1685180, bytes:2415638857, used:0.118s, flags:P., actions:meter(1),6 -- ：Re: [ovs-discuss] Re：Re： [HELP] Question about icmp pkt marked Invalid by userspace conntrack Hi Timo On Wed, Nov 6, 2019 at 2:06 AM txfh2007 wrote: Hi Darrell: the flow dump result is as below: Please help to check BEFORE: ct_state(-new+est-rel-rpl-inv+trk),ct_label(0/0x1),recirc_id(0x1b),in_port(6),packet_type(ns=0,id=0),eth(src=fa:16:3e:12:d7:77,dst=fa:16:3e:33:02:d8),eth_type(0x0800),ipv4(dst=192.168.1.8/255.255.255.248,proto=6,frag=no),tcp_flags(psh|ack), packets:18934, bytes:2660, used:0.000s, flags:P., actions:ct(zone=1),recirc(0x1c) ct_state(-new+est-rel-rpl-inv+trk),ct_label(0/0x1),recirc_id(0x1c),in_port(6),packet_type(ns=0,id=0),eth(src=fa:16:3e:12:d7:77,dst=fa:16:3e:33:02:d8),eth_type(0x0800),ipv4(src=192.168.1.10,dst=192.168.1.8,proto=6,frag=no), packets:5345996, bytes:7676256441, used:0.000s, flags:P., actions:5 AFTER: ct_state(-new+est-rel-rpl-inv+trk),ct_label(0/0x1),recirc_id(0x19),in_port(6),packet_type(ns=0,id=0),eth(src=fa:16:3e:12:d7:77,dst=fa:16:3e:33:02:d8),eth_type(0x0800),ipv4(dst=192.168.1.8/255.255.255.248,proto=6,frag=no),tcp_flags(ack), packets:2473174, bytes:3551472384, used:0.136s, flags:., actions:meter(0),ct(zone=1),recirc(0x1a) meter is being applied by above rule and then the pipeline continues below to do another pass thru the datapath; this would likely explain the numbers Can you double check the Openflow rules and do the metering at output rule. ct_state(-new+est-rel-rpl-inv+trk),ct_label(0/0x1),recirc_id(0x1a),in_port(6),packet_type(ns=0,id=0),eth(src=fa:16:3e:12:d7:77,dst=fa:16:3e:33:02:d8),eth_type(0x0800),ipv4(src=192.168.1.10,dst=192.168.1.8,proto=6,frag=no), packets:5292889, bytes:7599875381, used:0.046s, flags:P., actions:5 meter rate is 1Gbps, iperf result is around 800Mbps [ 5] 95.00-96.00 sec 104 MBytes 869 Mbits/sec [ 5] 96.00-97.00 sec 79.4 MBytes 666 Mbits/sec [ 5] 97.00-98.00 sec 107 MBytes 896 Mbits/sec [ 5] 98.00-99.00 sec 75.4 MBytes 632 Mbits/sec [ 5] 99.00-100.00 sec 98.3 MBytes 824 Mbits/sec [ 5] 100.00-100.04 sec 0.00 Bytes 0.00 bits/sec - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bandwidth [ 5] 0.00-100.04 sec 0.00 Bytes 0.00 bits/sec sender [ 5] 0.00-100.04 sec 9.29 GBytes 798 Mbits/sec receiver -- ：Darrell Ball ：2019年11月6日(星期三) 02:46 ：txfh2007 ：Ben Pfaff ; ovs-discuss ：Re: [ovs-discuss] Re：Re： [HELP] Question about icmp pkt marked Invalid by userspace conntrack Hi Timo On Mon, Nov 4, 2019 at 11:29 PM txfh2007 wrote: Hi Darrell: The meter rate limit is set as 1Gbps, but the actual rate is around 500Mbps.. I have read the meter patch, but this patch is to prevent delta_t changed to 0. But in my case, the delta_t is around 35500ms. It might be good to just include all known related fixes anyways, including this other one https://github.com/openvswitch/ovs/commit/acc5df0e3cb036524d49891fdb9ba89b609dd26a For my case, the meter action is on openflow table 46, and the ct action is on table 44, the output action is on table 65, so I guess the order is right? Could you dump the 'relevant' datapath flows before adding the meter rule and after adding the meter rule ? ovs-appctl dpif/dump-flows Thanks Timo -- ：Darrell Ball ：2019年11月5日(星期二) 06:56 ：txfh2007 ：Ben Pfaff ; ovs-discuss ：Re: [ovs-discuss] Re：Re： [HELP] Question about icmp pkt marked Invalid by userspace conntrack Hi Timo On Sun, Nov 3, 2019 at 5:12 PM txfh2007 wrote: Hi Darrell: Sorry for my late reply. Yes, the two VMs under test are on same compute node , and pkts rx/tx via vhost user type port. Got it Firstly if I don't con
Re: [ovs-discuss] OVS deleting flows from the datapath on exit
You might be right.
I don't think this affects what actions we shoudl take, though. It
still seems better to use "exit" to stop OVS gracefully.
I'm working on a patch to make "exit" avoid removing flows unless
--cleanup is passed in. It's slow going because I've got higher
priorities things to do.
On Wed, Nov 06, 2019 at 09:39:12AM -0800, Guru Shetty wrote:
> It may have come from this commit instead:
>
> commit 9b5422a98f817b9f2a1f8224cab7e1a8d0bbba1f
> Author: Ilya Maximets
> Date: Wed Dec 16 15:32:21 2015 +0300
>
> ovs-lib: Try to call exit before killing.
>
> While killing OVS may not free all allocated resources.
>
> Previously we used to SIGTERM ovs-vswitchd and even now, it looks like
> doing that prevents the flush of datapath flows.
>
> On Fri, 1 Nov 2019 at 13:35, Ben Pfaff wrote:
>
> > OVS currently can gracefully exit in two ways: either with or without
> > deleting the datapath. But, either way, it deletes all of the flows
> > from the datapath before it exits. That is due to commit e96a5c24e853
> > ("upcall: Remove datapath flows when setting n-threads."), which was
> > first released in OVS 2.1 back in 2014.
> >
> > This isn't usually a big deal. However, some controller folks I'm
> > talking to are concerned about upgrade. If the datapath flows persisted
> > after OVS exits, then existing network connections (and perhaps some
> > that are "similar" to them because they match the same megaflows) could
> > carry on while the upgrade was in progress.
> >
> > I am surprised that I have not heard complaints about this in the 5
> > years that the behavior has been this way. Does anyone have any stories
> > to report about it now that I bring it up? Contrariwise, if we changed
> > OVS so that it did not delete datapath flows on exit, can anyone suggest
> > what problems that might cause?
> >
> > Thanks,
> >
> > Ben.
> > ___
> > discuss mailing list
> > disc...@openvswitch.org
> > https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
> >
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] ovs-vswitchd.service crashes
On Wed, Nov 06, 2019 at 01:59:36PM +0100, Koukal Petr wrote: > The problem is the same even if hw-offload is off. > > I'm sending a log from ovs-vswitchd.log just after restarting the whole > openvswitch-switch. > Here you can see what happens before the assertion pops up. > > ethtool -K phys1-1 hw-tc-offload off > ethtool -K phys1-2 hw-tc-offload off This demonstrates turning off hardware offload at the ethtool level. However, even with that, I believe that OVS will still try to use it if OVS is configured for hardware offload. It looks like your OVS does have hardware offload enabled. To turn it off, run: ovs-vsctl set Open_vSwitch . other-config:hw-offload=false Then restart OVS and see if it makes a difference. ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] OVS deleting flows from the datapath on exit
It may have come from this commit instead:
commit 9b5422a98f817b9f2a1f8224cab7e1a8d0bbba1f
Author: Ilya Maximets
Date: Wed Dec 16 15:32:21 2015 +0300
ovs-lib: Try to call exit before killing.
While killing OVS may not free all allocated resources.
Previously we used to SIGTERM ovs-vswitchd and even now, it looks like
doing that prevents the flush of datapath flows.
On Fri, 1 Nov 2019 at 13:35, Ben Pfaff wrote:
> OVS currently can gracefully exit in two ways: either with or without
> deleting the datapath. But, either way, it deletes all of the flows
> from the datapath before it exits. That is due to commit e96a5c24e853
> ("upcall: Remove datapath flows when setting n-threads."), which was
> first released in OVS 2.1 back in 2014.
>
> This isn't usually a big deal. However, some controller folks I'm
> talking to are concerned about upgrade. If the datapath flows persisted
> after OVS exits, then existing network connections (and perhaps some
> that are "similar" to them because they match the same megaflows) could
> carry on while the upgrade was in progress.
>
> I am surprised that I have not heard complaints about this in the 5
> years that the behavior has been this way. Does anyone have any stories
> to report about it now that I bring it up? Contrariwise, if we changed
> OVS so that it did not delete datapath flows on exit, can anyone suggest
> what problems that might cause?
>
> Thanks,
>
> Ben.
> ___
> discuss mailing list
> disc...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
>
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] Re：Re： [HELP] Question about icmp pkt marked Invalid by userspace conntrack
Hi Timo On Wed, Nov 6, 2019 at 2:06 AM txfh2007 wrote: > Hi Darrell: > > the flow dump result is as below: Please help to check > BEFORE: > > > ct_state(-new+est-rel-rpl-inv+trk),ct_label(0/0x1),recirc_id(0x1b),in_port(6),packet_type(ns=0,id=0),eth(src=fa:16:3e:12:d7:77,dst=fa:16:3e:33:02:d8),eth_type(0x0800),ipv4(dst= > 192.168.1.8/255.255.255.248,proto=6,frag=no),tcp_flags(psh|ack), > packets:18934, bytes:2660, used:0.000s, flags:P., > actions:ct(zone=1),recirc(0x1c) > > ct_state(-new+est-rel-rpl-inv+trk),ct_label(0/0x1),recirc_id(0x1c),in_port(6),packet_type(ns=0,id=0),eth(src=fa:16:3e:12:d7:77,dst=fa:16:3e:33:02:d8),eth_type(0x0800),ipv4(src=192.168.1.10,dst=192.168.1.8,proto=6,frag=no), > packets:5345996, bytes:7676256441, used:0.000s, flags:P., actions:5 > > AFTER: > > > ct_state(-new+est-rel-rpl-inv+trk),ct_label(0/0x1),recirc_id(0x19),in_port(6),packet_type(ns=0,id=0),eth(src=fa:16:3e:12:d7:77,dst=fa:16:3e:33:02:d8),eth_type(0x0800),ipv4(dst= > 192.168.1.8/255.255.255.248,proto=6,frag=no),tcp_flags(ack), > packets:2473174, bytes:3551472384, used:0.136s, flags:., > actions:meter(0),ct(zone=1),recirc(0x1a) > meter is being applied by above rule and then the pipeline continues below to do another pass thru the datapath; this would likely explain the numbers Can you double check the Openflow rules and do the metering at output rule. > ct_state(-new+est-rel-rpl-inv+trk),ct_label(0/0x1),recirc_id(0x1a),in_port(6),packet_type(ns=0,id=0),eth(src=fa:16:3e:12:d7:77,dst=fa:16:3e:33:02:d8),eth_type(0x0800),ipv4(src=192.168.1.10,dst=192.168.1.8,proto=6,frag=no), > packets:5292889, bytes:7599875381, used:0.046s, flags:P., actions:5 > > > > meter rate is 1Gbps, iperf result is around 800Mbps > > [ 5] 95.00-96.00 sec 104 MBytes 869 Mbits/sec > [ 5] 96.00-97.00 sec 79.4 MBytes 666 Mbits/sec > [ 5] 97.00-98.00 sec 107 MBytes 896 Mbits/sec > [ 5] 98.00-99.00 sec 75.4 MBytes 632 Mbits/sec > [ 5] 99.00-100.00 sec 98.3 MBytes 824 Mbits/sec > [ 5] 100.00-100.04 sec 0.00 Bytes 0.00 bits/sec > - - - - - - - - - - - - - - - - - - - - - - - - - > [ ID] Interval Transfer Bandwidth > [ 5] 0.00-100.04 sec 0.00 Bytes 0.00 bits/sec sender > [ 5] 0.00-100.04 sec 9.29 GBytes 798 Mbits/sec > receiver > > > > -- > ：Darrell Ball > ：2019年11月6日(星期三) 02:46 > ：txfh2007 > ：Ben Pfaff ; ovs-discuss > ：Re: [ovs-discuss] Re：Re： [HELP] Question about icmp pkt marked Invalid by > userspace conntrack > > > Hi Timo > > On Mon, Nov 4, 2019 at 11:29 PM txfh2007 wrote: > > Hi Darrell: > The meter rate limit is set as 1Gbps, but the actual rate is around > 500Mbps.. I have read the meter patch, but this patch is to prevent delta_t > changed to 0. But in my case, the delta_t is around 35500ms. > > > It might be good to just include all known related fixes anyways, > including this other one > > > > https://github.com/openvswitch/ovs/commit/acc5df0e3cb036524d49891fdb9ba89b609dd26a > > > > > For my case, the meter action is on openflow table 46, and the ct action > is on table 44, the output action is on table 65, so I guess the order is > right? > > > Could you dump the 'relevant' datapath flows before adding the meter rule > and after adding the meter rule ? > ovs-appctl dpif/dump-flows > > > > Thanks > > Timo > > > > -- > ：Darrell Ball > ：2019年11月5日(星期二) 06:56 > ：txfh2007 > ：Ben Pfaff ; ovs-discuss > ：Re: [ovs-discuss] Re：Re： [HELP] Question about icmp pkt marked Invalid by > userspace conntrack > > > Hi Timo > > On Sun, Nov 3, 2019 at 5:12 PM txfh2007 wrote: > > Hi Darrell: > Sorry for my late reply. Yes, the two VMs under test are on same > compute node , and pkts rx/tx via vhost user type port. > > Got it > > > Firstly if I don't configure meter table, then Iperf TCP bandwidth result > From VM1 to VM2 is around 5Gbps, then I set the meter entry and constraint > the rate, and the deviation is larger than I throught. > > > IIUC, pre-meter, you get 5 Gbps, then post-meter 0.5 Gpbs, which is less > than you expected ? > What did you expect the metered rate to be ? > Note Ben pointed you to a meter related bug fix on the alias b4. > > I guess the recalculation of l4 checksum during conntrack would impact > the actual rate? > > > are you applying the meter rule at end of the complete pipeline ? > > > Thank you > Timo > > > > > txfh2007 > Ben Pfaff ; ovs-discuss > Re: [ovs-discuss] Re：Re： [HELP] Question about icmp pkt marked Invalid by > userspace conntrack > > > Hi Timo > > > I read thru this thread to get more context on what you are doing; you > have a base OVS-DPDK > use case and are measuring VM to VM performance across 2 compute nodes. > You are probably using > vhost-user-client ports ? Pls correct me if I am wrong. > In this case, "per direction" you have one rx virtual interface to handle > in OVS; there will be
Re: [ovs-discuss] OVS DPDK: Failed to create memory pool for netdev
Hi Flavio, the only error I saw in 'ovs-vsctl show' was related to the dpdk port. The other ports all came up fine. Regarding the "ring error", I'm fine with having it, as long as DPDK is able to reserve the minimum amount of memory (which, after restarting OvS process is always the case). Regards Tobias On 05.11.19, 21:07, "Flavio Leitner" wrote: On Tue, 5 Nov 2019 18:47:09 + "Tobias Hofmann \(tohofman\) via discuss" wrote: > Hi Flavio, > > thanks for the insights! Unfortunately, I don't know about the pdump > and its relation to the ring. pdump dumps packets from dpdk ports into rings/mempools, so that you can inspect/use the traffic: https://doc.dpdk.org/guides/howto/packet_capture_framework.html But I looked at the dpdk sources now and I don't see it allocating any memory when the library is initialized, so this is likely a red herring. > Can you please specify where I can see that the port is not ready > yet? Is that these three lines: > > 2019-11-02T14:14:23.094Z|00070|dpdk|ERR|EAL: Cannot find unplugged > device (:08:0b.2) The above shows the device is not ready/bound yet. > 2019-11-02T14:14:23.094Z|00071|netdev_dpdk|WARN|Error attaching > device ':08:0b.2' to DPDK > 2019-11-02T14:14:23.094Z|00072|netdev|WARN|dpdk-p0: could not set > configuration (Invalid argument) > > As far as I know, the ring allocation failure that you mentioned > isn't necessarily a bad thing since it just indicates that DPDK > reduces something internally (I can't remember what exactly it was) > to support a high MTU with only 1GB of memory. True for the memory allocated for DPDK ports. However, there is a minimum which if it's not there, the mempool allocation will fail. > I'm wondering now if it might help to change the timing of when > openvswitch is started after a system reboot to prevent this problem > as it only occurs after reboot. Do you think that this approach might > fix the problem? It will help to get the i40e port working, but that "ring error" will continue as you see after restarting anyways. I don't know the other interface types, maybe there is another interface failing which is not in the log. Do you see any error reported in 'ovs-vsctl show' after the restart? fbl ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
[ovs-discuss] Re：Re： [HELP] Question about icmp pkt marked Invalid by userspace conntrack
Hi Darrell: the flow dump result is as below: Please help to check BEFORE: ct_state(-new+est-rel-rpl-inv+trk),ct_label(0/0x1),recirc_id(0x1b),in_port(6),packet_type(ns=0,id=0),eth(src=fa:16:3e:12:d7:77,dst=fa:16:3e:33:02:d8),eth_type(0x0800),ipv4(dst=192.168.1.8/255.255.255.248,proto=6,frag=no),tcp_flags(psh|ack), packets:18934, bytes:2660, used:0.000s, flags:P., actions:ct(zone=1),recirc(0x1c) ct_state(-new+est-rel-rpl-inv+trk),ct_label(0/0x1),recirc_id(0x1c),in_port(6),packet_type(ns=0,id=0),eth(src=fa:16:3e:12:d7:77,dst=fa:16:3e:33:02:d8),eth_type(0x0800),ipv4(src=192.168.1.10,dst=192.168.1.8,proto=6,frag=no), packets:5345996, bytes:7676256441, used:0.000s, flags:P., actions:5 AFTER: ct_state(-new+est-rel-rpl-inv+trk),ct_label(0/0x1),recirc_id(0x19),in_port(6),packet_type(ns=0,id=0),eth(src=fa:16:3e:12:d7:77,dst=fa:16:3e:33:02:d8),eth_type(0x0800),ipv4(dst=192.168.1.8/255.255.255.248,proto=6,frag=no),tcp_flags(ack), packets:2473174, bytes:3551472384, used:0.136s, flags:., actions:meter(0),ct(zone=1),recirc(0x1a) ct_state(-new+est-rel-rpl-inv+trk),ct_label(0/0x1),recirc_id(0x1a),in_port(6),packet_type(ns=0,id=0),eth(src=fa:16:3e:12:d7:77,dst=fa:16:3e:33:02:d8),eth_type(0x0800),ipv4(src=192.168.1.10,dst=192.168.1.8,proto=6,frag=no), packets:5292889, bytes:7599875381, used:0.046s, flags:P., actions:5 meter rate is 1Gbps, iperf result is around 800Mbps [ 5] 95.00-96.00 sec 104 MBytes 869 Mbits/sec [ 5] 96.00-97.00 sec 79.4 MBytes 666 Mbits/sec [ 5] 97.00-98.00 sec 107 MBytes 896 Mbits/sec [ 5] 98.00-99.00 sec 75.4 MBytes 632 Mbits/sec [ 5] 99.00-100.00 sec 98.3 MBytes 824 Mbits/sec [ 5] 100.00-100.04 sec 0.00 Bytes 0.00 bits/sec - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bandwidth [ 5] 0.00-100.04 sec 0.00 Bytes 0.00 bits/sec sender [ 5] 0.00-100.04 sec 9.29 GBytes 798 Mbits/sec receiver -- ：Darrell Ball ：2019年11月6日(星期三) 02:46 ：txfh2007 ：Ben Pfaff ; ovs-discuss ：Re: [ovs-discuss] Re：Re： [HELP] Question about icmp pkt marked Invalid by userspace conntrack Hi Timo On Mon, Nov 4, 2019 at 11:29 PM txfh2007 wrote: Hi Darrell: The meter rate limit is set as 1Gbps, but the actual rate is around 500Mbps.. I have read the meter patch, but this patch is to prevent delta_t changed to 0. But in my case, the delta_t is around 35500ms. It might be good to just include all known related fixes anyways, including this other one https://github.com/openvswitch/ovs/commit/acc5df0e3cb036524d49891fdb9ba89b609dd26a For my case, the meter action is on openflow table 46, and the ct action is on table 44, the output action is on table 65, so I guess the order is right? Could you dump the 'relevant' datapath flows before adding the meter rule and after adding the meter rule ? ovs-appctl dpif/dump-flows Thanks Timo -- ：Darrell Ball ：2019年11月5日(星期二) 06:56 ：txfh2007 ：Ben Pfaff ; ovs-discuss ：Re: [ovs-discuss] Re：Re： [HELP] Question about icmp pkt marked Invalid by userspace conntrack Hi Timo On Sun, Nov 3, 2019 at 5:12 PM txfh2007 wrote: Hi Darrell: Sorry for my late reply. Yes, the two VMs under test are on same compute node , and pkts rx/tx via vhost user type port. Got it Firstly if I don't configure meter table, then Iperf TCP bandwidth result From VM1 to VM2 is around 5Gbps, then I set the meter entry and constraint the rate, and the deviation is larger than I throught. IIUC, pre-meter, you get 5 Gbps, then post-meter 0.5 Gpbs, which is less than you expected ? What did you expect the metered rate to be ? Note Ben pointed you to a meter related bug fix on the alias b4. I guess the recalculation of l4 checksum during conntrack would impact the actual rate? are you applying the meter rule at end of the complete pipeline ? Thank you Timo txfh2007 Ben Pfaff ; ovs-discuss Re: [ovs-discuss] Re：Re： [HELP] Question about icmp pkt marked Invalid by userspace conntrack Hi Timo I read thru this thread to get more context on what you are doing; you have a base OVS-DPDK use case and are measuring VM to VM performance across 2 compute nodes. You are probably using vhost-user-client ports ? Pls correct me if I am wrong. In this case, "per direction" you have one rx virtual interface to handle in OVS; there will be a tradeoff b/w checksum validation security and performance. JTBC, in terms of your measurements, how did you arrive at the 5Gbps - instrumented code or otherwise ?. (I can verify that later when I have a setup). Darrell On Thu, Oct 31, 2019 at 9:23 AM Darrell Ball wrote: On Thu, Oct 31, 2019 at 3:04 AM txfh2007 via discuss wrote: Hi Ben && Darrell： This patch works, but after merging this patch I have found the iperf throughout decrease from 5Gbps+ to 50
