Re: [ovs-dev] [PATCH v4 ovn 0/2] Add IPv6 Prefix delegation (RFC3633)
On Fri, Dec 20, 2019 at 5:02 PM Lorenzo Bianconi wrote: > > Introduce IPv6 Prefix delegation state machine according to RFC 3633 > https://tools.ietf.org/html/rfc3633. > Add handle_dhcpv6_reply controller action to parse advertise/reply from > IPv6 delegation server. > Introduce logical flows in ovn router pipeline in order to parse dhcpv6 > advertise/reply from IPv6 prefix delegation router. > This series relies on the following OVS commit: > https://github.com/openvswitch/ovs/commit/cec89046f72cb044b068ba6a4e30dbcc4292c4c1 > Hi Lorenzo, I tested this patch series. And I don't think it is working as expected. My test setup has the below ovn resources ** witch 6f57f575-1dc0-463e-8c04-7bcee6697cea (public) port public-lr0 type: router router-port: lr0-public port ln-public type: localnet addresses: ["unknown"] switch 1fa5de75-fcae-49a8-9eca-55ed274cc100 (sw0) port sw0-port1 addresses: ["50:54:00:00:00:03 10.0.0.3"] port sw0-lr0 type: router router-port: lr0-sw0 switch 73af6b0e-8156-446e-8419-83e5ecc323ee (sw1) port sw1-lr0 type: router router-port: lr0-sw1 port sw1-port1 addresses: ["40:54:00:00:00:03 20.0.0.3"] router 87c8d985-3a42-423b-8ed0-d4a5b4cfb5ac (lr0) port lr0-public mac: "00:00:20:20:12:13" networks: ["172.16.0.100/24", "2001:db8:::1/64"] gateway chassis: [ovn-gw-1] port lr0-sw1 mac: "00:00:00:00:ff:02" networks: ["20.0.0.1/24"] port lr0-sw0 mac: "00:00:00:00:ff:01" networks: ["10.0.0.1/24"] ** When I enabled prefix delegation on lr-public, lr0-sw1 and lr0-sw0, ovn-controller (on ovn-gw-1) didn't send the IPv6 PD messages. I had to add an IPv6 address on lr0-public router port for ovn-controller to start sending IPv6 PD messages. *** ovn-nbctl add logical_router_port lr0-public networks "2001\:db8\:\:\:1/64" *** I think that should not be the case. If prefix_delegation=true is set on a lrp, then ovn-controller should use the IPv6 link local address (which is derived from the mac) instead of expecting CMS to configure an IPv6 address. In my case, the logical router port - lr0-sw0 never received any IPv6 prefix. lr0-sw1 did receive. In my testing, ovn-controller crashed with the below trace when I ran the above "ovn-nbctl add logical_router_port ..." command *** (gdb) bt #0 0x004b7875 in skiplist_get_data (node=node@entry=0x786966) at ../lib/skiplist.c:212 #1 0x004aa457 in ovsdb_idl_cursor_next_eq (cursor=cursor@entry=0x7ffe28971090) at ../lib/ovsdb-idl.c:2982 #2 0x0041f2fd in prepare_ipv6_prefixd (active_tunnels=0x1f3dc60, chassis=0x1f9f9d0, local_datapaths=0x1f3dc00, sbrec_port_binding_by_name=0x1f12cd0, sbrec_port_binding_by_datapath=, ovnsb_idl_txn=0x2036cb0) at ../controller/pinctrl.c:3257 #3 pinctrl_run (ovnsb_idl_txn=ovnsb_idl_txn@entry=0x2036cb0, sbrec_datapath_binding_by_key=sbrec_datapath_binding_by_key@entry=0x1f3f940, sbrec_port_binding_by_datapath=sbrec_port_binding_by_datapath@entry=0x1f134b0, sbrec_port_binding_by_key=sbrec_port_binding_by_key@entry=0x1f12e80, sbrec_port_binding_by_name=sbrec_port_binding_by_name@entry=0x1f12cd0, sbrec_mac_binding_by_lport_ip=sbrec_mac_binding_by_lport_ip@entry=0x1f3faf0, sbrec_igmp_groups=0x1f3d060, sbrec_ip_multicast_opts=0x1f3fc80, dns_table=0x1f48f50, ce_table=0x1f48f50, svc_mon_table=0x1f48f50, br_int=, chassis=0x1f9f9d0, local_datapaths=0x1f3dc00, active_tunnels=0x1f3dc60) at ../controller/pinctrl.c:2510 #4 0x00408536 in main (argc=, argv=) at ../controller/ovn-controller.c:2136 This patch series stores the received PD in the port_binding.options:ipv6_ra_pd_list column. CMS will not come to know about the configured PD. Ideally all this should be transparent to CMS. When ovn-controller stores the received PD in the port_binding.options, ovn-northd should read this value and store it in logical_Router_port addresses column (or probably a new column) to indicate CMS that prefix is configured for this router port. And if CMS has enabled, router advertisement for a router port, ovn-controller(s) should start sending RAs for the ports which belong to the logical switches. As suggested earlier, please enhance system-ovn test case to add another logical router port to the router R1 and make sure that all the logical router ports get separate prefixes. Thanks Numan > Changes since v3: > - cosmetics > - add a provider bridge in the unit-test deployment and add a localnet > port to the deployment to access the underlay network > - request IPv6 prefix even for bar router logical port in the unit-test > deployment > > Changes since v2: > - add unitest support in system-ovn.at > > Changes since v1: > - rebase on top of ovn master branch > - request an IPv6 prefix for each 'downstream' logical router port marked with > prefix set to true > - add missing documentation
[ovs-dev] Can I Trust You?
-- Dearest one, I bring you greetings from our Lord. It is my Pleasure to write to you after series of Prayers, thought and consideration Regarding the situation at hand. My name is MRS.IRINE PALMER from UNITED STATE OF AMERICA, married to PAULINA THOMAS ANTHONY a nationality of TURKEY who worked with Malaysian oil company for nine years before he died in the year 2006. We were married for eleven years without a child, he died after a brief illness that lasted for only four days. Before his death we were both born again Christians but Non discrimination of any religion. When my late husband was alive we deposited the sum of $8.3 Million (Eight Million three hundred thousand U.S. Dollars) with a BANK, Presently, this money is still with the bank. Recently, my Doctor told me that I would not last for the next three months due to cancer problem. Though what disturbs me most is my stroke. Having known my condition I want to donate this fund to church or better still a good Christian or Muslim individual that will utilize this money the way I am going to instruct herein. I want a church, Muslim or Christian that will use this fund to;churches,orphanages, Refugees,Research centers and widows propagating to the word of God and to ensure that the house of God is maintained. We Serve a Living God Whosoever that wants to serve the lord must serve him in spirit and truth. Any delay in your reply will give me room in sourcing for an Individual Christian or Church or Muslim individual for this same purpose. Please assure me that you will act accordingly as I stated here in. Please, always be prayerful at all time. Hoping to hearing from you soon. Remain blessed. Yours Sincerely, MRS. IRINE PAULINA THOMAS ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] 答复: [PATCH RFC] WIP: netdev-tpacket: Add AF_PACKET v3 support.
William, maybe you don't know that kind of tap interface you're saying only can be used for VM, that is why openvswitch has to introduce internal type for the case I'm saying. In OVS DPDK case, if you create the below interface, it is a tap interface. ovs-vsctl add-port tapX -- set interface type=internal It won't work if you create tap interface in the below way Ip tuntap add tapX node tap ovs-vsctl add-port br-int tapX I have tried af_packet for it, it can't work, I don't think af_xdp can work for such tap, maybe you can double confirm this. -邮件原件- 发件人: William Tu [mailto:u9012...@gmail.com] 发送时间: 2019年12月24日 8:17 收件人: Yi Yang (杨燚)-云服务集团 抄送: b...@ovn.org; d...@openvswitch.org; i.maxim...@ovn.org; echau...@redhat.com 主题: Re: [PATCH RFC] WIP: netdev-tpacket: Add AF_PACKET v3 support. On Sun, Dec 22, 2019 at 4:35 PM Yi Yang (杨燚)-云服务集团 wrote: > > Thanks William, af_packet only can open tap interface, it can't create > tap interface. Tap interface onlu can be created by the below way > > ovs-vsctl add-port tapX -- set interface tapX type=internal > > this tap is very special, it is like a mystery to me so far. "ip > tuntap add tapX mode tap" can't work for such tap interface. Why not? What's the error message? you can create a tapX device using ip tuntap first, and add tapX using OVS using ovs-vsctl add-port tapX -- set interface tapX type=afxdp Regards, William > > Anybody can tell me how I can create such a tap interface without using " > ovs-vsctl add-port tapX" > > By the way, I tried af_packet for veth, the performance is very good, > it is about 4Gbps on my machine, but it used TPACKET_V2. > > -邮件原件- > 发件人: William Tu [mailto:u9012...@gmail.com] > 发送时间: 2019年12月21日 1:50 > 收件人: Ben Pfaff > 抄送: d...@openvswitch.org; i.maxim...@ovn.org; Yi Yang (杨燚)-云服务集团 > ; echau...@redhat.com > 主题: Re: [PATCH RFC] WIP: netdev-tpacket: Add AF_PACKET v3 support. > > On Thu, Dec 19, 2019 at 08:44:30PM -0800, Ben Pfaff wrote: > > On Thu, Dec 19, 2019 at 04:41:25PM -0800, William Tu wrote: > > > Currently the performance of sending packets from userspace ovs to > > > kernel veth device is pretty bad as reported from YiYang[1]. > > > The patch adds AF_PACKET v3, tpacket v3, as another way to tx/rx > > > packet to linux device, hopefully showing better performance. > > > > > > AF_PACKET v3 should get closed to 1Mpps, as shown[2]. However, my > > > current patch using iperf tcp shows only 1.4Gbps, maybe I'm doing > > > something wrong. Also DPDK has similar implementation using > > > AF_PACKET v2[3]. This is still work-in-progress but any feedbacks > > > are welcome. > > > > Is there a good reason that this is implemented as a new kind of > > netdev rather than just a new way for the existing netdev > > implementation to do packet i/o? > > The AF_PACKET v3 is more like PMD mode driver (the netdev-afxdp and > other dpdk netdev), which has its own memory mgmt, ring structure, and > polling the descriptors. So I implemented it as a new kind. I feel its > pretty different than tap or existing af_packet netdev. > > But integrate it to the existing netdev (lib/netdev-linux.c) is also OK. > > William > ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] 答复: iperf tcp issue on veth using afxdp
Thanks Yifeng, good performance number. I'll run it on my machine and feedback you my result. -邮件原件- 发件人: Yifeng Sun [mailto:pkusunyif...@gmail.com] 发送时间: 2019年12月24日 6:59 收件人: Yi Yang (杨燚)-云服务集团 抄送: u9012...@gmail.com; d...@openvswitch.org; i.maxim...@ovn.org; echau...@redhat.com 主题: Re: [ovs-dev] iperf tcp issue on veth using afxdp Hi Yi, I don't have OVS DPDK setup yet. I need to set it up first. On my machine, afxdp can reach 4.6Gbps. [ 3] 0.0- 1.0 sec 564 MBytes 4.73 Gbits/sec [ 3] 1.0- 2.0 sec 553 MBytes 4.64 Gbits/sec [ 3] 2.0- 3.0 sec 558 MBytes 4.68 Gbits/sec [ 3] 3.0- 4.0 sec 556 MBytes 4.66 Gbits/sec [ 3] 4.0- 5.0 sec 545 MBytes 4.57 Gbits/sec [ 3] 5.0- 6.0 sec 554 MBytes 4.64 Gbits/sec [ 3] 6.0- 7.0 sec 548 MBytes 4.60 Gbits/sec [ 3] 7.0- 8.0 sec 548 MBytes 4.60 Gbits/sec [ 3] 8.0- 9.0 sec 550 MBytes 4.62 Gbits/sec [ 3] 9.0-10.0 sec 548 MBytes 4.60 Gbits/sec Thanks, Yifeng On Sun, Dec 22, 2019 at 4:40 PM Yi Yang (杨燚)-云服务集团 wrote: > > Hi, Yifeng > > I'll try it again. By the way, did you try af_packet for veth in OVS DPDK? In > my machine it can reach 4Gbps, do you think af_xdp can reach this number? > > -邮件原件- > 发件人: Yifeng Sun [mailto:pkusunyif...@gmail.com] > 发送时间: 2019年12月21日 9:11 > 收件人: William Tu > 抄送: ; Ilya Maximets > ; Eelco Chaudron ; Yi Yang > (杨燚)-云服务集团 > 主题: Re: [ovs-dev] iperf tcp issue on veth using afxdp > > This seems to be related to netdev-afxdp's batch size bigger than kernel's > xdp batch size. > I created a patch to fix it. > > https://patchwork.ozlabs.org/patch/1214397/ > > Could anyone take a look at this patch? > > Thanks, > Yifeng > > On Fri, Nov 22, 2019 at 9:52 AM William Tu wrote: > > > > Hi Ilya and Eelco, > > > > Yiyang reports very poor TCP performance on his setup and I can also > > reproduce it on my machine. Somehow I think this might be a kernel > > issue, but I don't know where to debug this. Need your suggestion > > about how to debug. > > > > So the setup is like the system-traffic, creating 2 namespaces and > > veth devices and attach to OVS. I do remember to turn off tx offload > > and ping, UDP, nc (tcp-mode) works fine. > > > > TCP using iperf drops to 0Mbps after 4 seconds. > > At server side: > > root@osboxes:~/ovs# ip netns exec at_ns0 iperf -s > > > > Server listening on TCP port 5001 > > TCP window size: 128 KByte (default) > > > > [ 4] local 10.1.1.1 port 5001 connected with 10.1.1.2 port 40384 > > Waiting for server threads to complete. Interrupt again to force quit. > > > > At client side > > root@osboxes:~/bpf-next# ip netns exec at_ns1 iperf -c 10.1.1.1 -i 1 > > -t 10 > > > > Client connecting to 10.1.1.1, TCP port 5001 TCP window size: 85.0 > > KByte (default) > > > > [ 3] local 10.1.1.2 port 40384 connected with 10.1.1.1 port 5001 > > [ ID] Interval Transfer Bandwidth > > [ 3] 0.0- 1.0 sec 17.0 MBytes 143 Mbits/sec > > [ 3] 1.0- 2.0 sec 9.62 MBytes 80.7 Mbits/sec [ 3] 2.0- 3.0 sec > > 6.75 MBytes 56.6 Mbits/sec [ 3] 3.0- 4.0 sec 11.0 MBytes 92.3 > > Mbits/sec [ 3] 5.0- 6.0 sec 0.00 Bytes 0.00 bits/sec [ 3] 6.0- > > 7.0 sec 0.00 Bytes 0.00 bits/sec [ 3] 7.0- 8.0 sec 0.00 Bytes > > 0.00 bits/sec [ 3] 8.0- 9.0 sec 0.00 Bytes 0.00 bits/sec [ 3] > > 9.0-10.0 sec 0.00 Bytes 0.00 bits/sec [ 3] 10.0-11.0 sec 0.00 > > Bytes 0.00 bits/sec > > > > (after this, even ping stops working) > > > > Script to reproduce > > - > > ovs-vsctl -- add-br br0 -- set Bridge br0 datapath_type=netdev > > > > ip netns add at_ns0 > > ip link add p0 type veth peer name afxdp-p0 ip link set p0 netns > > at_ns0 ip link set dev afxdp-p0 up ovs-vsctl add-port br0 afxdp-p0 > > > > ovs-vsctl -- set interface afxdp-p0 options:n_rxq=1 type="afxdp" > > options:xdp-mode=native > > ip netns exec at_ns0 sh << NS_EXEC_HEREDOC ip addr add "10.1.1.1/24" > > dev p0 ip link set dev p0 up NS_EXEC_HEREDOC > > > > ip netns add at_ns1 > > ip link add p1 type veth peer name afxdp-p1 ip link set p1 netns > > at_ns1 ip link set dev afxdp-p1 up ovs-vsctl add-port br0 afxdp-p1 > > -- \ > >set interface afxdp-p1 options:n_rxq=1 type="afxdp" > > options:xdp-mode=native > > > > ip netns exec at_ns1 sh << NS_EXEC_HEREDOC ip addr add "10.1.1.2/24" > > dev p1 ip link set dev p1 up NS_EXEC_HEREDOC > > > > ethtool -K afxdp-p0 tx off > > ethtool -K afxdp-p1 tx off > > ip netns exec at_ns0 ethtool -K p0 tx off ip netns exec at_ns1 > > ethtool -K p1 tx off > > > > ip netns exec at_ns0 ping -c 10 -i .2 10.1.1.2 echo "ip netns exec > > at_ns1 iperf -c 10.1.1.1 -i 1 -t 10" > > ip netns exec at_ns0 iperf -s > > > > Thank you > > William > > ___
Re: [ovs-dev] [PATCH RFC] WIP: netdev-tpacket: Add AF_PACKET v3 support.
On Sun, Dec 22, 2019 at 4:35 PM Yi Yang (杨燚)-云服务集团 wrote: > > Thanks William, af_packet only can open tap interface, it can't create tap > interface. Tap interface onlu can be created by the below way > > ovs-vsctl add-port tapX -- set interface tapX type=internal > > this tap is very special, it is like a mystery to me so far. "ip tuntap add > tapX mode tap" can't work for such tap interface. Why not? What's the error message? you can create a tapX device using ip tuntap first, and add tapX using OVS using ovs-vsctl add-port tapX -- set interface tapX type=afxdp Regards, William > > Anybody can tell me how I can create such a tap interface without using " > ovs-vsctl add-port tapX" > > By the way, I tried af_packet for veth, the performance is very good, it is > about 4Gbps on my machine, but it used TPACKET_V2. > > -邮件原件- > 发件人: William Tu [mailto:u9012...@gmail.com] > 发送时间: 2019年12月21日 1:50 > 收件人: Ben Pfaff > 抄送: d...@openvswitch.org; i.maxim...@ovn.org; Yi Yang (杨燚)-云服务集团 > ; echau...@redhat.com > 主题: Re: [PATCH RFC] WIP: netdev-tpacket: Add AF_PACKET v3 support. > > On Thu, Dec 19, 2019 at 08:44:30PM -0800, Ben Pfaff wrote: > > On Thu, Dec 19, 2019 at 04:41:25PM -0800, William Tu wrote: > > > Currently the performance of sending packets from userspace ovs to > > > kernel veth device is pretty bad as reported from YiYang[1]. > > > The patch adds AF_PACKET v3, tpacket v3, as another way to tx/rx > > > packet to linux device, hopefully showing better performance. > > > > > > AF_PACKET v3 should get closed to 1Mpps, as shown[2]. However, my > > > current patch using iperf tcp shows only 1.4Gbps, maybe I'm doing > > > something wrong. Also DPDK has similar implementation using > > > AF_PACKET v2[3]. This is still work-in-progress but any feedbacks > > > are welcome. > > > > Is there a good reason that this is implemented as a new kind of > > netdev rather than just a new way for the existing netdev > > implementation to do packet i/o? > > The AF_PACKET v3 is more like PMD mode driver (the netdev-afxdp and other > dpdk netdev), which has its own memory mgmt, ring structure, and polling the > descriptors. So I implemented it as a new kind. I feel its pretty different > than tap or existing af_packet netdev. > > But integrate it to the existing netdev (lib/netdev-linux.c) is also OK. > > William > ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] 答复: 答复: [PATCH RFC] WIP: netdev-tpacket: Add AF_PACKET v3 support.
On Mon, Dec 23, 2019 at 12:29:25AM +, Yi Yang (杨燚)-云服务集团 wrote: > Thanks William, > https://www.kernel.org/doc/Documentation/networking/packet_mmap.txt is very > good document for TPACKET_V*, I completely agree TPCKET_V3 is the best way to > improve tap and veth performance. Can you share us how to use your patch? > Lib/netdev-linux.c is still there, which recv function will be called when I > add veth/tap in OVS DPDK? > Hi Yiyang, To use my patch, simply add a port (ex: veth) by doing ovs-vsctl add-port br0 afxdp-p0 ovs-vsctl -- set interface afxdp-p0 options:n_rxq=1 type="tpacket" btw, this is not using OVS-DPDK. --William ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] iperf tcp issue on veth using afxdp
Hi Yi, I don't have OVS DPDK setup yet. I need to set it up first. On my machine, afxdp can reach 4.6Gbps. [ 3] 0.0- 1.0 sec 564 MBytes 4.73 Gbits/sec [ 3] 1.0- 2.0 sec 553 MBytes 4.64 Gbits/sec [ 3] 2.0- 3.0 sec 558 MBytes 4.68 Gbits/sec [ 3] 3.0- 4.0 sec 556 MBytes 4.66 Gbits/sec [ 3] 4.0- 5.0 sec 545 MBytes 4.57 Gbits/sec [ 3] 5.0- 6.0 sec 554 MBytes 4.64 Gbits/sec [ 3] 6.0- 7.0 sec 548 MBytes 4.60 Gbits/sec [ 3] 7.0- 8.0 sec 548 MBytes 4.60 Gbits/sec [ 3] 8.0- 9.0 sec 550 MBytes 4.62 Gbits/sec [ 3] 9.0-10.0 sec 548 MBytes 4.60 Gbits/sec Thanks, Yifeng On Sun, Dec 22, 2019 at 4:40 PM Yi Yang (杨燚)-云服务集团 wrote: > > Hi, Yifeng > > I'll try it again. By the way, did you try af_packet for veth in OVS DPDK? In > my machine it can reach 4Gbps, do you think af_xdp can reach this number? > > -邮件原件- > 发件人: Yifeng Sun [mailto:pkusunyif...@gmail.com] > 发送时间: 2019年12月21日 9:11 > 收件人: William Tu > 抄送: ; Ilya Maximets > ; Eelco Chaudron ; Yi Yang > (杨燚)-云服务集团 > 主题: Re: [ovs-dev] iperf tcp issue on veth using afxdp > > This seems to be related to netdev-afxdp's batch size bigger than kernel's > xdp batch size. > I created a patch to fix it. > > https://patchwork.ozlabs.org/patch/1214397/ > > Could anyone take a look at this patch? > > Thanks, > Yifeng > > On Fri, Nov 22, 2019 at 9:52 AM William Tu wrote: > > > > Hi Ilya and Eelco, > > > > Yiyang reports very poor TCP performance on his setup and I can also > > reproduce it on my machine. Somehow I think this might be a kernel > > issue, but I don't know where to debug this. Need your suggestion > > about how to debug. > > > > So the setup is like the system-traffic, creating 2 namespaces and > > veth devices and attach to OVS. I do remember to turn off tx offload > > and ping, UDP, nc (tcp-mode) works fine. > > > > TCP using iperf drops to 0Mbps after 4 seconds. > > At server side: > > root@osboxes:~/ovs# ip netns exec at_ns0 iperf -s > > > > Server listening on TCP port 5001 > > TCP window size: 128 KByte (default) > > > > [ 4] local 10.1.1.1 port 5001 connected with 10.1.1.2 port 40384 > > Waiting for server threads to complete. Interrupt again to force quit. > > > > At client side > > root@osboxes:~/bpf-next# ip netns exec at_ns1 iperf -c 10.1.1.1 -i 1 > > -t 10 > > > > Client connecting to 10.1.1.1, TCP port 5001 TCP window size: 85.0 > > KByte (default) > > > > [ 3] local 10.1.1.2 port 40384 connected with 10.1.1.1 port 5001 > > [ ID] Interval Transfer Bandwidth > > [ 3] 0.0- 1.0 sec 17.0 MBytes 143 Mbits/sec > > [ 3] 1.0- 2.0 sec 9.62 MBytes 80.7 Mbits/sec [ 3] 2.0- 3.0 sec > > 6.75 MBytes 56.6 Mbits/sec [ 3] 3.0- 4.0 sec 11.0 MBytes 92.3 > > Mbits/sec [ 3] 5.0- 6.0 sec 0.00 Bytes 0.00 bits/sec [ 3] 6.0- > > 7.0 sec 0.00 Bytes 0.00 bits/sec [ 3] 7.0- 8.0 sec 0.00 Bytes > > 0.00 bits/sec [ 3] 8.0- 9.0 sec 0.00 Bytes 0.00 bits/sec [ 3] > > 9.0-10.0 sec 0.00 Bytes 0.00 bits/sec [ 3] 10.0-11.0 sec 0.00 > > Bytes 0.00 bits/sec > > > > (after this, even ping stops working) > > > > Script to reproduce > > - > > ovs-vsctl -- add-br br0 -- set Bridge br0 datapath_type=netdev > > > > ip netns add at_ns0 > > ip link add p0 type veth peer name afxdp-p0 ip link set p0 netns > > at_ns0 ip link set dev afxdp-p0 up ovs-vsctl add-port br0 afxdp-p0 > > > > ovs-vsctl -- set interface afxdp-p0 options:n_rxq=1 type="afxdp" > > options:xdp-mode=native > > ip netns exec at_ns0 sh << NS_EXEC_HEREDOC ip addr add "10.1.1.1/24" > > dev p0 ip link set dev p0 up NS_EXEC_HEREDOC > > > > ip netns add at_ns1 > > ip link add p1 type veth peer name afxdp-p1 ip link set p1 netns > > at_ns1 ip link set dev afxdp-p1 up ovs-vsctl add-port br0 afxdp-p1 -- > > \ > >set interface afxdp-p1 options:n_rxq=1 type="afxdp" > > options:xdp-mode=native > > > > ip netns exec at_ns1 sh << NS_EXEC_HEREDOC ip addr add "10.1.1.2/24" > > dev p1 ip link set dev p1 up NS_EXEC_HEREDOC > > > > ethtool -K afxdp-p0 tx off > > ethtool -K afxdp-p1 tx off > > ip netns exec at_ns0 ethtool -K p0 tx off ip netns exec at_ns1 ethtool > > -K p1 tx off > > > > ip netns exec at_ns0 ping -c 10 -i .2 10.1.1.2 echo "ip netns exec > > at_ns1 iperf -c 10.1.1.1 -i 1 -t 10" > > ip netns exec at_ns0 iperf -s > > > > Thank you > > William > > ___ > > dev mailing list > > d...@openvswitch.org > > https://mail.openvswitch.org/mailman/listinfo/ovs-dev ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH v2] netdev-dpdk: Add ability to set MAC address.
Hi Ilya, I have taken and tested your code against DPDK 19.11.0 release. I can confirm your code works, but at the moment is not being called. When setting MAC address in OVSDB, there is an interface type check in vswitchd/bridge.c:iface_set_mac() that block calls to any set_etheraddr()s except for internal interfaces. I have submitted a separate patch to allow DPDK interfaces through as well as internal: https://patchwork.ozlabs.org/patch/1215075/ Please, take a look at it and let me if you think it's ok. We have also verified Roni's RFC use-case for cloud controllers ( https://mail.openvswitch.org/pipermail/ovs-dev/2019-October/364063.html ) with DPDK 19.11 - needed changes to propagate representor's MAC to VF are merged. Note: for 19.11 need to prefix struct ether_addr with 'rte_'. Sincerely, Eveline Raine ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [PATCH 0/1] vswitchd: Allow setting MAC on DPDK interfaces
This patch extends the type check in iface_set_mac() to allow DPDK interfaces. It provides the missing functionality to the following patch, to allow setting MAC address on a DPDK interface: "[ovs-dev,v2] netdev-dpdk: Add ability to set MAC address." (https://patchwork.ozlabs.org/patch/1186896/) This and the linked Ilya's patch together implement the following RFC to enhance integration with cloud controllers (e.g. OpenStack): "[ovs-dev] [RFC v2] netdev-dpdk: setting VF MAC address" (https://mail.openvswitch.org/pipermail/ovs-dev/2019-October/364063.html) Eveline Raine (1): vswitchd: Allow setting MAC on DPDK interfaces vswitchd/bridge.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- 2.23.0 ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [PATCH 1/1] vswitchd: Allow setting MAC on DPDK interfaces
When setting mac address for an interface using ovs-vsctl command:
ovs-vsctl set interface mac=XX:XX:XX:XX:XX:XX
iface_set_mac() is responsible to delegate a request to set MAC to a
netdev-specific set_etheraddr().
At the moment iface_set_mac() skips all interfaces except those with
type = "internal", making it impossible to change MAC on any DPDK port.
Since DPDK ports are owned by the OVS process, OVSDB can be considered
the source of truth for them. In particular, the source of truth for
their MAC addresses - so, OVS can take responsibility for setting them.
Therefore this check is extended to "dpdk" type.
Acked-by: Roni Bar Yanai
Tested-by: Adrian Chiris
Signed-off-by: Eveline Raine
---
vswitchd/bridge.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/vswitchd/bridge.c b/vswitchd/bridge.c
index 5de0a264a..355364afd 100644
--- a/vswitchd/bridge.c
+++ b/vswitchd/bridge.c
@@ -4696,7 +4696,7 @@ iface_set_mac(const struct bridge *br, const struct port
*port, struct iface *if
struct eth_addr ea, *mac = NULL;
struct iface *hw_addr_iface;
-if (strcmp(iface->type, "internal")) {
+if (strcmp(iface->type, "internal") && strcmp(iface->type, "dpdk")) {
return;
}
--
2.23.0
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [PATCH] netdev_afxdp: Detects combined channels and aborts wrong config
This patches detects the number of combined channels on a AF_XDP port
via using ethtool interface. If the number of combined channels
is different from the n_rxq, netdev_afxdp will not be able to get
all the packets from that port. Thus, abort the port setup when
the case is detected.
Signed-off-by: Yi-Hung Wei
---
Travis CI: https://travis-ci.org/YiHungWei/ovs/builds/627972465
---
lib/netdev-afxdp.c | 15 +++
lib/netdev-linux.c | 27 +++
lib/netdev-linux.h | 2 ++
3 files changed, 44 insertions(+)
diff --git a/lib/netdev-afxdp.c b/lib/netdev-afxdp.c
index 58365ed483e3..6d002882d355 100644
--- a/lib/netdev-afxdp.c
+++ b/lib/netdev-afxdp.c
@@ -601,6 +601,14 @@ netdev_afxdp_set_config(struct netdev *netdev, const
struct smap *args,
enum afxdp_mode xdp_mode;
bool need_wakeup;
int new_n_rxq;
+int combined_channels;
+
+if (netdev_linux_ethtool_get_combined_channels(netdev,
+ &combined_channels)) {
+VLOG_INFO("Cannot get the number of combined channels of %s. "
+ "Defaults it to 1.", netdev_get_name(netdev));
+combined_channels = 1;
+}
ovs_mutex_lock(&dev->mutex);
new_n_rxq = MAX(smap_get_int(args, "n_rxq", NR_QUEUE), 1);
@@ -611,6 +619,13 @@ netdev_afxdp_set_config(struct netdev *netdev, const
struct smap *args,
return EINVAL;
}
+if (new_n_rxq != combined_channels) {
+ovs_mutex_unlock(&dev->mutex);
+VLOG_ERR("%s: n_rxq: %d != combined channels: %d.",
+ netdev_get_name(netdev), new_n_rxq, combined_channels);
+return EINVAL;
+}
+
str_xdp_mode = smap_get_def(args, "xdp-mode", "best-effort");
for (xdp_mode = OVS_AF_XDP_MODE_BEST_EFFORT;
xdp_mode < OVS_AF_XDP_MODE_MAX;
diff --git a/lib/netdev-linux.c b/lib/netdev-linux.c
index f8e59bacfb13..e3086fc1cbb6 100644
--- a/lib/netdev-linux.c
+++ b/lib/netdev-linux.c
@@ -2166,6 +2166,33 @@ out:
netdev->get_features_error = error;
}
+int
+netdev_linux_ethtool_get_combined_channels(struct netdev *netdev_,
+ int *combined_channels)
+{
+struct netdev_linux *netdev = netdev_linux_cast(netdev_);
+struct ethtool_channels echannels;
+int err;
+
+ovs_mutex_lock(&netdev->mutex);
+
+COVERAGE_INC(netdev_get_ethtool);
+
+memset(&echannels, 0, sizeof echannels);
+err = netdev_linux_do_ethtool(netdev_get_name(netdev_),
+ (struct ethtool_cmd *) &echannels,
+ ETHTOOL_GCHANNELS, "ETHTOOL_GCHANNELS");
+if (err) {
+goto exit;
+}
+
+*combined_channels = echannels.combined_count;
+
+exit:
+ovs_mutex_unlock(&netdev->mutex);
+return err;
+}
+
/* Stores the features supported by 'netdev' into of '*current', '*advertised',
* '*supported', and '*peer'. Each value is a bitmap of NETDEV_* bits.
* Returns 0 if successful, otherwise a positive errno value. */
diff --git a/lib/netdev-linux.h b/lib/netdev-linux.h
index e1e30f806557..55cade4bb356 100644
--- a/lib/netdev-linux.h
+++ b/lib/netdev-linux.h
@@ -27,6 +27,8 @@ struct netdev;
int netdev_linux_ethtool_set_flag(struct netdev *netdev, uint32_t flag,
const char *flag_name, bool enable);
+int netdev_linux_ethtool_get_combined_channels(struct netdev *netdev,
+ int *combined_channels);
int linux_get_ifindex(const char *netdev_name);
#endif /* netdev-linux.h */
--
2.17.1
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH] afxdp: Reduce afxdp's batch size to match kernel's xdp batch size
Thanks Ilya. This patch is actually a quick fix. Sure, I will check generic mode later. Thanks, Yifeng On Mon, Dec 23, 2019 at 12:22 AM Ilya Maximets wrote: > > On Sat, Dec 21, 2019 at 2:03 AM Yifeng Sun wrote: > > > > William reported that there is iperf TCP issue between two afxdp ports: > > > > [ 3] local 10.1.1.2 port 40384 connected with 10.1.1.1 port 5001 > > [ ID] Interval Transfer Bandwidth > > [ 3] 0.0- 1.0 sec 17.0 MBytes 143 Mbits/sec > > [ 3] 1.0- 2.0 sec 9.62 MBytes 80.7 Mbits/sec > > [ 3] 2.0- 3.0 sec 6.75 MBytes 56.6 Mbits/sec > > [ 3] 3.0- 4.0 sec 11.0 MBytes 92.3 Mbits/sec > > [ 3] 5.0- 6.0 sec 0.00 Bytes 0.00 bits/sec > > [ 3] 6.0- 7.0 sec 0.00 Bytes 0.00 bits/sec > > [ 3] 7.0- 8.0 sec 0.00 Bytes 0.00 bits/sec > > [ 3] 8.0- 9.0 sec 0.00 Bytes 0.00 bits/sec > > [ 3] 9.0-10.0 sec 0.00 Bytes 0.00 bits/sec > > [ 3] 10.0-11.0 sec 0.00 Bytes 0.00 bits/sec > > > > The reason is, currently, netdev-afxdp's batch size is 32 while kernel's > > xdp batch size is only 16. This can result in exhausting of sock wmem if > > netdev-afxdp keeps sending large number of packets. Later on, when ARP > > expires at one side of TCP connection, ARP packets can be delayed or > > even dropped because sock wmen is already full. > > > > This patch fixes this issue by reducing netdev-afxdp's batch size so > > as to match kernel's xdp batch size. Now iperf TCP works correctly. > > I didn't look at the veth driver implementation yet, but if your issue > analysis is correct, driver doesn't process all the packets we're > trying to send. In this case changing the batch size should not fully > fix the issue since we're still could push packets fast enough to fill > queues that will not be drained by kernel or some packets could stuck > inside queues if we'll not send other packets. This sounds more like > a missing napi rescheduling or incorrect work with need-wakeup feature > inside the veth driver. I could look at it on the next week > (travelling now). > > Anyway, we should not ultimately change batch size because it will > affect performance on all modes and all drivers. Since your > workaround fixes the issue at least partially, same multi-kick > workaround for this case as we have for generic mode might work here > too. Could you, please, check? > > Best regards, Ilya Maximets. ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH ovn v4 0/2] Add a way to delete QoS directly
On Mon, Dec 23, 2019 at 2:37 AM Yunxiang Tao < taoyunxi...@cmss.chinamobile.com> wrote: > > Currently, qos can only be deleted by indirect way which must designate > switch or more parameters. The first patch add "name" column to QoS table, > and make QoS table could be listed by "name" witch comand > "ovn-nbctl list qos "name"". > > The second patch change the original "qos-del" to "ls-qos-del", add > a new "qos-del" command. By the new command, you can delete qos > by uuid or name of the qos. It is useful. For example, we can associate > the qos table in neutron and OVN by "name" of qos in OVN, so neutron > could find and easily delete the corresponding qos in OVN. > Thanks for the patch. I have below comments: 1. There are other ways to associate QoS between Neutron and OVN. For example, the external-ids column can be used to add any customized key-value pairs, such as external_ids:neutron:qos_name = . Is this sufficient for your use case? 2. If we believe it is useful for qos-del command to delete qos by name/uuid, it is better to extend the exist command "qos-del" to handle both old and new formats, and we should NOT rename the existing command because it will break existing customer tools. 3. It is more efficient to specify the lswitch in the qos-del command so that it doesn't need to iterate every lswitch. Is there a use case that neutron needs to delete a QoS record without knowing which lswitch should it be deleted from? 4. QoS and ACL are implemented in similar way with similar principles. If "name" is needed in QoS table, probably it is also needed in ACL table. In other words, if we can handle ACL well without introducing the "name" column, probably we could do the same for QoS table without problem. What's your thought on this? ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [PATCH] netdev-offload-tc: Add checking when assigning flow api
From: Tonghao Zhang
netdev_assign_flow_api will try to init the netdev,
if success, the netdev will use the offload api.
If we init the type of netdev is dpdk, using the tc offload
api (netdev_tc_init_flow_api, which may be called firstly.),
the err log always is showing up. This patch adds a additional
check, and can void the err log.
"failed adding ingress qdisc required for offloading: No such device"
Signed-off-by: Tonghao Zhang
---
lib/netdev-linux.c | 21 +
lib/netdev-linux.h | 1 +
lib/netdev-offload-tc.c | 4
3 files changed, 26 insertions(+)
diff --git a/lib/netdev-linux.c b/lib/netdev-linux.c
index f8e59ba..bd83e64 100644
--- a/lib/netdev-linux.c
+++ b/lib/netdev-linux.c
@@ -3317,6 +3317,27 @@ const struct netdev_class netdev_afxdp_class = {
#endif
+static bool
+is_linux_class(const struct netdev_class *class)
+{
+if (class->destruct == netdev_linux_destruct) {
+return true;
+}
+#ifdef HAVE_AF_XDP
+if (class->destruct == netdev_afxdp_destruct) {
+return true;
+}
+#endif
+
+return false;
+}
+
+bool
+netdev_linux_flow_api_supported(const struct netdev *netdev)
+{
+return is_linux_class(netdev->netdev_class);
+}
+
#define CODEL_N_QUEUES 0x
/* In sufficiently new kernel headers these are defined as enums in
diff --git a/lib/netdev-linux.h b/lib/netdev-linux.h
index e1e30f8..43cc725 100644
--- a/lib/netdev-linux.h
+++ b/lib/netdev-linux.h
@@ -28,5 +28,6 @@ struct netdev;
int netdev_linux_ethtool_set_flag(struct netdev *netdev, uint32_t flag,
const char *flag_name, bool enable);
int linux_get_ifindex(const char *netdev_name);
+bool netdev_linux_flow_api_supported(const struct netdev *netdev);
#endif /* netdev-linux.h */
diff --git a/lib/netdev-offload-tc.c b/lib/netdev-offload-tc.c
index 1adbb32..80bbf2d 100644
--- a/lib/netdev-offload-tc.c
+++ b/lib/netdev-offload-tc.c
@@ -1643,6 +1643,10 @@ netdev_tc_init_flow_api(struct netdev *netdev)
int ifindex;
int error;
+if (!netdev_linux_flow_api_supported(netdev)) {
+return EOPNOTSUPP;
+}
+
ifindex = netdev_get_ifindex(netdev);
if (ifindex < 0) {
VLOG_INFO("init: failed to get ifindex for %s: %s",
--
1.8.3.1
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [PATCH] dpif-netdev: Allow to set max capacity of flow on netdev
From: Tonghao Zhang
There may be too many flows (> MAX_FLOWS 65536) on
dpif-netdev at same time. For this case, we support
the ovs-appctl command to change the flow max number.
Signed-off-by: Tonghao Zhang
---
lib/dpif-netdev.c | 51 +--
1 file changed, 49 insertions(+), 2 deletions(-)
diff --git a/lib/dpif-netdev.c b/lib/dpif-netdev.c
index 8485b54db0d8..9d14268aa703 100644
--- a/lib/dpif-netdev.c
+++ b/lib/dpif-netdev.c
@@ -97,7 +97,6 @@ DEFINE_STATIC_PER_THREAD_DATA(uint32_t, recirc_depth, 0)
#define DEFAULT_TX_FLUSH_INTERVAL 0
/* Configuration parameters. */
-enum { MAX_FLOWS = 65536 }; /* Maximum number of flows in flow table. */
enum { MAX_METERS = 65536 };/* Maximum number of meters. */
enum { MAX_BANDS = 8 }; /* Maximum number of bands / meter. */
enum { N_METER_LOCKS = 64 };/* Maximum number of meters. */
@@ -105,6 +104,9 @@ enum { N_METER_LOCKS = 64 };/* Maximum number of
meters. */
/* Protects against changes to 'dp_netdevs'. */
static struct ovs_mutex dp_netdev_mutex = OVS_MUTEX_INITIALIZER;
+/* Maximum number of flows in flow table. */
+static uint32_t netdev_max_flows = 65536;
+
/* Contains all 'struct dp_netdev's. */
static struct shash dp_netdevs OVS_GUARDED_BY(dp_netdev_mutex)
= SHASH_INITIALIZER(&dp_netdevs);
@@ -1112,6 +1114,43 @@ pmd_info_show_perf(struct ds *reply,
}
}
+static void
+dpif_netdev_set_max_flow(struct unixctl_conn *conn,
+ int argc OVS_UNUSED,
+ const char *argv[],
+ void *aux OVS_UNUSED)
+{
+struct ds ds = DS_EMPTY_INITIALIZER;
+uint32_t max_flows = atoi(argv[1]);
+
+if (!max_flows) {
+unixctl_command_reply_error(conn,
+"the max flow capacity should > 0\n");
+return;
+}
+
+netdev_max_flows = max_flows;
+ds_put_format(&ds, "set netdev_max_flows to %u\n", netdev_max_flows);
+unixctl_command_reply(conn, ds_cstr(&ds));
+
+ds_destroy(&ds);
+}
+
+static void
+dpif_netdev_show_max_flow(struct unixctl_conn *conn,
+ int argc OVS_UNUSED,
+ const char *argv[] OVS_UNUSED,
+ void *aux OVS_UNUSED)
+{
+struct ds reply = DS_EMPTY_INITIALIZER;
+
+ds_put_format(&reply,"pmd flow capacity: %u\n",
+ netdev_max_flows);
+unixctl_command_reply(conn, ds_cstr(&reply));
+
+ds_destroy(&reply);
+}
+
static int
compare_poll_list(const void *a_, const void *b_)
{
@@ -1416,6 +1455,14 @@ dpif_netdev_init(void)
"[-us usec] [-q qlen]",
0, 10, pmd_perf_log_set_cmd,
NULL);
+unixctl_command_register("dpif-netdev/pmd-set-flow-capacity",
+ "max-flow-number",
+ 1, 1, dpif_netdev_set_max_flow,
+ NULL);
+unixctl_command_register("dpif-netdev/pmd-show-flow-capacity",
+ "",
+ 0, 0, dpif_netdev_show_max_flow,
+ NULL);
return 0;
}
@@ -3345,7 +3392,7 @@ flow_put_on_pmd(struct dp_netdev_pmd_thread *pmd,
netdev_flow = dp_netdev_pmd_lookup_flow(pmd, key, NULL);
if (!netdev_flow) {
if (put->flags & DPIF_FP_CREATE) {
-if (cmap_count(&pmd->flow_table) < MAX_FLOWS) {
+if (cmap_count(&pmd->flow_table) < netdev_max_flows) {
dp_netdev_flow_add(pmd, match, ufid, put->actions,
put->actions_len);
error = 0;
--
2.23.0
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH ovn v4 2/2] Add a way to delete QoS by its name or uuid
Bleep bloop. Greetings Yunxiang Tao, 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: Line lacks whitespace around operator
#28 FILE: utilities/ovn-nbctl.c:607:
ls-qos-del SWITCH [DIRECTION [PRIORITY MATCH]]\n\
WARNING: Line lacks whitespace around operator
#30 FILE: utilities/ovn-nbctl.c:609:
qos-del QOS remove QoS rules by name or UUID\n\
ERROR: Improper whitespace around control block
#84 FILE: utilities/ovn-nbctl.c:2611:
NBREC_QOS_FOR_EACH(iter, ctx->idl) {
Lines checked: 154, Warnings: 2, Errors: 1
Please check this out. If you feel there has been an error, please email
acon...@redhat.com
Thanks,
0-day Robot
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [PATCH ovn v4 1/2] Add "name" column of QoS table
Add "name" column of QoS table and make qos could be list
by command "ovn-nbctl list qos "name"".
Signed-off-by: Yunxiang Tao
---
ovn-nb.ovsschema | 3 ++-
ovn-nb.xml| 6 ++
utilities/ovn-nbctl.c | 2 ++
3 files changed, 10 insertions(+), 1 deletion(-)
diff --git a/ovn-nb.ovsschema b/ovn-nb.ovsschema
index 12999a466..02ae48e73 100644
--- a/ovn-nb.ovsschema
+++ b/ovn-nb.ovsschema
@@ -1,7 +1,7 @@
{
"name": "OVN_Northbound",
"version": "5.18.0",
-"cksum": "2806349485 24196",
+"cksum": "80177565 24240",
"tables": {
"NB_Global": {
"columns": {
@@ -204,6 +204,7 @@
"isRoot": false},
"QoS": {
"columns": {
+"name": {"type": "string"},
"priority": {"type": {"key": {"type": "integer",
"minInteger": 0,
"maxInteger": 32767}}},
diff --git a/ovn-nb.xml b/ovn-nb.xml
index 5ae52bbde..97f8eba80 100644
--- a/ovn-nb.xml
+++ b/ovn-nb.xml
@@ -1662,6 +1662,12 @@
+
+
+A name for the logical router.
+
+
+
The value of this field is similar to https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [PATCH ovn v4 2/2] Add a way to delete QoS by its name or uuid
Currently, qos can only be deleted by indirect way which must designate
switch or more parameters. This patch change the original "qos-del" to
"ls-qos-del", and add a new "qos-del" command. By the new command, you
can delete qos by uuid or name of the qos. It is very import to support
a way to delete a table by direct way. For example, we can associate
the qos table in neutron and OVN by "name" of qos in OVN, so neutron
could find and easily delete the corresponding qos in OVN.
Signed-off-by: Yunxiang Tao
---
utilities/ovn-nbctl.c | 100 --
1 file changed, 96 insertions(+), 4 deletions(-)
diff --git a/utilities/ovn-nbctl.c b/utilities/ovn-nbctl.c
index 7a0a2cc02..cdbceae07 100644
--- a/utilities/ovn-nbctl.c
+++ b/utilities/ovn-nbctl.c
@@ -604,8 +604,9 @@ ACL commands:\n\
QoS commands:\n\
qos-add SWITCH DIRECTION PRIORITY MATCH [rate=RATE [burst=BURST]]
[dscp=DSCP]\n\
add an QoS rule to SWITCH\n\
- qos-del SWITCH [DIRECTION [PRIORITY MATCH]]\n\
+ ls-qos-del SWITCH [DIRECTION [PRIORITY MATCH]]\n\
remove QoS rules from SWITCH\n\
+ qos-del QOS remove QoS rules by name or UUID\n\
qos-list SWITCH print QoS rules for SWITCH\n\
\n\
Meter commands:\n\
@@ -2496,7 +2497,7 @@ nbctl_qos_add(struct ctl_context *ctx)
}
static void
-nbctl_qos_del(struct ctl_context *ctx)
+nbctl_ls_qos_del(struct ctl_context *ctx)
{
const struct nbrec_logical_switch *ls;
char *error = ls_by_name_or_uuid(ctx, ctx->argv[1], true, &ls);
@@ -2570,6 +2571,96 @@ nbctl_qos_del(struct ctl_context *ctx)
}
}
+/* Remove qos*/
+static void
+remove_qos(const struct nbrec_logical_switch *ls, size_t idx)
+{
+
+/* First remove 'qos' from the array of qos_rules. This is what will
+ * actually cause the qos to be deleted when the transaction is
+ * sent to the database server (due to garbage collection). */
+struct nbrec_qos **new_qos_rules
+= xmemdup(ls->qos_rules, sizeof *new_qos_rules * ls->n_qos_rules);
+new_qos_rules[idx] = new_qos_rules[ls->n_qos_rules - 1];
+nbrec_logical_switch_verify_qos_rules(ls);
+nbrec_logical_switch_set_qos_rules(ls, new_qos_rules, \
+ ls->n_qos_rules - 1);
+free(new_qos_rules);
+
+/* Delete 'qos' from the IDL.This won't have a real effect on the
+ * database server (the IDL will suppress it in fact) but it means that it
+ * won't show up when we iterate with NBREC_LOGICAL_QOS_FOR_EACH later. */
+}
+
+static char * OVS_WARN_UNUSED_RESULT
+qos_by_name_or_uuid(struct ctl_context *ctx, const char *id, bool must_exist,
+ const struct nbrec_qos **qos_p)
+{
+const struct nbrec_qos *qos = NULL;
+*qos_p = NULL;
+
+struct uuid qos_uuid;
+bool is_uuid = uuid_from_string(&qos_uuid, id);
+if (is_uuid) {
+qos = nbrec_qos_get_for_uuid(ctx->idl, &qos_uuid);
+}
+
+if (!qos) {
+const struct nbrec_qos *iter;
+
+NBREC_QOS_FOR_EACH(iter, ctx->idl) {
+if (strcmp(iter->name, id)) {
+continue;
+}
+if (qos) {
+return xasprintf("Multiple qos named '%s'. "
+ "Use a UUID.", id);
+}
+qos = iter;
+}
+}
+
+if (!qos && must_exist) {
+return xasprintf("%s: qos %s not found",
+ id, is_uuid ? "UUID" : "name");
+}
+
+*qos_p = qos;
+return NULL;
+}
+
+static void
+nbctl_qos_del(struct ctl_context *ctx)
+{
+bool must_exist = !shash_find(&ctx->options, "--if-exists");
+const char *id = ctx->argv[1];
+const struct nbrec_qos *qos = NULL;
+
+char *error = qos_by_name_or_uuid(ctx, id, must_exist, &qos);
+if (error) {
+ctx->error = error;
+return;
+}
+if (!qos) {
+return;
+}
+
+/* Find the switch that contains 'qos_rules', then delete it. */
+const struct nbrec_logical_switch *ls;
+NBREC_LOGICAL_SWITCH_FOR_EACH (ls, ctx->idl) {
+for (size_t i = 0; i < ls->n_qos_rules; i++) {
+if (ls->qos_rules[i] == qos) {
+remove_qos(ls, i);
+return;
+}
+}
+}
+
+/* Can't happen because of the database schema. */
+ctl_error(ctx, "qos %s is not part of any logical switch",
+ ctx->argv[1]);
+}
+
static int
meter_cmp(const void *meter1_, const void *meter2_)
{
@@ -5658,8 +5749,9 @@ static const struct ctl_command_syntax nbctl_commands[] =
{
{ "qos-add", 5, 7,
"SWITCH DIRECTION PRIORITY MATCH [rate=RATE [burst=BURST]] [dscp=DSCP]",
NULL, nbctl_qos_add, NULL, "--may-exist", RW },
-{ "qos-del", 1, 4, "SWITCH [DIRECTION [PRIORITY MATCH]]", NULL,
- nbctl_qos_del, NULL, "", RW },
+{ "qos-del", 1, 1, "QOS", NULL, nbctl_qos_del, NULL, "--if-exists", RW },
+{ "ls-qos-del", 1, 4, "SWITCH [DIRECTIO
[ovs-dev] [PATCH ovn v4 0/2] Add a way to delete QoS directly
Currently, qos can only be deleted by indirect way which must designate switch or more parameters. The first patch add "name" column to QoS table, and make QoS table could be listed by "name" witch comand "ovn-nbctl list qos "name"". The second patch change the original "qos-del" to "ls-qos-del", add a new "qos-del" command. By the new command, you can delete qos by uuid or name of the qos. It is useful. For example, we can associate the qos table in neutron and OVN by "name" of qos in OVN, so neutron could find and easily delete the corresponding qos in OVN. Yunxiang Tao (2): Add "name" column of QoS table Add a way to delete QoS by its name or uuid ovn-nb.ovsschema | 3 +- ovn-nb.xml| 6 +++ utilities/ovn-nbctl.c | 102 -- 3 files changed, 106 insertions(+), 5 deletions(-) -- 2.17.1 ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [PATCH 1/1] tests: introduced tests for adding/deleting logical routers in VTEP database
New tests were introduced based on lcov report, which reveals apparent code is not covered by ovs test suites. Signed-off-by: Damijan Skvarc --- tests/vtep-ctl.at | 87 +++ 1 file changed, 87 insertions(+) diff --git a/tests/vtep-ctl.at b/tests/vtep-ctl.at index 3949f16..9806765 100644 --- a/tests/vtep-ctl.at +++ b/tests/vtep-ctl.at @@ -129,6 +129,39 @@ m4_define([CHECK_LSWITCHES], AT_CHECK([RUN_VTEP_CTL([ls-exists nonexistent])], [2], [], [], [VTEP_CTL_CLEANUP])]) + +dnl CHECK_LROUTERS([LROUTER], ...) +dnl +dnl Verifies that "vtep-ctl list-lr" prints the specified list of +dnl logical routers, which must be in alphabetical order. +m4_define([CHECK_LROUTERS], + [dnl Check that the lrouters appear on list-lr, without --oneline. + AT_CHECK( + [RUN_VTEP_CTL([list-lr])], + [0], + [m4_foreach([lrinfo], [$@], [m4_car(lrinfo) +])], + [], + [VTEP_CTL_CLEANUP]) + + dnl Check that the lswitches appear on list-lr, with --oneline. + AT_CHECK( + [RUN_VTEP_CTL_ONELINE([list-lr])], + [0], + [m4_join([\n], m4_foreach([lrinfo], [$@], [m4_car(lrinfo),])) +], + [], + [VTEP_CTL_CLEANUP]) + + dnl Check that each lrouter exists according to lr-exists and that + dnl a prouter that should not exist does not. + m4_foreach([lrinfo], [$@], + [AT_CHECK([RUN_VTEP_CTL([lr-exists m4_car(lrinfo)])], [0], [], +[], [VTEP_CTL_CLEANUP])]) + AT_CHECK([RUN_VTEP_CTL([lr-exists nonexistent])], [2], [], [], +[VTEP_CTL_CLEANUP])]) + + dnl -- AT_BANNER([vtep-ctl unit tests -- physical switch tests]) @@ -351,6 +384,60 @@ AT_CHECK([RUN_VTEP_CTL( VTEP_CTL_CLEANUP AT_CLEANUP + +dnl -- +AT_BANNER([vtep-ctl unit tests -- logical router tests]) + +AT_SETUP([add-lr a]) +AT_KEYWORDS([vtep-ctl]) +VTEP_CTL_SETUP +AT_CHECK([RUN_VTEP_CTL([add-lr a])], [0], [], [], [VTEP_CTL_CLEANUP]) +CHECK_LROUTERS([a]) +VTEP_CTL_CLEANUP +AT_CLEANUP + +AT_SETUP([add-lr a, add-lr a]) +AT_KEYWORDS([vtep-ctl]) +VTEP_CTL_SETUP +AT_CHECK([RUN_VTEP_CTL([add-lr a])], [0], [], [], [VTEP_CTL_CLEANUP]) +AT_CHECK([RUN_VTEP_CTL([add-lr a])], [1], [], + [vtep-ctl: cannot create logical router a because it already exists +], [VTEP_CTL_CLEANUP]) +VTEP_CTL_CLEANUP +AT_CLEANUP + +AT_SETUP([add-lr a, add-lr b]) +AT_KEYWORDS([vtep-ctl]) +VTEP_CTL_SETUP +AT_CHECK([RUN_VTEP_CTL([add-lr a], [add-lr b])], [0], [], [], + [VTEP_CTL_CLEANUP]) +CHECK_LROUTERS([a], [b]) +VTEP_CTL_CLEANUP +AT_CLEANUP + +AT_SETUP([add-lr a, add-lr b, del-lr a]) +AT_KEYWORDS([vtep-ctl]) +VTEP_CTL_SETUP +AT_CHECK([RUN_VTEP_CTL([add-lr a], [add-lr b], [del-lr a])], [0], [], [], + [VTEP_CTL_CLEANUP]) +CHECK_LROUTERS([b]) +VTEP_CTL_CLEANUP +AT_CLEANUP + +AT_SETUP([add-lr a, del-lr a, add-lr a]) +AT_KEYWORDS([vtep-ctl]) +VTEP_CTL_SETUP +AT_CHECK([RUN_VTEP_CTL_TOGETHER( + [add-lr a], + [del-lr a], + [add-lr a])], [0], [ + + +], [], [VTEP_CTL_CLEANUP]) +CHECK_LROUTERS([a]) +VTEP_CTL_CLEANUP +AT_CLEANUP + dnl -- AT_BANNER([vtep-ctl unit tests -- logical binding tests]) -- 2.7.4 ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH] afxdp: Reduce afxdp's batch size to match kernel's xdp batch size
On Sat, Dec 21, 2019 at 2:03 AM Yifeng Sun wrote: > > William reported that there is iperf TCP issue between two afxdp ports: > > [ 3] local 10.1.1.2 port 40384 connected with 10.1.1.1 port 5001 > [ ID] Interval Transfer Bandwidth > [ 3] 0.0- 1.0 sec 17.0 MBytes 143 Mbits/sec > [ 3] 1.0- 2.0 sec 9.62 MBytes 80.7 Mbits/sec > [ 3] 2.0- 3.0 sec 6.75 MBytes 56.6 Mbits/sec > [ 3] 3.0- 4.0 sec 11.0 MBytes 92.3 Mbits/sec > [ 3] 5.0- 6.0 sec 0.00 Bytes 0.00 bits/sec > [ 3] 6.0- 7.0 sec 0.00 Bytes 0.00 bits/sec > [ 3] 7.0- 8.0 sec 0.00 Bytes 0.00 bits/sec > [ 3] 8.0- 9.0 sec 0.00 Bytes 0.00 bits/sec > [ 3] 9.0-10.0 sec 0.00 Bytes 0.00 bits/sec > [ 3] 10.0-11.0 sec 0.00 Bytes 0.00 bits/sec > > The reason is, currently, netdev-afxdp's batch size is 32 while kernel's > xdp batch size is only 16. This can result in exhausting of sock wmem if > netdev-afxdp keeps sending large number of packets. Later on, when ARP > expires at one side of TCP connection, ARP packets can be delayed or > even dropped because sock wmen is already full. > > This patch fixes this issue by reducing netdev-afxdp's batch size so > as to match kernel's xdp batch size. Now iperf TCP works correctly. I didn't look at the veth driver implementation yet, but if your issue analysis is correct, driver doesn't process all the packets we're trying to send. In this case changing the batch size should not fully fix the issue since we're still could push packets fast enough to fill queues that will not be drained by kernel or some packets could stuck inside queues if we'll not send other packets. This sounds more like a missing napi rescheduling or incorrect work with need-wakeup feature inside the veth driver. I could look at it on the next week (travelling now). Anyway, we should not ultimately change batch size because it will affect performance on all modes and all drivers. Since your workaround fixes the issue at least partially, same multi-kick workaround for this case as we have for generic mode might work here too. Could you, please, check? Best regards, Ilya Maximets. ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
