[ovs-dev] 答复: can userspace conntrack support IP fragment?
Yi Yang (杨燚)-云服务集团
yangyi01 at inspur.com
Tue Nov 17 09:37:41 UTC 2020
It works after I disabled my GRO, so please ignore my issue, thanks a lot.
-----邮件原件-----
发件人: Yi Yang (杨燚)-云服务集团
发送时间: 2020年11月17日 9:38
收件人: 'aconole at redhat.com' <aconole at redhat.com>
抄送: 'yihung.wei at gmail.com' <yihung.wei at gmail.com>; 'u9012063 at gmail.com' <u9012063 at gmail.com>; 'dlu998 at gmail.com' <dlu998 at gmail.com>; 'dev at openvswitch.org' <dev at openvswitch.org>; 'yang_y_yi at 163.com' <yang_y_yi at 163.com>
主题: 答复: can userspace conntrack support IP fragment?
重要性: 高
Thanks Aaron, here are my ipf settings
# ovs-appctl dpctl/ipf-get-status netdev at ovs-netdev
Fragmentation Module Status
---------------------------
v4 enabled: 1
v6 enabled: 1
max num frags (v4/v6): 1000
num frag: 0
min v4 frag size: 1200
v4 frags accepted: 660
v4 frags completed: 660
v4 frags expired: 0
v4 frags too small: 0
v4 frags overlapped: 0
v4 frags purged: 0
min v6 frag size: 1280
v6 frags accepted: 0
v6 frags completed: 0
v6 frags expired: 0
v6 frags too small: 0
v6 frags overlapped: 0
v6 frags purged: 0
I tried big packet ping, ICMP is ok, but tcp and udp are not ok. So I really don't know what's wrong. Ip fragment size should be 1500, it is VM MTU value.
root at yangyi-ovsdpdk-vm1-on-07:~# ping 172.16.1.250 -s 8192
PING 172.16.1.250 (172.16.1.250) 8192(8220) bytes of data.
8200 bytes from 172.16.1.250: icmp_seq=1 ttl=64 time=1.06 ms
8200 bytes from 172.16.1.250: icmp_seq=2 ttl=64 time=0.651 ms
8200 bytes from 172.16.1.250: icmp_seq=3 ttl=64 time=0.541 ms
8200 bytes from 172.16.1.250: icmp_seq=4 ttl=64 time=0.485 ms
8200 bytes from 172.16.1.250: icmp_seq=5 ttl=64 time=0.600 ms
8200 bytes from 172.16.1.250: icmp_seq=6 ttl=64 time=0.536 ms
^C
--- 172.16.1.250 ping statistics ---
6 packets transmitted, 6 received, 0% packet loss, time 5000ms
rtt min/avg/max/mdev = 0.485/0.646/1.067/0.197 ms
root at yangyi-ovsdpdk-vm1-on-07:~# tcpdump -i ens3 -vvv -c 5 icmp
tcpdump: listening on ens3, link-type EN10MB (Ethernet), capture size 262144 bytes
01:32:15.373681 IP (tos 0x0, ttl 64, id 3275, offset 0, flags [+], proto ICMP (1), length 1500)
172.16.1.250 > 172.16.2.10: ICMP echo request, id 1610, seq 22, length 1480
01:32:15.373705 IP (tos 0x0, ttl 64, id 3275, offset 1480, flags [+], proto ICMP (1), length 1500)
172.16.1.250 > 172.16.2.10: icmp
01:32:15.373709 IP (tos 0x0, ttl 64, id 3275, offset 2960, flags [+], proto ICMP (1), length 1500)
172.16.1.250 > 172.16.2.10: icmp
01:32:15.373712 IP (tos 0x0, ttl 64, id 3275, offset 4440, flags [+], proto ICMP (1), length 1500)
172.16.1.250 > 172.16.2.10: icmp
01:32:15.373715 IP (tos 0x0, ttl 64, id 3275, offset 5920, flags [+], proto ICMP (1), length 1500)
172.16.1.250 > 172.16.2.10: icmp
5 packets captured
240 packets received by filter
233 packets dropped by kernel
root at yangyi-ovsdpdk-vm1-on-07:~# iperf3 -t 5 -i 1 -c 172.16.1.250 --get-server-output
Connecting to host 172.16.1.250, port 5201
[ 4] local 172.16.2.10 port 55350 connected to 172.16.1.250 port 5201
[ ID] Interval Transfer Bandwidth Retr Cwnd
[ 4] 0.00-1.00 sec 433 KBytes 3.54 Mbits/sec 88 2.83 KBytes
[ 4] 1.00-2.00 sec 1.01 MBytes 8.43 Mbits/sec 124 4.24 KBytes
[ 4] 2.00-3.00 sec 921 KBytes 7.54 Mbits/sec 270 7.07 KBytes
[ 4] 3.00-4.00 sec 573 KBytes 4.69 Mbits/sec 86 4.24 KBytes
[ 4] 4.00-5.00 sec 1.06 MBytes 8.86 Mbits/sec 152 2.83 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Retr
[ 4] 0.00-5.00 sec 3.94 MBytes 6.61 Mbits/sec 720 sender
[ 4] 0.00-5.00 sec 3.82 MBytes 6.40 Mbits/sec receiver
Server output:
Accepted connection from 172.16.2.10, port 55348
[ 5] local 172.16.1.250 port 5201 connected to 172.16.2.10 port 55350
[ ID] Interval Transfer Bandwidth
[ 5] 0.00-1.00 sec 317 KBytes 2.59 Mbits/sec
[ 5] 1.00-2.00 sec 1015 KBytes 8.32 Mbits/sec
[ 5] 2.00-3.00 sec 897 KBytes 7.34 Mbits/sec
[ 5] 3.00-4.00 sec 590 KBytes 4.83 Mbits/sec
[ 5] 4.00-5.00 sec 1.04 MBytes 8.71 Mbits/sec
iperf Done.
root at yangyi-ovsdpdk-vm1-on-07:~# iperf3 -t 5 -i 1 -c 172.16.1.250 --get-server-output -u -b 1G -l 8192
Connecting to host 172.16.1.250, port 5201
[ 4] local 172.16.2.10 port 58188 connected to 172.16.1.250 port 5201
[ ID] Interval Transfer Bandwidth Total Datagrams
[ 4] 0.00-1.00 sec 119 MBytes 998 Mbits/sec 15223
[ 4] 1.00-2.00 sec 118 MBytes 990 Mbits/sec 15110
[ 4] 2.00-3.00 sec 120 MBytes 1.01 Gbits/sec 15418
[ 4] 3.00-4.00 sec 118 MBytes 989 Mbits/sec 15088
[ 4] 4.00-5.00 sec 121 MBytes 1.01 Gbits/sec 15443
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
[ 4] 0.00-5.00 sec 596 MBytes 1000 Mbits/sec 0.000 ms 0/0 (-nan%)
[ 4] Sent 0 datagrams
Server output:
-----------------------------------------------------------
Accepted connection from 172.16.2.10, port 55352
[ 5] local 172.16.1.250 port 5201 connected to 172.16.2.10 port 58188
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
[ 5] 0.00-1.00 sec 0.00 Bytes 0.00 bits/sec 0.000 ms 0/0 (-nan%)
[ 5] 1.00-2.00 sec 0.00 Bytes 0.00 bits/sec 0.000 ms 0/0 (-nan%)
[ 5] 2.00-3.00 sec 0.00 Bytes 0.00 bits/sec 0.000 ms 0/0 (-nan%)
[ 5] 3.00-4.00 sec 0.00 Bytes 0.00 bits/sec 0.000 ms 0/0 (-nan%)
[ 5] 4.00-5.00 sec 0.00 Bytes 0.00 bits/sec 0.000 ms 0/0 (-nan%)
iperf Done.
root at yangyi-ovsdpdk-vm1-on-07:~#
-----邮件原件-----
发件人: Aaron Conole [mailto:aconole at redhat.com]
发送时间: 2020年11月16日 22:58
收件人: Yi Yang (杨燚)-云服务集团 <yangyi01 at inspur.com>
抄送: yihung.wei at gmail.com; u9012063 at gmail.com; dlu998 at gmail.com; dev at openvswitch.org; yang_y_yi at 163.com
主题: Re: can userspace conntrack support IP fragment?
"Yi Yang (杨燚)-云服务集团" <yangyi01 at inspur.com> writes:
> Hi, folks
>
>
>
> I used latest ovs matser in Openstack, when I enabled security group
> and port security (note: openstack is using ovs openflow to implement security group), TCP performance is about several Mbps, big UDP packet (i.e.
> 8192) can’t work, but after disabled security group and port security,
> everything is ok, I doubt userspace conntrack can’t support IP
> fragment (or recent changes introduced bugs),
> https://bugzilla.redhat.com/show_bug.cgi?id=1639173 said it can’t
> handle big ICMP packet, anybody can help clarify what limitations of
> userspace conntrack are? Is there any existing document to warn users about them? Thank you in advance.
What were your frag settings? For example, try:
ovs-appctl dpctl/ipf-set-min-frag v4 1000
ovs-appctl dpctl/ipf-set-max-nfrags 500
See if that helps?
IIRC, the fragmentation engine doesn't support ICMP, just tcp/udp.
More information about the dev
mailing list