From gowrishankar.m at linux.vnet.ibm.com Tue Aug 1 10:11:57 2017 From: gowrishankar.m at linux.vnet.ibm.com (gowrishankar muthukrishnan) Date: Tue, 1 Aug 2017 15:41:57 +0530 Subject: [ovs-discuss] less tcp perf with active-backup bonding mode on XL710 In-Reply-To: References: Message-ID: <43d0ab16-56ed-1444-2e0e-374a1b8e1086@linux.vnet.ibm.com> With verbose logging, i see revalidator reporting less packets with i40e in comparison with better scenario as in ixgbe. i40e: 2017-07-31T06:21:26.510Z|00759|dpif(revalidator50)|DBG|netdev at ovs-netdev: flow_dump ufid:e72fca54-e8c3-4066-a474-10eb8ca8e152 , packets:27, bytes:38018, used:0.003s, flags:P. ixgbe: 2017-07-31T05:45:17.999Z|00969|dpif(revalidator49)|DBG|netdev at ovs-netdev: flow_dump ufid:98225e69-e180-4880-aa85-0be2eff19251 , packets:1568, bytes:2371092, used:0.000s, flags:P. This is the case with tcp. Less count alarms possible delay of tcp packets reaching network stack through bonding port, hence tcp slows down overall. I don't see any difference with udp traffic between these cards though. Any pointer within ovs datapath to chase possible reasons for this delay ? To note, I also tried disabling tcp seg offload within NICs, but no difference in problem. Thanks, Gowrishankar On Thursday 27 July 2017 03:41 PM, gowrishankar muthukrishnan wrote: > Hi, > I am using XL710 NIC (2 ports) as part of OVS bonding port in > active-backup mode > in x86_64 servers. Setup is pretty simple. Two machines each with > XL710 NIC > connected each other back-to-back on these ports. Bonding is setup > through OVS > active-backup mode. After bonding port is created, I assign an IP > address on > bridge and run iperf for TCP perf comparison. > > iperf (with default params) between bonding ports shows very less > throughput of > around 1 Mbps where as in same server, when I use 82599 (ixgbe) I find > better > throughput of around 20 Mbps. I tried with dpdk poll mode driver as > well. It helps > ixgbe to get near 250 Mbps but, same poor performance I get for i40e. > > Has anyone observed this reduced throughput (with or without dpdk) in > XL710 > while in OVS active-backup bonding ?. Any pointer to find hot spot > causing > trouble (I am trying perf for the moment). > > OVS version of 2.6 as well as 2.7 tried (along with dpdk 16.11.1). > From aswinsuryan at gmail.com Tue Aug 1 18:15:35 2017 From: aswinsuryan at gmail.com (Aswin S) Date: Tue, 1 Aug 2017 23:45:35 +0530 Subject: [ovs-discuss] DPDK support for snat conntrack Message-ID: Hi, I would like to know when we can expect dpdk support for conntrack based snat. Will it be available in ovs 2.8? Thanks Aswin -------------- next part -------------- An HTML attachment was scrubbed... URL: From nakamura.tetsuro at lab.ntt.co.jp Wed Aug 2 04:49:36 2017 From: nakamura.tetsuro at lab.ntt.co.jp (TETSURO NAKAMURA) Date: Wed, 2 Aug 2017 13:49:36 +0900 Subject: [ovs-discuss] How to enable zero-copy feature of vhost-user ?? In-Reply-To: References: Message-ID: <827d030b-0f04-e0bf-53a4-192ae177857e@lab.ntt.co.jp> Hi, I heard that, about vhost-user interface, 0 copy rx is under development, but 0 copy tx from a vm is already supported with both vhost-user and ovs-dpdk. However, I couldn't find out how to enable that zero copy feature from the ovs document (/ovs/Documentation/topics/dpdk/vhost-user.rst) Could you inform me how to enable it or where I should refer about the feature ? Thanks -- Tetsuro Nakamura From aswinsuryan at gmail.com Wed Aug 2 07:03:23 2017 From: aswinsuryan at gmail.com (Aswin S) Date: Wed, 2 Aug 2017 12:33:23 +0530 Subject: [ovs-discuss] DPDK support for snat conntrack In-Reply-To: <20A5DE5F-BE1F-4AFA-8CBF-D68F7E17EEFF@vmware.com> References: <20A5DE5F-BE1F-4AFA-8CBF-D68F7E17EEFF@vmware.com> Message-ID: Thanks for the confirmation Darrell. Aswin On Tue, Aug 1, 2017 at 11:55 PM, Darrell Ball wrote: > yes > > > > *From: * on behalf of Aswin S < > aswinsuryan at gmail.com> > *Date: *Tuesday, August 1, 2017 at 11:15 AM > *To: *discuss > *Subject: *[ovs-discuss] DPDK support for snat conntrack > > > > Hi, > > > > I would like to know when we can expect dpdk support for conntrack based > snat. Will it be available in ovs 2.8? > > > > Thanks > > Aswin > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ciara.loftus at intel.com Wed Aug 2 08:04:23 2017 From: ciara.loftus at intel.com (Loftus, Ciara) Date: Wed, 2 Aug 2017 08:04:23 +0000 Subject: [ovs-discuss] How to enable zero-copy feature of vhost-user ?? In-Reply-To: <827d030b-0f04-e0bf-53a4-192ae177857e@lab.ntt.co.jp> References: <827d030b-0f04-e0bf-53a4-192ae177857e@lab.ntt.co.jp> Message-ID: <74F120C019F4A64C9B78E802F6AD4CC278DCE61B@IRSMSX106.ger.corp.intel.com> > > Hi, > > I heard that, about vhost-user interface, > 0 copy rx is under development, > but 0 copy tx from a vm is already supported with both vhost-user and > ovs-dpdk. > > However, I couldn't find out how to enable that zero copy feature from > the ovs document (/ovs/Documentation/topics/dpdk/vhost-user.rst) > > Could you inform me how to enable it or where I should refer about the > feature ? Try this: diff --git a/lib/netdev-dpdk.c b/lib/netdev-dpdk.c index ea17b97..9fdae46 100644 --- a/lib/netdev-dpdk.c +++ b/lib/netdev-dpdk.c @@ -944,6 +944,7 @@ netdev_dpdk_vhost_construct(struct netdev *netdev) dpdk_get_vhost_sock_dir(), name); dev->vhost_driver_flags &= ~RTE_VHOST_USER_CLIENT; + dev->vhost_driver_flags |= RTE_VHOST_USER_DEQUEUE_ZERO_COPY; err = rte_vhost_driver_register(dev->vhost_id, dev->vhost_driver_flags); if (err) { VLOG_ERR("vhost-user socket device setup failure for socket %s\n", Thanks, Ciara > > Thanks > > -- > Tetsuro Nakamura > > _______________________________________________ > discuss mailing list > discuss at openvswitch.org > https://mail.openvswitch.org/mailman/listinfo/ovs-discuss From nakamura.tetsuro at lab.ntt.co.jp Wed Aug 2 09:05:27 2017 From: nakamura.tetsuro at lab.ntt.co.jp (TETSURO NAKAMURA) Date: Wed, 2 Aug 2017 18:05:27 +0900 Subject: [ovs-discuss] How to enable zero-copy feature of vhost-user ?? In-Reply-To: <74F120C019F4A64C9B78E802F6AD4CC278DCE61B@IRSMSX106.ger.corp.intel.com> References: <827d030b-0f04-e0bf-53a4-192ae177857e@lab.ntt.co.jp> <74F120C019F4A64C9B78E802F6AD4CC278DCE61B@IRSMSX106.ger.corp.intel.com> Message-ID: Hi Ciara, Thank you for the infomation. IIUC, you should compile ovs again to use zero copy feature so far, right ? On 2017/08/02 17:04, Loftus, Ciara wrote: >> >> Hi, >> >> I heard that, about vhost-user interface, >> 0 copy rx is under development, >> but 0 copy tx from a vm is already supported with both vhost-user and >> ovs-dpdk. >> >> However, I couldn't find out how to enable that zero copy feature from >> the ovs document (/ovs/Documentation/topics/dpdk/vhost-user.rst) >> >> Could you inform me how to enable it or where I should refer about the >> feature ? > > Try this: > > diff --git a/lib/netdev-dpdk.c b/lib/netdev-dpdk.c > index ea17b97..9fdae46 100644 > --- a/lib/netdev-dpdk.c > +++ b/lib/netdev-dpdk.c > @@ -944,6 +944,7 @@ netdev_dpdk_vhost_construct(struct netdev *netdev) > dpdk_get_vhost_sock_dir(), name); > > dev->vhost_driver_flags &= ~RTE_VHOST_USER_CLIENT; > + dev->vhost_driver_flags |= RTE_VHOST_USER_DEQUEUE_ZERO_COPY; > err = rte_vhost_driver_register(dev->vhost_id, dev->vhost_driver_flags); > if (err) { > VLOG_ERR("vhost-user socket device setup failure for socket %s\n", > > Thanks, > Ciara > >> >> Thanks >> >> -- >> Tetsuro Nakamura >> >> _______________________________________________ >> discuss mailing list >> discuss at openvswitch.org >> https://mail.openvswitch.org/mailman/listinfo/ovs-discuss > > -- Tetsuro Nakamura NTT Network Service Systems Laboratories TEL:0422 59 6914(National)/+81 422 59 6914(International) 3-9-11, Midori-Cho Musashino-Shi, Tokyo 180-8585 Japan From ciara.loftus at intel.com Wed Aug 2 09:12:05 2017 From: ciara.loftus at intel.com (Loftus, Ciara) Date: Wed, 2 Aug 2017 09:12:05 +0000 Subject: [ovs-discuss] How to enable zero-copy feature of vhost-user ?? In-Reply-To: References: <827d030b-0f04-e0bf-53a4-192ae177857e@lab.ntt.co.jp> <74F120C019F4A64C9B78E802F6AD4CC278DCE61B@IRSMSX106.ger.corp.intel.com> Message-ID: <74F120C019F4A64C9B78E802F6AD4CC278DCE716@IRSMSX106.ger.corp.intel.com> > > Hi Ciara, > > Thank you for the infomation. > IIUC, you should compile ovs again to use zero copy feature so far, right ? Hi Tetsuro, That's right. I might look into creating a patch to enable it during runtime. But for now, you need to apply the patch below & recompile. Thanks, Ciara > > On 2017/08/02 17:04, Loftus, Ciara wrote: > >> > >> Hi, > >> > >> I heard that, about vhost-user interface, > >> 0 copy rx is under development, > >> but 0 copy tx from a vm is already supported with both vhost-user and > >> ovs-dpdk. > >> > >> However, I couldn't find out how to enable that zero copy feature from > >> the ovs document (/ovs/Documentation/topics/dpdk/vhost-user.rst) > >> > >> Could you inform me how to enable it or where I should refer about the > >> feature ? > > > > Try this: > > > > diff --git a/lib/netdev-dpdk.c b/lib/netdev-dpdk.c > > index ea17b97..9fdae46 100644 > > --- a/lib/netdev-dpdk.c > > +++ b/lib/netdev-dpdk.c > > @@ -944,6 +944,7 @@ netdev_dpdk_vhost_construct(struct netdev > *netdev) > > dpdk_get_vhost_sock_dir(), name); > > > > dev->vhost_driver_flags &= ~RTE_VHOST_USER_CLIENT; > > + dev->vhost_driver_flags |= RTE_VHOST_USER_DEQUEUE_ZERO_COPY; > > err = rte_vhost_driver_register(dev->vhost_id, dev- > >vhost_driver_flags); > > if (err) { > > VLOG_ERR("vhost-user socket device setup failure for socket %s\n", > > > > Thanks, > > Ciara > > > >> > >> Thanks > >> > >> -- > >> Tetsuro Nakamura > >> > >> _______________________________________________ > >> discuss mailing list > >> discuss at openvswitch.org > >> https://mail.openvswitch.org/mailman/listinfo/ovs-discuss > > > > > > -- > Tetsuro Nakamura > NTT Network Service Systems Laboratories > TEL:0422 59 6914(National)/+81 422 59 6914(International) > 3-9-11, Midori-Cho Musashino-Shi, Tokyo 180-8585 Japan > From vincent.mc.li at gmail.com Wed Aug 2 20:16:20 2017 From: vincent.mc.li at gmail.com (Vincent Li) Date: Wed, 2 Aug 2017 13:16:20 -0700 Subject: [ovs-discuss] Guest network interface with model type virtio defined in libvirt on openvswitch has no network connectivity Message-ID: Hi, I compiled and installed openvswitch openvswitch-2.7.1 on my ubuntu 16.04 server, I noticed I would have network connectivity problem on KVM guest with network interface model type virtio, ping between KVM guest and another physical Dell R210 server appears to be working, but tcp type of connections not working, SYN from KVM guest to Dell R210 appears to be ignored by Dell R210. tcpdump on Dell R210: root at r210:~# tcpdump -nn -i em2 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on em2, link-type EN10MB (Ethernet), capture size 65535 bytes 10:47:45.832640 IP 10.2.72.2.56286 > 10.2.72.86.9877: Flags [S], seq 3850831329, win 29200, options [mss 1460,sackOK,TS val 183908 ecr 0,nop,wscale 7], length 0 10:47:46.834635 IP 10.2.72.2.56286 > 10.2.72.86.9877: Flags [S], seq 3850831329, win 29200, options [mss 1460,sackOK,TS val 184910 ecr 0,nop,wscale 7], length 0 10:47:48.836547 IP 10.2.72.2.56286 > 10.2.72.86.9877: Flags [S], seq 3850831329, win 29200, options [mss 1460,sackOK,TS val 186912 ecr 0,nop,wscale 7], length 0 my lab as below: two servers connected with direct 10G fiber cable Dell R710: Ubuntu 16.04 + OVS 2.7.1 <----->Dell R210 Ubuntu 14.04 OVS config: root at dell710:/mnt/sdb1# ovs-vsctl show 7344de6e-8717-4a32-a883-7f6743a730fd Bridge "ovs-br2" Port "vnet3" Interface "vnet3" Port "vnet1" Interface "vnet1" <====vnet1 correlate to guest network interface Port "enp4s0f1" Interface "enp4s0f1" Port "ovs-br2" Interface "ovs-br2" type: internal Bridge "ovs-br1" Port "ovs-br1" Interface "ovs-br1" type: internal Port "enp4s0f0" Interface "enp4s0f0" root at dell710:/mnt/sdb1# ip link list 7: enp4s0f0: mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000 link/ether e8:ea:6a:06:1b:1a brd ff:ff:ff:ff:ff:ff 8: enp4s0f1: mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000 link/ether e8:ea:6a:06:1b:1b brd ff:ff:ff:ff:ff:ff 21: ovs-netdev: mtu 1500 qdisc pfifo_fast state UNKNOWN mode DEFAULT group default qlen 1000 link/ether 22:82:24:8f:73:d4 brd ff:ff:ff:ff:ff:ff 22: ovs-br2: mtu 1500 qdisc pfifo_fast state UNKNOWN mode DEFAULT group default qlen 1000 link/ether e8:ea:6a:06:1b:1b brd ff:ff:ff:ff:ff:ff 23: ovs-br1: mtu 1500 qdisc pfifo_fast state UNKNOWN mode DEFAULT group default qlen 1000 link/ether e8:ea:6a:06:1b:1a brd ff:ff:ff:ff:ff:ff 60: vnet2: mtu 1500 qdisc pfifo_fast master br0 state UNKNOWN mode DEFAULT group default qlen 1000 link/ether fe:54:00:55:47:05 brd ff:ff:ff:ff:ff:ff 61: vnet3: mtu 1500 qdisc pfifo_fast state UNKNOWN mode DEFAULT group default qlen 1000 link/ether fe:54:00:0e:6f:7c brd ff:ff:ff:ff:ff:ff 72: vnet0: mtu 1500 qdisc pfifo_fast master br0 state UNKNOWN mode DEFAULT group default qlen 1000 link/ether fe:54:00:29:c2:0e brd ff:ff:ff:ff:ff:ff 73: vnet1: mtu 1500 qdisc pfifo_fast state UNKNOWN mode DEFAULT group default qlen 1000 link/ether fe:54:00:69:86:22 brd ff:ff:ff:ff:ff:ff A test (tcp connection failed): guest libvirt network interface with defined, guest xml dump: <========= <=====has network connectivity problem with Dell R210
guest lspci: 00:04.0 Ethernet controller: Red Hat, Inc Virtio network device B test (tcp connection works): guest libvirt network interface xml without model type='virtio' defined, guest dumpxml result as below <====rtl8139 is automatically picked up, networks works fine
guest lspci: 00:04.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8100/8101L/8139 PCI Fast Ethernet Adapter (rev 20) I initially thought I need to load virtio_net driver on guest Ubuntu 14.04 qcow2 since I see no virtio_net driver loaded in guest, then I tried Centos 7 qcow2 image with virtio_net driver loaded, still have same problem. is there anything I am missing with the guest libvirt network interface model type virtio definition? Regards, Vincent -------------- next part -------------- An HTML attachment was scrubbed... URL: From vincent.mc.li at gmail.com Wed Aug 2 20:37:18 2017 From: vincent.mc.li at gmail.com (Vincent Li) Date: Wed, 2 Aug 2017 13:37:18 -0700 Subject: [ovs-discuss] Guest network interface with model type virtio defined in libvirt on openvswitch has no network connectivity In-Reply-To: References: Message-ID: > > > > I initially thought I need to load virtio_net driver on guest Ubuntu > 14.04 qcow2 since I see no virtio_net driver loaded in guest, then I tried > Centos 7 qcow2 image with virtio_net driver loaded, still have same problem. > > I just found out that Ubuntu 14.04 or 16.04 compiles virtio_net in the kernel, not as loadable module as in Centos 7, so the guest virtio_net driver should not be involved here. any more clue is appreciated! -------------- next part -------------- An HTML attachment was scrubbed... URL: From nakamura.tetsuro at lab.ntt.co.jp Thu Aug 3 00:28:39 2017 From: nakamura.tetsuro at lab.ntt.co.jp (TETSURO NAKAMURA) Date: Thu, 3 Aug 2017 09:28:39 +0900 Subject: [ovs-discuss] How to enable zero-copy feature of vhost-user ?? In-Reply-To: <74F120C019F4A64C9B78E802F6AD4CC278DCE716@IRSMSX106.ger.corp.intel.com> References: <827d030b-0f04-e0bf-53a4-192ae177857e@lab.ntt.co.jp> <74F120C019F4A64C9B78E802F6AD4CC278DCE61B@IRSMSX106.ger.corp.intel.com> <74F120C019F4A64C9B78E802F6AD4CC278DCE716@IRSMSX106.ger.corp.intel.com> Message-ID: <0594a73a-0d8f-21f9-2623-fb8329207acb@lab.ntt.co.jp> Hi Ciara, Now it's all clear. It would be great if the patch is applied. Thank you, Tetsuro On 2017/08/02 18:12, Loftus, Ciara wrote: >> >> Hi Ciara, >> >> Thank you for the infomation. >> IIUC, you should compile ovs again to use zero copy feature so far, right ? > > Hi Tetsuro, > > That's right. I might look into creating a patch to enable it during runtime. But for now, you need to apply the patch below & recompile. > > Thanks, > Ciara > >> >> On 2017/08/02 17:04, Loftus, Ciara wrote: >>>> >>>> Hi, >>>> >>>> I heard that, about vhost-user interface, >>>> 0 copy rx is under development, >>>> but 0 copy tx from a vm is already supported with both vhost-user and >>>> ovs-dpdk. >>>> >>>> However, I couldn't find out how to enable that zero copy feature from >>>> the ovs document (/ovs/Documentation/topics/dpdk/vhost-user.rst) >>>> >>>> Could you inform me how to enable it or where I should refer about the >>>> feature ? >>> >>> Try this: >>> >>> diff --git a/lib/netdev-dpdk.c b/lib/netdev-dpdk.c >>> index ea17b97..9fdae46 100644 >>> --- a/lib/netdev-dpdk.c >>> +++ b/lib/netdev-dpdk.c >>> @@ -944,6 +944,7 @@ netdev_dpdk_vhost_construct(struct netdev >> *netdev) >>> dpdk_get_vhost_sock_dir(), name); >>> >>> dev->vhost_driver_flags &= ~RTE_VHOST_USER_CLIENT; >>> + dev->vhost_driver_flags |= RTE_VHOST_USER_DEQUEUE_ZERO_COPY; >>> err = rte_vhost_driver_register(dev->vhost_id, dev- >>> vhost_driver_flags); >>> if (err) { >>> VLOG_ERR("vhost-user socket device setup failure for socket %s\n", >>> >>> Thanks, >>> Ciara >>> >>>> >>>> Thanks >>>> >>>> -- >>>> Tetsuro Nakamura >>>> >>>> _______________________________________________ >>>> discuss mailing list >>>> discuss at openvswitch.org >>>> https://mail.openvswitch.org/mailman/listinfo/ovs-discuss >>> >>> >> >> -- >> Tetsuro Nakamura >> NTT Network Service Systems Laboratories >> TEL:0422 59 6914(National)/+81 422 59 6914(International) >> 3-9-11, Midori-Cho Musashino-Shi, Tokyo 180-8585 Japan >> > -- Tetsuro Nakamura NTT Network Service Systems Laboratories TEL:0422 59 6914(National)/+81 422 59 6914(International) 3-9-11, Midori-Cho Musashino-Shi, Tokyo 180-8585 Japan From yinpeijun at huawei.com Thu Aug 3 02:04:34 2017 From: yinpeijun at huawei.com (Yinpeijun) Date: Thu, 3 Aug 2017 02:04:34 +0000 Subject: [ovs-discuss] ovs_assert when do classifier_insert Message-ID: <5A8902FEB230604AA283AF414AEB9BBD77E3A887@NKGEML515-MBX.china.huawei.com> Hi all, Recently, there's been a problem when I use ovs, the problem is ovs_assert when do classifier_insert. I read the source code and annotation, but I don't understand how the problem is been triggered. there is any idea to help me to find the trigger or how to prevent the problem, Looking forward to your reply. -------------- next part -------------- An HTML attachment was scrubbed... URL: From blp at ovn.org Thu Aug 3 02:10:41 2017 From: blp at ovn.org (Ben Pfaff) Date: Wed, 2 Aug 2017 19:10:41 -0700 Subject: [ovs-discuss] ovs_assert when do classifier_insert In-Reply-To: <5A8902FEB230604AA283AF414AEB9BBD77E3A887@NKGEML515-MBX.china.huawei.com> References: <5A8902FEB230604AA283AF414AEB9BBD77E3A887@NKGEML515-MBX.china.huawei.com> Message-ID: <20170803021041.GV6175@ovn.org> On Thu, Aug 03, 2017 at 02:04:34AM +0000, Yinpeijun wrote: > Recently, there's been a problem when I use ovs, > the problem is ovs_assert when do classifier_insert. I read the source > code and annotation, but I don't understand how the problem is been > triggered. Can you provide a backtrace? Which assertion is failing? When did this start? From yinpeijun at huawei.com Thu Aug 3 03:05:30 2017 From: yinpeijun at huawei.com (Yinpeijun) Date: Thu, 3 Aug 2017 03:05:30 +0000 Subject: [ovs-discuss] reply: ovs_assert when do classifier_insert Message-ID: <5A8902FEB230604AA283AF414AEB9BBD77E3A8E4@NKGEML515-MBX.china.huawei.com> >>On Thu, Aug 03, 2017 at 02:04:34AM +0000, Yinpeijun wrote: >> Recently, there's been a problem when I use ovs, >> the problem is ovs_assert when do classifier_insert. I read the source >> code and annotation, but I don't understand how the problem is been >> triggered. >Can you provide a backtrace? Which assertion is failing? When did this start? Thank you for your reply, Ben. I use ovs2.0.2(may be too old) and backtrace as follow: #0 0x00007f2315a98875 in raise () from /lib64/libc.so.6 #1 0x00007f2315a99e51 in abort () from /lib64/libc.so.6 #2 0x00000000004d64ff in ovs_abort_valist (err_no=0, format=0x5577e0 "%s: assertion %s failed in %s()", args=0x7ffc597e57a0) at lib/util.c:243 #3 0x00000000004dcd8a in vlog_abort_valist (module_=0x7cdae0 , message=0x5577e0 "%s: assertion %s failed in %s()", args=0x7ffc597e57a0) at lib/vlog.c:944 #4 0x00000000004dce6d in vlog_abort (module=0x7cdae0 , message=0x5577e0 "%s: assertion %s failed in %s()") at lib/vlog.c:958 #5 0x00000000004d5f50 in ovs_assert_failure (where=0x53d3c2 "lib/classifier.c:236", function=0x53d3a0 <__func__.10702> "classifier_insert", condition=0x53d3b2 "!displaced_rule") at lib/util.c:66 #6 0x0000000000457f16 in classifier_insert (cls=0xa2ff48, rule=0x7f230c603248) at lib/classifier.c:236 #7 0x000000000042cdb2 in facet_create (miss=0xb68c10) at ofproto/ofproto_dpif.c:4444 #8 0x000000000042b6de in handle_flow_miss (miss=0xb68c10, ops=0x7ffc597e5cb0, n_ops=0x7ffc597e5b18) at ofproto/ofproto_dpif.c:3826 #9 0x000000000042b9eb in handle_flow_misses (backer=0xcce850, fmb=0xb68c00) at ofproto/ofproto_dpif.c:3886 #10 0x000000000042c0a6 in handle_upcalls (backer=0xcce850) at ofproto/ofproto_dpif.c:4047 #11 0x00000000004254c8 in dpif_backer_run_fast (backer=0xcce850) at ofproto/ofproto_dpif.c:1155 #12 0x0000000000425506 in type_run_fast (type=0x7f230c52fc20 "system") at ofproto/ofproto_dpif.c:1172 #13 0x0000000000418db9 in ofproto_type_run_fast (datapath_type=0x7f230c52fc20 "system") at ofproto/ofproto.c:1462 #14 0x000000000040e0dd in bridge_run_fast () at vswitchd/bridge.c:2493 I've been using ovs2.0.2 for more than one year, it happened recently in my lab environment. And I was a little confused, there is only one thread to process the classifier insert , why need to lock it ? From blp at ovn.org Thu Aug 3 03:14:02 2017 From: blp at ovn.org (Ben Pfaff) Date: Wed, 2 Aug 2017 20:14:02 -0700 Subject: [ovs-discuss] reply: ovs_assert when do classifier_insert In-Reply-To: <5A8902FEB230604AA283AF414AEB9BBD77E3A8E4@NKGEML515-MBX.china.huawei.com> References: <5A8902FEB230604AA283AF414AEB9BBD77E3A8E4@NKGEML515-MBX.china.huawei.com> Message-ID: <20170803031402.GW6175@ovn.org> On Thu, Aug 03, 2017 at 03:05:30AM +0000, Yinpeijun wrote: > > >>On Thu, Aug 03, 2017 at 02:04:34AM +0000, Yinpeijun wrote: > >> Recently, there's been a problem when I use ovs, > >> the problem is ovs_assert when do classifier_insert. I read the source > >> code and annotation, but I don't understand how the problem is been > >> triggered. > > >Can you provide a backtrace? Which assertion is failing? When did this start? > > Thank you for your reply, Ben. > > I use ovs2.0.2(may be too old) and backtrace as follow: OK. We'll happily take a bug fix for OVS 2.0, if you come up with one, but it's too old for me to spend time tracking it down myself. I hope that you can figure out how to make it work. From aarcane at aarcane.org Thu Aug 3 05:32:48 2017 From: aarcane at aarcane.org (Schlacta, Christopher) Date: Wed, 2 Aug 2017 22:32:48 -0700 Subject: [ovs-discuss] Strange behaviour with VLANs and Bridges and ARP. Message-ID: So this is a bit hard to explain, but I hope you'll follow. I have two hosts, density and densetsu. they each host VMs and CEPH nodes using libvirt and ceph and they're connected to a smart switch using openvswitch and there are a bunch of VLANs. 5, 6, 10, 20, and 30. Most "normal" traffic goes along VLAN 10. That's just the LAN VLAN. So here's what the ovs-vsctl show looks like on each host: density: aarcane at density:~$ sudo ovs-vsctl show YubiKey for `aarcane': f2ae0266-6cae-44f0-8ca5-9d6f66562ff4 Bridge "br0" Port lan tag: 10 Interface lan type: internal Port "vnet0" trunks: [5, 6, 10, 20, 30] Interface "vnet0" Port "eth1" Interface "eth1" Port "vnet1" trunks: [5, 6, 10, 20, 30] Interface "vnet1" Port "br0" Interface "br0" type: internal ovs_version: "2.7.0" densetsu: aarcane at densetsu:~$ sudo ovs-vsctl show 2d6843ee-2bb6-48b8-a979-ba7f64bf5ebc Bridge "br0" Port "eth0" Interface "eth0" Port lan tag: 10 Interface lan type: internal Port "br0" Interface "br0" type: internal ovs_version: "2.7.0" The problem is when I try to ping the opposite machine (densetsu to density or vice versa), the ARP packets get sent with appropriate information through BR0 and out the eth device all tagged with VLAN 10, but the *inbound* arp packet is never sent to the lan interface. I see it at the br0 and the eth interface, but not the destination host's lan interface. Furthermore, the destination never seems to see this or respond to it, so it's then impossible for the to initiate contact without adding entries to the ethers file. This is well and good, but it also means that other systems on the network also cannot connect to them for purposes of administration and management, and this is very problematic. I've not made any changes to openflow. They've been able to communicate with each other for a long time. This change happened with a recent kernel upgrade. Not sure how to fix it or if it's a bug. Again, note: All IP traffic seems to work fine. ICMP works without issue, TCP, etc. It's only the ARP protocol that seems to not be passing inward when it should be. From neelugaddam at gmail.com Thu Aug 3 11:46:37 2017 From: neelugaddam at gmail.com (Neelakantam Gaddam) Date: Thu, 3 Aug 2017 17:16:37 +0530 Subject: [ovs-discuss] delete bridge issue Message-ID: Hi, I am observing a long delay in deleting a bridge which has a physical port. Issue observed when the attached port receives constant huge traffic from network. No issue when there is no traffic. The issue is seen only when the bridge is being deleted without deleting the port. When the port is deleted from the bridge initially, delete bridge completes immediately. I am using openvswitch 2.6.1 version. Any ideas on how to debug this issue is highly appreciated? -- Thanks & Regards Neelakantam Gaddam -------------- next part -------------- An HTML attachment was scrubbed... URL: From fukaige at huawei.com Thu Aug 3 11:59:02 2017 From: fukaige at huawei.com (fukaige) Date: Thu, 3 Aug 2017 11:59:02 +0000 Subject: [ovs-discuss] Why we can still see the port when failed to add it to ovs bridge Message-ID: <043DF66DA1F8854EAA5871EAC0454A582DDE7880@DGGEML503-MBX.china.huawei.com> Hi all: Recently, I met a confusing problem when using ovs-2.5.2. When a device fail to be attach to ovs bridge, I still can get the port using ?ovs-vsctl show?. As I see it, we should remove the port?s configuration in ovsdb when failed to attach it to ovs bridge. Then, we cannot get the port using ?ovs-vsctl show?. Could anyone tell me why it is not delete in ovsdb? If it is designed to do like this or we miss the step to remove the port?s configuration. Here is the log: EulerOS:~ # ovs-vsctl add-br br-test tap01 ovs-vsctl: 'add-br' command takes exactly 1 or 3 arguments EulerOS:~ # ovs-vsctl add-port br-test tap01 ovs-vsctl: Error detected while setting up 'tap01'. See ovs-vswitchd log for details. EulerOS:~ # ovs-vsctl show 4a8ab521-ded1-45c7-afb7-04005c05908e Bridge br-test Port "tap01" Interface "tap01" Port br-test Interface br-test type: internal ovs_version: "2.5.2" ovs version: 2ba45f0 odp-util: Fix generating various ct fields in odp_key_to_dp_packet() Thanks, Kaige Fu -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthias.may at neratec.com Thu Aug 3 13:58:48 2017 From: matthias.may at neratec.com (Matthias May) Date: Thu, 3 Aug 2017 15:58:48 +0200 Subject: [ovs-discuss] Why we can still see the port when failed to add it to ovs bridge In-Reply-To: <043DF66DA1F8854EAA5871EAC0454A582DDE7880@DGGEML503-MBX.china.huawei.com> References: <043DF66DA1F8854EAA5871EAC0454A582DDE7880@DGGEML503-MBX.china.huawei.com> Message-ID: <573cc223-79a7-8540-e039-ce30384700d7@neratec.com> On 03/08/17 13:59, fukaige wrote: > Hi all: > > Recently, I met a confusing problem when using ovs-2.5.2. When a device fail to be attach to ovs bridge, I still can get > the port using ?ovs-vsctl show?. > > As I see it, we should remove the port?s configuration in ovsdb when failed to attach it to ovs bridge. Then, we cannot > get the port using ?ovs-vsctl show?. > > Could anyone tell me why it is not delete in ovsdb? If it is designed to do like this or we miss the step to remove the > port?s configuration. > > > > Here is the log: > > > > EulerOS:~ # ovs-vsctl add-br br-test tap01 > > ovs-vsctl: 'add-br' command takes exactly 1 or 3 arguments > > EulerOS:~ # ovs-vsctl add-port br-test tap01 > > ovs-vsctl: Error detected while setting up 'tap01'. See ovs-vswitchd log for details. > > EulerOS:~ # ovs-vsctl show > > 4a8ab521-ded1-45c7-afb7-04005c05908e > > Bridge br-test > > Port "tap01" > > Interface "tap01" > > Port br-test > > Interface br-test > > type: internal > > ovs_version: "2.5.2" > > > > ovs version: 2ba45f0 odp-util: Fix generating various ct fields in odp_key_to_dp_packet() > > > > Thanks, > > Kaige Fu > > > > > > _______________________________________________ > discuss mailing list > discuss at openvswitch.org > https://mail.openvswitch.org/mailman/listinfo/ovs-discuss > The port could not exist yet (e.g a VM which hasn't started yet), but you may want to already configure it. When the VM then later is started and the port is created, it will be already configured and can be used immediately. BR Matthias From blp at ovn.org Thu Aug 3 18:41:06 2017 From: blp at ovn.org (Ben Pfaff) Date: Thu, 3 Aug 2017 11:41:06 -0700 Subject: [ovs-discuss] How OVN works with Openflow fast-failover group table In-Reply-To: References: Message-ID: <20170803184106.GJ6175@ovn.org> On Tue, Jul 25, 2017 at 11:17:12AM +0800, Harbor Wang wrote: > I'm learning OVN and wonder how to let OVN works with Openflow > fast-failover group table? We have a case that one port done the flow > should redirect to backup port. OVN doesn't use fast failover groups, only select groups. From xiangxia.m.yue at gmail.com Fri Aug 4 11:57:58 2017 From: xiangxia.m.yue at gmail.com (Tonghao Zhang) Date: Fri, 4 Aug 2017 19:57:58 +0800 Subject: [ovs-discuss] Fedora 25+ with OVS kernel trainted? In-Reply-To: References: Message-ID: That my be a bug in the kernel and it will be fixed. On Tue, Aug 1, 2017 at 12:01 AM, Ziemowit Pierzycki wrote: > Hi, > > I have a hypervisor with Fedora 25 on a few machines and ever since > upgrading I started getting occasional messages: > > [321428.168903] WARNING: CPU: 0 PID: 2279 at net/core/dev.c:2562 > skb_warn_bad_offload+0xc4/0x110 > [321428.168906] san0: caps=(0x000004009fbb58e9, 0x0000000000000000) > len=6769 data_len=6727 gso_size=1480 gso_type=2 ip_summed=0 > [321428.168906] Modules linked in: vhost_net vhost tap tun > ebtable_filter ebtables ip6table_filter ip6_tables nfsv3 nfs_acl nfs > lockd grace fscache fuse cfg80211 openvswitch rfkill nf_conntrack_ipv6 > nf_nat_ipv6 nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 > nf_defrag_ipv6 nf_nat nf_conntrack intel_rapl sb_edac edac_core > x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm irqbypass > crct10dif_pclmul crc32_pclmul ghash_clmulni_intel intel_cstate > iTCO_wdt ipmi_ssif iTCO_vendor_support intel_uncore mei_me ipmi_si > intel_rapl_perf raid10 joydev i2c_i801 mei lpc_ich ioatdma shpchp wmi > ipmi_devintf ipmi_msghandler acpi_power_meter acpi_pad tpm_tis > tpm_tis_core tpm auth_rpcgss sunrpc xfs libcrc32c ast i2c_algo_bit > raid1 drm_kms_helper ixgbe ttm drm crc32c_intel mdio ptp pps_core dca > [321428.168955] CPU: 0 PID: 2279 Comm: ruby-mri Tainted: G W > 4.11.12-200.fc25.x86_64 #1 > [321428.168956] Hardware name: Supermicro SYS-1028U-TNRTP+/X10DRU-i+, > BIOS 1.1 07/22/2015 > [321428.168957] Call Trace: > [321428.168962] dump_stack+0x63/0x86 > [321428.168965] __warn+0xcb/0xf0 > [321428.168966] warn_slowpath_fmt+0x5a/0x80 > [321428.168968] skb_warn_bad_offload+0xc4/0x110 > [321428.168970] __skb_gso_segment+0x190/0x1a0 > [321428.168977] queue_gso_packets+0x62/0x160 [openvswitch] > [321428.168979] ? wait_for_completion+0x39/0x180 > [321428.168982] ? stop_one_cpu+0x81/0xb0 > [321428.168984] ? sched_ttwu_pending+0xd0/0xd0 > [321428.168987] ? __skb_flow_dissect+0xcc6/0xfb0 > [321428.168989] ? __skb_get_hash+0x8f/0x300 > [321428.168992] ovs_dp_upcall+0x31/0x60 [openvswitch] > [321428.168994] ovs_dp_process_packet+0x10d/0x130 [openvswitch] > [321428.168997] ovs_vport_receive+0x76/0xd0 [openvswitch] > [321428.168999] ? wait_for_completion+0x39/0x180 > [321428.169001] ? ___slab_alloc+0x2ac/0x570 > [321428.169003] ? __alloc_skb+0x87/0x1c0 > [321428.169005] ? stop_one_cpu+0x81/0xb0 > [321428.169006] ? sched_ttwu_pending+0xd0/0xd0 > [321428.169007] ? set_next_entity+0xd9/0x220 > [321428.169009] ? __slab_alloc+0x20/0x40 > [321428.169010] ? __alloc_skb+0x9b/0x1c0 > [321428.169013] internal_dev_xmit+0x28/0x60 [openvswitch] > [321428.169014] dev_hard_start_xmit+0xa3/0x1f0 > [321428.169016] __dev_queue_xmit+0x592/0x650 > [321428.169025] ? udp_packet+0x50/0xa0 [nf_conntrack] > [321428.169026] dev_queue_xmit+0x10/0x20 > [321428.169029] ip_finish_output2+0x2a9/0x3a0 > [321428.169030] ip_finish_output+0x1c7/0x270 > [321428.169032] ? ip_finish_output+0x1c7/0x270 > [321428.169033] ip_output+0x76/0xe0 > [321428.169035] ? ip_fragment.constprop.49+0x80/0x80 > [321428.169037] ip_local_out+0x35/0x40 > [321428.169038] ip_send_skb+0x19/0x40 > [321428.169040] udp_send_skb+0x99/0x260 > [321428.169042] udp_sendmsg+0x368/0xa10 > [321428.169043] ? ip_reply_glue_bits+0x50/0x50 > [321428.169047] ? __check_object_size+0x100/0x19d > [321428.169048] inet_sendmsg+0x31/0xb0 > [321428.169050] sock_sendmsg+0x38/0x50 > [321428.169051] SYSC_sendto+0x101/0x190 > [321428.169060] ? handle_mm_fault+0xd3/0x240 > [321428.169062] ? __do_page_fault+0x266/0x4e0 > [321428.169064] SyS_sendto+0xe/0x10 > [321428.169066] entry_SYSCALL_64_fastpath+0x1a/0xa9 > [321428.169067] RIP: 0033:0x7fd138484b23 > [321428.169068] RSP: 002b:00007ffd8cabc8d0 EFLAGS: 00000293 ORIG_RAX: > 000000000000002c > [321428.169070] RAX: ffffffffffffffda RBX: 00007fd137d2bae0 RCX: > 00007fd138484b23 > [321428.169070] RDX: 0000000000001a47 RSI: 000000b0ea9c36a0 RDI: > 0000000000000007 > [321428.169071] RBP: 00007fd137d2bae0 R08: 000000b0e91370e0 R09: > 0000000000000010 > [321428.169072] R10: 0000000000000000 R11: 0000000000000293 R12: > 0000000000000020 > [321428.169072] R13: 0000000000000002 R14: 000000b0e91370d0 R15: > 0000000000000000 > [321428.169074] ---[ end trace 355a022d9ee054ce ]--- > > I noticed it's happening with Fedora 26 too. I'm using kernel > 4.11.12-200.fc25.x86_64 in this particular example. I'm using OVS > 2.5.0-4. Am I supposed to turn off GSO everywhere? I thought it was > supposed to automatic. Thanks, > > Ziemowit > _______________________________________________ > discuss mailing list > discuss at openvswitch.org > https://mail.openvswitch.org/mailman/listinfo/ovs-discuss From Alp_Arslan at DellTeam.com Fri Aug 4 15:16:08 2017 From: Alp_Arslan at DellTeam.com (Alp_Arslan at DellTeam.com) Date: Fri, 4 Aug 2017 15:16:08 +0000 Subject: [ovs-discuss] OVS-DPDK OVS port on dpdk bridge Message-ID: Hi, I was experimenting with OVS-DPDK based deployment of OpenStack (using tripleo). In the documentation that I followed they suggested to use different datapaths for control plane networks and tenant (VM) networks. For control plane networks Linux bonds were used. While experimenting I deployed the OpenStack with internal api network (a control plane network) on OVS-DPDK, to my surprise the network was working. But after testing it out I found out it was giving very poor performance, around 150 -250 Mbits/s on a 20 Gbits/s bonded network. While the networks on Linux bond were working fine. Now after reading a lot of answers on mailing list I couldn't find the answer to this question. Other than a casual mention that it's a rule of thumb to not use kernel and dpdk datapath ports on the same bridge. Also using the ethtool I found that the tagged vLAN network that I created over dpdk bridge is showing a link speed of 10 Mb/s. Can someone please explain what's happening here. [root at compute-0 ~]# ovs-ofctl show br-tenant OFPT_FEATURES_REPLY (xid=0x2): dpid:0000246e961158a2 n_tables:254, n_buffers:256 capabilities: FLOW_STATS TABLE_STATS PORT_STATS QUEUE_STATS ARP_MATCH_IP actions: output enqueue set_vlan_vid set_vlan_pcp strip_vlan mod_dl_src mod_dl_dst mod_nw_src mod_nw_dst mod_nw_tos mod_tp_src mod_tp_dst 1(dpdk0): addr:24:6e:96:11:58:a2 config: 0 state: 0 current: 10GB-FD speed: 10000 Mbps now, 0 Mbps max 2(dpdk1): addr:a0:36:9f:9b:75:12 config: 0 state: 0 current: 10GB-FD speed: 10000 Mbps now, 0 Mbps max 3(vlan140): addr:1e:06:26:db:85:8c config: 0 state: 0 current: 10MB-FD COPPER speed: 10 Mbps now, 0 Mbps max 4(phy-br-tenant): addr:7e:d6:f6:ba:60:aa config: 0 state: 0 speed: 0 Mbps now, 0 Mbps max LOCAL(br-tenant): addr:24:6e:96:11:58:a2 config: 0 state: 0 current: 10MB-FD COPPER speed: 10 Mbps now, 0 Mbps max OFPT_GET_CONFIG_REPLY (xid=0x4): frags=normal miss_send_len=0 [root at compute-0 ~]# ethtool vlan140 Settings for vlan140: Supported ports: [ ] Supported link modes: Not reported Supported pause frame use: No Supports auto-negotiation: No Advertised link modes: Not reported Advertised pause frame use: No Advertised auto-negotiation: No Speed: 10Mb/s Duplex: Full Port: Twisted Pair PHYAD: 0 Transceiver: internal Auto-negotiation: off MDI-X: Unknown Current message level: 0xffffffa1 (-95) drv ifup tx_err tx_queued intr tx_done rx_status pktdata hw wol 0xffff8000 Link detected: yes [root at compute-0 ~]# ip a 1: lo: mtu 65536 qdisc noqueue state UNKNOWN qlen 1 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: em3: mtu 1500 qdisc mq state UP qlen 1000 link/ether 24:6e:96:11:58:a4 brd ff:ff:ff:ff:ff:ff inet 192.168.120.18/24 brd 192.168.120.255 scope global em3 valid_lft forever preferred_lft forever inet6 fe80::266e:96ff:fe11:58a4/64 scope link valid_lft forever preferred_lft forever 3: em1: mtu 1500 qdisc mq master bond0 state UP qlen 1000 link/ether 24:6e:96:11:58:a0 brd ff:ff:ff:ff:ff:ff 4: em4: mtu 1500 qdisc mq state DOWN qlen 1000 link/ether 24:6e:96:11:58:a5 brd ff:ff:ff:ff:ff:ff 6: p3p1: mtu 1500 qdisc mq master bond0 state UP qlen 1000 link/ether 24:6e:96:11:58:a0 brd ff:ff:ff:ff:ff:ff 8: p2p1: mtu 1500 qdisc mq state UP qlen 1000 link/ether a0:36:9f:ac:a9:04 brd ff:ff:ff:ff:ff:ff inet6 fe80::a236:9fff:feac:a904/64 scope link valid_lft forever preferred_lft forever 9: p2p2: mtu 1500 qdisc mq state UP qlen 1000 link/ether a0:36:9f:ac:a9:06 brd ff:ff:ff:ff:ff:ff inet6 fe80::a236:9fff:feac:a906/64 scope link valid_lft forever preferred_lft forever 10: p1p1: mtu 1500 qdisc mq state UP qlen 1000 link/ether a0:36:9f:7c:1d:a4 brd ff:ff:ff:ff:ff:ff inet6 fe80::a236:9fff:fe7c:1da4/64 scope link valid_lft forever preferred_lft forever 11: p1p2: mtu 1500 qdisc mq state UP qlen 1000 link/ether a0:36:9f:7c:1d:a6 brd ff:ff:ff:ff:ff:ff inet6 fe80::a236:9fff:fe7c:1da6/64 scope link valid_lft forever preferred_lft forever 12: ovs-netdev: mtu 1500 qdisc noop state DOWN qlen 1000 link/ether 06:94:79:00:e8:af brd ff:ff:ff:ff:ff:ff 13: br-int: mtu 1500 qdisc noop state DOWN qlen 1000 link/ether 96:67:93:64:75:40 brd ff:ff:ff:ff:ff:ff 14: br-ex: mtu 1500 qdisc noop state DOWN qlen 1000 link/ether f2:54:f8:fa:26:4a brd ff:ff:ff:ff:ff:ff 15: br-tun: mtu 1500 qdisc noop state DOWN qlen 1000 link/ether a6:40:37:20:d7:45 brd ff:ff:ff:ff:ff:ff 16: vlan140: mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 1000 link/ether 1e:06:26:db:85:8c brd ff:ff:ff:ff:ff:ff inet 192.168.140.15/24 brd 192.168.140.255 scope global vlan140 valid_lft forever preferred_lft forever inet6 fe80::1c06:26ff:fedb:858c/64 scope link valid_lft forever preferred_lft forever 17: br-tenant: mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 1000 link/ether 24:6e:96:11:58:a2 brd ff:ff:ff:ff:ff:ff inet6 fe80::266e:96ff:fe11:58a2/64 scope link valid_lft forever preferred_lft forever 18: bond0: mtu 1500 qdisc noqueue state UP qlen 1000 link/ether 24:6e:96:11:58:a0 brd ff:ff:ff:ff:ff:ff inet6 fe80::266e:96ff:fe11:58a0/64 scope link valid_lft forever preferred_lft forever 19: vlan130 at bond0: mtu 1500 qdisc noqueue state UP qlen 1000 link/ether 24:6e:96:11:58:a0 brd ff:ff:ff:ff:ff:ff inet 192.168.130.15/24 brd 192.168.130.255 scope global vlan130 valid_lft forever preferred_lft forever inet6 fe80::266e:96ff:fe11:58a0/64 scope link valid_lft forever preferred_lft forever 20: vlan170 at bond0: mtu 1500 qdisc noqueue state UP qlen 1000 link/ether 24:6e:96:11:58:a0 brd ff:ff:ff:ff:ff:ff inet 192.168.170.15/24 brd 192.168.170.255 scope global vlan170 valid_lft forever preferred_lft forever inet6 fe80::266e:96ff:fe11:58a0/64 scope link valid_lft forever preferred_lft forever -------------- next part -------------- An HTML attachment was scrubbed... URL: From tredaelli at redhat.com Fri Aug 4 16:24:45 2017 From: tredaelli at redhat.com (Timothy M. Redaelli) Date: Fri, 4 Aug 2017 18:24:45 +0200 Subject: [ovs-discuss] Fedora 25+ with OVS kernel trainted? In-Reply-To: References: Message-ID: <805e79cd-13bd-127c-4081-21836a36a9a9@redhat.com> On 07/31/2017 06:01 PM, Ziemowit Pierzycki wrote: > Hi, > > I have a hypervisor with Fedora 25 on a few machines and ever since > upgrading I started getting occasional messages: [...] > I noticed it's happening with Fedora 26 too. I'm using kernel > 4.11.12-200.fc25.x86_64 in this particular example. I'm using OVS > 2.5.0-4. Am I supposed to turn off GSO everywhere? I thought it was > supposed to automatic. Thanks, Hi, you can try to disable only UFO (ethtool -i dev ufo off) since it'll be disabled in upstream kernel [1] [1]: https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/commit/?id=5c3c6081b246b05ee5bb2fc1759a7c0c6a0b7c3b From david.yangxiaoliang at huawei.com Sat Aug 5 12:34:49 2017 From: david.yangxiaoliang at huawei.com (Yangxiaoliang (Neo)) Date: Sat, 5 Aug 2017 12:34:49 +0000 Subject: [ovs-discuss] reply: ovs_assert when do classifier_insert: classifier.c:236: assertion !displaced_rule failed in classifier_insert() Message-ID: Hello Ben, I'm looking this problem with yinpeijun. Our ovs code is almost same with the latest ovs 2.0 branch. We found no patch related to this problem. We hope to get some advice from you. We are looking forward to your reply. Thanks. The calling functions are as follows: handle_flow_miss->facet_lookup_valid->facet_create->classifier_insert. There is an assert error: classifier.c:236: assertion !displaced_rule failed in classifier_insert(). ==Related functions: static void handle_flow_miss(struct flow_miss *miss, struct flow_miss_op *ops, size_t *n_ops) { struct facet *facet; miss->ofproto->n_missed += list_size(&miss->packets); facet = facet_lookup_valid(miss->ofproto, &miss->flow); if (!facet) { //**** facet is NULL, take this branch if (miss->key_fitness == ODP_FIT_TOO_LITTLE //**** miss->key_fitness=ODP_FIT_PERFECT || !flow_miss_should_make_facet(miss)) { return; } facet = facet_create(miss); //**** take this line } handle_flow_miss_with_facet(miss, facet, ops, n_ops); } static struct facet * facet_lookup_valid(struct ofproto_dpif *ofproto, const struct flow *flow) { struct facet *facet; facet = facet_find(ofproto, flow); //**** facet is found if (facet && ofproto->backer->need_revalidate && !facet_revalidate(facet)) { //**** facet_revalidate has been called. return NULL; //**** take this line } return facet; } ==In the core file, we found 2 same rules. After analyzing the ovs 2.0.2 code for a long time, we have no idea about how does this happen? //new rule (gdb) p *rule $2 = {hmap_node = {hash = 2324087362, next = 0x0}, list = {prev = 0x7f230c603258, next = 0x7f230c603258}, match = { flow = {values = 0x7f230c603270, inline_values = {2, 8, 3301985768, 1278747220, 3813303887, 0, 0, 0}, map = { 0, 1825}}, mask = {masks = {values = 0x7f230c6032a0, inline_values = {4294967295, 4294967295, 4280221696, 65535, 4294967295, 4294967295, 4294967295, 50331648}, map = {1048576, 18225}}}}, priority = 32768} //old rule (gdb) p *displaced_rule $4 = {hmap_node = {hash = 2324087362, next = 0x0}, list = {prev = 0x7f230c603258, next = 0x7f230c173d38}, match = { flow = {values = 0x7f230c173d50, inline_values = {2, 8, 3301985768, 1278747220, 3813303887, 0, 0, 0}, map = { 0, 1825}}, mask = {masks = {values = 0x7f230c173d80, inline_values = {4294967295, 4294967295, 4280221696, 65535, 4294967295, 4294967295, 4294967295, 50331648}, map = {1048576, 18225}}}}, priority = 32768} -----Original Message----- From: Yinpeijun Sent: Thursday, August 03, 2017 11:06 AM To: Ben Pfaff Cc: ovs-discuss at openvswitch.org; lixiao (H) ; gaoxiaoqiu ; Lichunhe ; Chentao (Boby) ; Yangxiaoliang (Neo) Subject: reply: [ovs-discuss] ovs_assert when do classifier_insert >>On Thu, Aug 03, 2017 at 02:04:34AM +0000, Yinpeijun wrote: >> Recently, there's been a problem when I use ovs, >>the problem is ovs_assert when do classifier_insert. I read the source >>code and annotation, but I don't understand how the problem is been >>triggered. >Can you provide a backtrace? Which assertion is failing? When did this start? Thank you for your reply, Ben. I use ovs2.0.2(may be too old) and backtrace as follow: #0 0x00007f2315a98875 in raise () from /lib64/libc.so.6 #1 0x00007f2315a99e51 in abort () from /lib64/libc.so.6 #2 0x00000000004d64ff in ovs_abort_valist (err_no=0, format=0x5577e0 "%s: assertion %s failed in %s()", args=0x7ffc597e57a0) at lib/util.c:243 #3 0x00000000004dcd8a in vlog_abort_valist (module_=0x7cdae0 , message=0x5577e0 "%s: assertion %s failed in %s()", args=0x7ffc597e57a0) at lib/vlog.c:944 #4 0x00000000004dce6d in vlog_abort (module=0x7cdae0 , message=0x5577e0 "%s: assertion %s failed in %s()") at lib/vlog.c:958 #5 0x00000000004d5f50 in ovs_assert_failure (where=0x53d3c2 "lib/classifier.c:236", function=0x53d3a0 <__func__.10702> "classifier_insert", condition=0x53d3b2 "!displaced_rule") at lib/util.c:66 #6 0x0000000000457f16 in classifier_insert (cls=0xa2ff48, rule=0x7f230c603248) at lib/classifier.c:236 #7 0x000000000042cdb2 in facet_create (miss=0xb68c10) at ofproto/ofproto_dpif.c:4444 #8 0x000000000042b6de in handle_flow_miss (miss=0xb68c10, ops=0x7ffc597e5cb0, n_ops=0x7ffc597e5b18) at ofproto/ofproto_dpif.c:3826 #9 0x000000000042b9eb in handle_flow_misses (backer=0xcce850, fmb=0xb68c00) at ofproto/ofproto_dpif.c:3886 #10 0x000000000042c0a6 in handle_upcalls (backer=0xcce850) at ofproto/ofproto_dpif.c:4047 #11 0x00000000004254c8 in dpif_backer_run_fast (backer=0xcce850) at ofproto/ofproto_dpif.c:1155 #12 0x0000000000425506 in type_run_fast (type=0x7f230c52fc20 "system") at ofproto/ofproto_dpif.c:1172 #13 0x0000000000418db9 in ofproto_type_run_fast (datapath_type=0x7f230c52fc20 "system") at ofproto/ofproto.c:1462 #14 0x000000000040e0dd in bridge_run_fast () at vswitchd/bridge.c:2493 I've been using ovs2.0.2 for more than one year, it happened recently in my lab environment. And I was a little confused, there is only one thread to process the classifier insert , why need to lock it ? From blp at ovn.org Sat Aug 5 18:04:16 2017 From: blp at ovn.org (Ben Pfaff) Date: Sat, 5 Aug 2017 11:04:16 -0700 Subject: [ovs-discuss] reply: ovs_assert when do classifier_insert: classifier.c:236: assertion !displaced_rule failed in classifier_insert() In-Reply-To: References: Message-ID: <20170805180416.GE6175@ovn.org> I'm sorry, I can't help with OVS 2.0. It is too old. I recommend upgrading. On Sat, Aug 05, 2017 at 12:34:49PM +0000, Yangxiaoliang (Neo) wrote: > Hello Ben, > > I'm looking this problem with yinpeijun. Our ovs code is almost same with the latest ovs 2.0 branch. We found no patch related to this problem. We hope to get some advice from you. We are looking forward to your reply. Thanks. > > The calling functions are as follows: handle_flow_miss->facet_lookup_valid->facet_create->classifier_insert. > There is an assert error: classifier.c:236: assertion !displaced_rule failed in classifier_insert(). > > ==Related functions: > static void > handle_flow_miss(struct flow_miss *miss, struct flow_miss_op *ops, > size_t *n_ops) > { > struct facet *facet; > > miss->ofproto->n_missed += list_size(&miss->packets); > > facet = facet_lookup_valid(miss->ofproto, &miss->flow); > if (!facet) { //**** facet is NULL, take this branch > if (miss->key_fitness == ODP_FIT_TOO_LITTLE //**** miss->key_fitness=ODP_FIT_PERFECT > || !flow_miss_should_make_facet(miss)) { > return; > } > > facet = facet_create(miss); //**** take this line > } > handle_flow_miss_with_facet(miss, facet, ops, n_ops); > } > > static struct facet * > facet_lookup_valid(struct ofproto_dpif *ofproto, const struct flow *flow) > { > struct facet *facet; > > facet = facet_find(ofproto, flow); //**** facet is found > if (facet > && ofproto->backer->need_revalidate > && !facet_revalidate(facet)) { //**** facet_revalidate has been called. > return NULL; //**** take this line > } > > return facet; > } > > ==In the core file, we found 2 same rules. After analyzing the ovs 2.0.2 code for a long time, we have no idea about how does this happen? > //new rule > (gdb) p *rule > $2 = {hmap_node = {hash = 2324087362, next = 0x0}, list = {prev = 0x7f230c603258, next = 0x7f230c603258}, match = { > flow = {values = 0x7f230c603270, inline_values = {2, 8, 3301985768, 1278747220, 3813303887, 0, 0, 0}, map = { > 0, 1825}}, mask = {masks = {values = 0x7f230c6032a0, inline_values = {4294967295, 4294967295, 4280221696, > 65535, 4294967295, 4294967295, 4294967295, 50331648}, map = {1048576, 18225}}}}, priority = 32768} > //old rule > (gdb) p *displaced_rule > $4 = {hmap_node = {hash = 2324087362, next = 0x0}, list = {prev = 0x7f230c603258, next = 0x7f230c173d38}, match = { > flow = {values = 0x7f230c173d50, inline_values = {2, 8, 3301985768, 1278747220, 3813303887, 0, 0, 0}, map = { > 0, 1825}}, mask = {masks = {values = 0x7f230c173d80, inline_values = {4294967295, 4294967295, 4280221696, > 65535, 4294967295, 4294967295, 4294967295, 50331648}, map = {1048576, 18225}}}}, priority = 32768} > > > -----Original Message----- > From: Yinpeijun > Sent: Thursday, August 03, 2017 11:06 AM > To: Ben Pfaff > Cc: ovs-discuss at openvswitch.org; lixiao (H) ; gaoxiaoqiu ; Lichunhe ; Chentao (Boby) ; Yangxiaoliang (Neo) > Subject: reply: [ovs-discuss] ovs_assert when do classifier_insert > > > >>On Thu, Aug 03, 2017 at 02:04:34AM +0000, Yinpeijun wrote: > >> Recently, there's been a problem when I use ovs, > >>the problem is ovs_assert when do classifier_insert. I read the source > >>code and annotation, but I don't understand how the problem is been > >>triggered. > > >Can you provide a backtrace? Which assertion is failing? When did this start? > > Thank you for your reply, Ben. > > I use ovs2.0.2(may be too old) and backtrace as follow: > #0 0x00007f2315a98875 in raise () from /lib64/libc.so.6 > #1 0x00007f2315a99e51 in abort () from /lib64/libc.so.6 > #2 0x00000000004d64ff in ovs_abort_valist (err_no=0, format=0x5577e0 "%s: assertion %s failed in %s()", > args=0x7ffc597e57a0) at lib/util.c:243 > #3 0x00000000004dcd8a in vlog_abort_valist (module_=0x7cdae0 , > message=0x5577e0 "%s: assertion %s failed in %s()", args=0x7ffc597e57a0) at lib/vlog.c:944 > #4 0x00000000004dce6d in vlog_abort (module=0x7cdae0 , > message=0x5577e0 "%s: assertion %s failed in %s()") at lib/vlog.c:958 > #5 0x00000000004d5f50 in ovs_assert_failure (where=0x53d3c2 "lib/classifier.c:236", > function=0x53d3a0 <__func__.10702> "classifier_insert", condition=0x53d3b2 "!displaced_rule") at lib/util.c:66 > #6 0x0000000000457f16 in classifier_insert (cls=0xa2ff48, rule=0x7f230c603248) at lib/classifier.c:236 > #7 0x000000000042cdb2 in facet_create (miss=0xb68c10) at ofproto/ofproto_dpif.c:4444 > #8 0x000000000042b6de in handle_flow_miss (miss=0xb68c10, ops=0x7ffc597e5cb0, n_ops=0x7ffc597e5b18) > at ofproto/ofproto_dpif.c:3826 > #9 0x000000000042b9eb in handle_flow_misses (backer=0xcce850, fmb=0xb68c00) at ofproto/ofproto_dpif.c:3886 > #10 0x000000000042c0a6 in handle_upcalls (backer=0xcce850) at ofproto/ofproto_dpif.c:4047 > #11 0x00000000004254c8 in dpif_backer_run_fast (backer=0xcce850) at ofproto/ofproto_dpif.c:1155 > #12 0x0000000000425506 in type_run_fast (type=0x7f230c52fc20 "system") at ofproto/ofproto_dpif.c:1172 > #13 0x0000000000418db9 in ofproto_type_run_fast (datapath_type=0x7f230c52fc20 "system") at ofproto/ofproto.c:1462 > #14 0x000000000040e0dd in bridge_run_fast () at vswitchd/bridge.c:2493 > > I've been using ovs2.0.2 for more than one year, it happened recently in my lab environment. > > And I was a little confused, there is only one thread to process the classifier insert , why need to lock it ? From paolo.narducci at ericsson.com Sun Aug 6 17:59:14 2017 From: paolo.narducci at ericsson.com (Paolo Narducci) Date: Sun, 6 Aug 2017 17:59:14 +0000 Subject: [ovs-discuss] [openvswitch 2.8.0] testsuite: 1211 1212 1213 1214 1215 1217 1218 1219 1220 1221 1222 1224 1225 1226 2338 failed Message-ID: Build environemnt : CentOS 7.3 uname -a Linux localhost.localdomain 3.10.0-514.26.2.el7.x86_64 #1 SMP Tue Jul 4 15:04:05 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux Without DPDK all test are ok. BR Paolo Narducci -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: testsuite.log Type: application/octet-stream Size: 323425 bytes Desc: testsuite.log URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: build-ovs.out.xz Type: application/octet-stream Size: 74652 bytes Desc: build-ovs.out.xz URL: From shivaram.mysore at gmail.com Mon Aug 7 18:41:27 2017 From: shivaram.mysore at gmail.com (Shivaram Mysore) Date: Mon, 7 Aug 2017 11:41:27 -0700 Subject: [ovs-discuss] TLS and SNI support Message-ID: Hello, Does OVS have plans to support SSL with SNI (Server Name Indication) [1] [1] https://wiki.openssl.org/index.php/SSL_and_TLS_Protocols#Server_Name_Indication Thanks & Regards /Shivaram -------------- next part -------------- An HTML attachment was scrubbed... URL: From batmanustc at gmail.com Tue Aug 8 02:03:19 2017 From: batmanustc at gmail.com (Sam) Date: Tue, 8 Aug 2017 10:03:19 +0800 Subject: [ovs-discuss] [ovs-tests] Questions about ovs tests Message-ID: Hi all, I'm working on ovs tests, and I want to add my test, so I have few questions: 1. what testing frame work does ovs-tests use, as I have seen lots of *.at file, lots of AT_*() macro. 2. Will ovs-tests start ovs-vswitchd or ovsdb-server when running test by `make check` command? As if no vswitchd started, how to test it? 3. Also there are *.py files, how it works? Thank you~ -------------- next part -------------- An HTML attachment was scrubbed... URL: From aarcane at aarcane.org Tue Aug 8 02:19:53 2017 From: aarcane at aarcane.org (Schlacta, Christopher) Date: Mon, 7 Aug 2017 19:19:53 -0700 Subject: [ovs-discuss] Strange behaviour with VLANs and Bridges and ARP. In-Reply-To: References: Message-ID: Ping. Anybody? Hello? On Wed, Aug 2, 2017 at 10:32 PM, Schlacta, Christopher wrote: > So this is a bit hard to explain, but I hope you'll follow. I have > two hosts, density and densetsu. they each host VMs and CEPH nodes > using libvirt and ceph and they're connected to a smart switch using > openvswitch and there are a bunch of VLANs. 5, 6, 10, 20, and 30. > Most "normal" traffic goes along VLAN 10. That's just the LAN VLAN. > So here's what the ovs-vsctl show looks like on each host: > > > density: > aarcane at density:~$ sudo ovs-vsctl show > YubiKey for `aarcane': > f2ae0266-6cae-44f0-8ca5-9d6f66562ff4 > Bridge "br0" > Port lan > tag: 10 > Interface lan > type: internal > Port "vnet0" > trunks: [5, 6, 10, 20, 30] > Interface "vnet0" > Port "eth1" > Interface "eth1" > Port "vnet1" > trunks: [5, 6, 10, 20, 30] > Interface "vnet1" > Port "br0" > Interface "br0" > type: internal > ovs_version: "2.7.0" > > > densetsu: > aarcane at densetsu:~$ sudo ovs-vsctl show > 2d6843ee-2bb6-48b8-a979-ba7f64bf5ebc > Bridge "br0" > Port "eth0" > Interface "eth0" > Port lan > tag: 10 > Interface lan > type: internal > Port "br0" > Interface "br0" > type: internal > ovs_version: "2.7.0" > > > The problem is when I try to ping the opposite machine (densetsu to > density or vice versa), the ARP packets get sent with appropriate > information through BR0 and out the eth device all tagged with VLAN > 10, but the *inbound* arp packet is never sent to the lan interface. > I see it at the br0 and the eth interface, but not the destination > host's lan interface. Furthermore, the destination never seems to see > this or respond to it, so it's then impossible for the to initiate > contact without adding entries to the ethers file. > > This is well and good, but it also means that other systems on the > network also cannot connect to them for purposes of administration and > management, and this is very problematic. > > I've not made any changes to openflow. They've been able to > communicate with each other for a long time. This change happened > with a recent kernel upgrade. Not sure how to fix it or if it's a > bug. Again, note: All IP traffic seems to work fine. ICMP works > without issue, TCP, etc. It's only the ARP protocol that seems to not > be passing inward when it should be. From batmanustc at gmail.com Tue Aug 8 02:51:14 2017 From: batmanustc at gmail.com (Sam) Date: Tue, 8 Aug 2017 10:51:14 +0800 Subject: [ovs-discuss] [ovs-tests] Questions about ovs tests In-Reply-To: References: Message-ID: For example, in tests/dpif-netdev.at file, there are OVS_VSWITCHD_START( > [add-port br0 p1 -- set interface p1 type=dummy > options:pstream=punix:$OVS_RUNDIR/p0.sock ofport_request=1 -- \ > add-port br0 p7 -- set interface p7 ofport_request=7 type=dummy -- \ > add-br br1 -- \ > set bridge br1 other-config:hwaddr=aa:66:aa:66:00:00 -- \ > set bridge br1 datapath-type=dummy other-config:datapath-id=1234 \ > fail-mode=secure -- \ > add-port br1 p2 -- set interface p2 type=dummy > options:stream=unix:$OVS_RUNDIR/p0.sock ofport_request=2 -- \ > add-port br1 p8 -- set interface p8 ofport_request=8 type=dummy --]) if no vswitchd started, `add-port` will failed. 2017-08-08 10:03 GMT+08:00 Sam : > Hi all, > > I'm working on ovs tests, and I want to add my test, so I have few > questions: > > 1. what testing frame work does ovs-tests use, as I have seen lots of *.at > file, lots of AT_*() macro. > > 2. Will ovs-tests start ovs-vswitchd or ovsdb-server when running test by > `make check` command? As if no vswitchd started, how to test it? > > 3. Also there are *.py files, how it works? > > Thank you~ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From james.page at ubuntu.com Tue Aug 8 09:49:10 2017 From: james.page at ubuntu.com (James Page) Date: Tue, 08 Aug 2017 09:49:10 +0000 Subject: [ovs-discuss] [openvswitch 2.8.0 dpdk] testsuite: 1211 1212 1213 1214 1215 1217 1218 1219 1220 1221 1222 1224 1225 1226 2338 failed Message-ID: Hi I'm cutting builds from branch-2.8 in preparation for the ovs 2.8.0 release for Ubuntu; we build and test two sets of binaries - a vanilla one and one with dpdk enabled. I see test failures on all of the "ofproto-dpif - conntrack" tests with the DPDK build and with the ovn ACL test (see attached logs). Vanilla build is fine. Also tracking this in Ubuntu under [0]. Cheers James [0] https://bugs.launchpad.net/ubuntu/+source/openvswitch/+bug/1709272 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: testsuite.log Type: text/x-log Size: 274334 bytes Desc: not available URL: From Alp_Arslan at DellTeam.com Tue Aug 8 11:42:48 2017 From: Alp_Arslan at DellTeam.com (Alp_Arslan at DellTeam.com) Date: Tue, 8 Aug 2017 11:42:48 +0000 Subject: [ovs-discuss] OVS-DPDK OVS port on dpdk bridge In-Reply-To: References: Message-ID: <45cc607ba23845b1a7b26f780d9711cc@AUSX13MPS328.AMER.DELL.COM> Anyone who can help me with this, or can point to a more relevant forum. From: ovs-discuss-bounces at openvswitch.org [mailto:ovs-discuss-bounces at openvswitch.org] On Behalf Of Arslan, Alp - Dell Team Sent: Friday, August 4, 2017 8:16 PM To: ovs-discuss at openvswitch.org Subject: [ovs-discuss] OVS-DPDK OVS port on dpdk bridge Hi, I was experimenting with OVS-DPDK based deployment of OpenStack (using tripleo). In the documentation that I followed they suggested to use different datapaths for control plane networks and tenant (VM) networks. For control plane networks Linux bonds were used. While experimenting I deployed the OpenStack with internal api network (a control plane network) on OVS-DPDK, to my surprise the network was working. But after testing it out I found out it was giving very poor performance, around 150 -250 Mbits/s on a 20 Gbits/s bonded network. While the networks on Linux bond were working fine. Now after reading a lot of answers on mailing list I couldn't find the answer to this question. Other than a casual mention that it's a rule of thumb to not use kernel and dpdk datapath ports on the same bridge. Also using the ethtool I found that the tagged vLAN network that I created over dpdk bridge is showing a link speed of 10 Mb/s. Can someone please explain what's happening here. [root at compute-0 ~]# ovs-ofctl show br-tenant OFPT_FEATURES_REPLY (xid=0x2): dpid:0000246e961158a2 n_tables:254, n_buffers:256 capabilities: FLOW_STATS TABLE_STATS PORT_STATS QUEUE_STATS ARP_MATCH_IP actions: output enqueue set_vlan_vid set_vlan_pcp strip_vlan mod_dl_src mod_dl_dst mod_nw_src mod_nw_dst mod_nw_tos mod_tp_src mod_tp_dst 1(dpdk0): addr:24:6e:96:11:58:a2 config: 0 state: 0 current: 10GB-FD speed: 10000 Mbps now, 0 Mbps max 2(dpdk1): addr:a0:36:9f:9b:75:12 config: 0 state: 0 current: 10GB-FD speed: 10000 Mbps now, 0 Mbps max 3(vlan140): addr:1e:06:26:db:85:8c config: 0 state: 0 current: 10MB-FD COPPER speed: 10 Mbps now, 0 Mbps max 4(phy-br-tenant): addr:7e:d6:f6:ba:60:aa config: 0 state: 0 speed: 0 Mbps now, 0 Mbps max LOCAL(br-tenant): addr:24:6e:96:11:58:a2 config: 0 state: 0 current: 10MB-FD COPPER speed: 10 Mbps now, 0 Mbps max OFPT_GET_CONFIG_REPLY (xid=0x4): frags=normal miss_send_len=0 [root at compute-0 ~]# ethtool vlan140 Settings for vlan140: Supported ports: [ ] Supported link modes: Not reported Supported pause frame use: No Supports auto-negotiation: No Advertised link modes: Not reported Advertised pause frame use: No Advertised auto-negotiation: No Speed: 10Mb/s Duplex: Full Port: Twisted Pair PHYAD: 0 Transceiver: internal Auto-negotiation: off MDI-X: Unknown Current message level: 0xffffffa1 (-95) drv ifup tx_err tx_queued intr tx_done rx_status pktdata hw wol 0xffff8000 Link detected: yes [root at compute-0 ~]# ip a 1: lo: mtu 65536 qdisc noqueue state UNKNOWN qlen 1 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: em3: mtu 1500 qdisc mq state UP qlen 1000 link/ether 24:6e:96:11:58:a4 brd ff:ff:ff:ff:ff:ff inet 192.168.120.18/24 brd 192.168.120.255 scope global em3 valid_lft forever preferred_lft forever inet6 fe80::266e:96ff:fe11:58a4/64 scope link valid_lft forever preferred_lft forever 3: em1: mtu 1500 qdisc mq master bond0 state UP qlen 1000 link/ether 24:6e:96:11:58:a0 brd ff:ff:ff:ff:ff:ff 4: em4: mtu 1500 qdisc mq state DOWN qlen 1000 link/ether 24:6e:96:11:58:a5 brd ff:ff:ff:ff:ff:ff 6: p3p1: mtu 1500 qdisc mq master bond0 state UP qlen 1000 link/ether 24:6e:96:11:58:a0 brd ff:ff:ff:ff:ff:ff 8: p2p1: mtu 1500 qdisc mq state UP qlen 1000 link/ether a0:36:9f:ac:a9:04 brd ff:ff:ff:ff:ff:ff inet6 fe80::a236:9fff:feac:a904/64 scope link valid_lft forever preferred_lft forever 9: p2p2: mtu 1500 qdisc mq state UP qlen 1000 link/ether a0:36:9f:ac:a9:06 brd ff:ff:ff:ff:ff:ff inet6 fe80::a236:9fff:feac:a906/64 scope link valid_lft forever preferred_lft forever 10: p1p1: mtu 1500 qdisc mq state UP qlen 1000 link/ether a0:36:9f:7c:1d:a4 brd ff:ff:ff:ff:ff:ff inet6 fe80::a236:9fff:fe7c:1da4/64 scope link valid_lft forever preferred_lft forever 11: p1p2: mtu 1500 qdisc mq state UP qlen 1000 link/ether a0:36:9f:7c:1d:a6 brd ff:ff:ff:ff:ff:ff inet6 fe80::a236:9fff:fe7c:1da6/64 scope link valid_lft forever preferred_lft forever 12: ovs-netdev: mtu 1500 qdisc noop state DOWN qlen 1000 link/ether 06:94:79:00:e8:af brd ff:ff:ff:ff:ff:ff 13: br-int: mtu 1500 qdisc noop state DOWN qlen 1000 link/ether 96:67:93:64:75:40 brd ff:ff:ff:ff:ff:ff 14: br-ex: mtu 1500 qdisc noop state DOWN qlen 1000 link/ether f2:54:f8:fa:26:4a brd ff:ff:ff:ff:ff:ff 15: br-tun: mtu 1500 qdisc noop state DOWN qlen 1000 link/ether a6:40:37:20:d7:45 brd ff:ff:ff:ff:ff:ff 16: vlan140: mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 1000 link/ether 1e:06:26:db:85:8c brd ff:ff:ff:ff:ff:ff inet 192.168.140.15/24 brd 192.168.140.255 scope global vlan140 valid_lft forever preferred_lft forever inet6 fe80::1c06:26ff:fedb:858c/64 scope link valid_lft forever preferred_lft forever 17: br-tenant: mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 1000 link/ether 24:6e:96:11:58:a2 brd ff:ff:ff:ff:ff:ff inet6 fe80::266e:96ff:fe11:58a2/64 scope link valid_lft forever preferred_lft forever 18: bond0: mtu 1500 qdisc noqueue state UP qlen 1000 link/ether 24:6e:96:11:58:a0 brd ff:ff:ff:ff:ff:ff inet6 fe80::266e:96ff:fe11:58a0/64 scope link valid_lft forever preferred_lft forever 19: vlan130 at bond0: mtu 1500 qdisc noqueue state UP qlen 1000 link/ether 24:6e:96:11:58:a0 brd ff:ff:ff:ff:ff:ff inet 192.168.130.15/24 brd 192.168.130.255 scope global vlan130 valid_lft forever preferred_lft forever inet6 fe80::266e:96ff:fe11:58a0/64 scope link valid_lft forever preferred_lft forever 20: vlan170 at bond0: mtu 1500 qdisc noqueue state UP qlen 1000 link/ether 24:6e:96:11:58:a0 brd ff:ff:ff:ff:ff:ff inet 192.168.170.15/24 brd 192.168.170.255 scope global vlan170 valid_lft forever preferred_lft forever inet6 fe80::266e:96ff:fe11:58a0/64 scope link valid_lft forever preferred_lft forever -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthias.may at neratec.com Tue Aug 8 13:00:01 2017 From: matthias.may at neratec.com (Matthias May) Date: Tue, 8 Aug 2017 15:00:01 +0200 Subject: [ovs-discuss] RSTP: ARP frames not flooded to internal interfaces when RSTP is enabled before virtual interfaces are created Message-ID: Hi I'm observing some strange behaviour when configuring RSTP in combination with internal interfaces other than the br interface itself. I have 3 interfaces (eth0, 1, 2) eth1 and eth2 are used with other devices to form a ring (hence rstp is in use). Since eth1 and eth2 are connected to a hardware switch which offloads unicast forwarding they have the protected flag set to prevent duplication of broadcast/multicast frames. eth0 is not connected. I use the following commands to configure the bridge: ovs-vsctl add-br br0 ovs-vsctl -- set bridge br0 other-config:hwaddr=00:14:5a:03:52:05 ovs-vsctl -- set Bridge br0 other_config:rstp-priority=32768 ovs-vsctl -- set Bridge br0 other_config:rstp-forward-delay=15 ovs-vsctl -- set Bridge br0 other_config:rstp-max-age=20 ovs-vsctl -- set Bridge br0 other_config:rstp-transmit-hold-count=6 ovs-vsctl -- set Bridge br0 rstp_enable=true ip l s br0 down ovs-vsctl add-port br0 eth0 ovs-vsctl -- set port eth0 trunks=[] ovs-vsctl -- set port eth0 tag=[] ovs-vsctl -- set port eth0 vlan_mode=trunk ovs-vsctl -- set port eth0 protected=false ovs-vsctl -- set Interface eth0 ofport_request=100 ovs-vsctl -- set Port eth0 other_config:rstp-port-priority=128 ovs-vsctl -- set Port eth0 other_config:rstp-port-auto-edge=true ovs-vsctl -- remove Port eth0 other_config rstp-path-cost ovs-vsctl -- set Port eth0 other_config:rstp-enable=true ip l s eth0 up ovs-vsctl add-port br0 eth1 ovs-vsctl -- set port eth1 trunks=[] ovs-vsctl -- set port eth1 tag=[] ovs-vsctl -- set port eth1 vlan_mode=trunk ovs-vsctl -- set port eth1 protected=true ovs-vsctl -- set Interface eth1 ofport_request=101 ovs-vsctl -- set Port eth1 other_config:rstp-port-priority=128 ovs-vsctl -- set Port eth1 other_config:rstp-port-auto-edge=false ovs-vsctl -- remove Port eth1 other_config rstp-path-cost ovs-vsctl -- set Port eth1 other_config:rstp-enable=true ip l s eth1 up ovs-vsctl add-port br0 eth2 ovs-vsctl -- set port eth2 trunks=[] ovs-vsctl -- set port eth2 tag=[] ovs-vsctl -- set port eth2 vlan_mode=trunk ovs-vsctl -- set port eth2 protected=true ovs-vsctl -- set Interface eth2 ofport_request=102 ovs-vsctl -- set Port eth2 other_config:rstp-port-priority=128 ovs-vsctl -- set Port eth2 other_config:rstp-port-auto-edge=false ovs-vsctl -- remove Port eth2 other_config rstp-path-cost ovs-vsctl -- set Port eth2 other_config:rstp-enable=true ip l s eth2 up ovs-vsctl add-port br0 br0.vlan0 ovs-vsctl -- set interface br0.vlan0 type=internal ovs-vsctl -- set port br0.vlan0 tag=0 ovs-vsctl -- set interface br0.vlan0 "mac=\"00:14:5a:03:52:05\"" ip l s br0.vlan0 up ip a a 192.168.1.20/24 brd + dev br0.vlan0 RSTP is enabled directly when creating the bridge to prevent a look before the interfaces are added to the bridge. Resulting in: root at RM4:~# ovs-dpctl show system at ovs-system: lookups: hit:190 missed:84 lost: flows: 5 masks: hit:268 total:3 hit/pkt:0.98 port 0: ovs-system (internal) port 1: br0 (internal) port 2: eth0 port 3: eth1 port 4: eth2 port 5: br0.vlan0 (internal: open failed (File exists)) Notice that br0 is down and the IP is on br0.vlan0. Now if I try to ping 192.168.1.20 ARP requests are not answered. and I see in the datapath dump: root at RM4:~# ovs-dpctl dump-flows recirc_id(0),in_port(4),eth(dst=01:80:c2:00:00:00),eth_type(0/0xffff), packets:46, bytes:2760, used:1.417s, actions:userspace(pid=4192251794,slow_path(stp)) recirc_id(0),in_port(3),eth(src=e8:39:35:34:d4:60,dst=ff:ff:ff:ff:ff:ff),eth_type(0x0806),arp(sip=192.168.1.2,tip=192.168.1.20,op=1/0xff), packets:70, bytes:4200, used:0.633s, actions:1 recirc_id(0),in_port(3),eth(src=00:14:5a:09:15:7c,dst=ff:ff:ff:ff:ff:ff),eth_type(0x0800),ipv4(frag=no), packets:31, bytes:10602, used:0.225s, actions:1 recirc_id(0),in_port(3),eth(dst=01:80:c2:00:00:00),eth_type(0/0xffff), packets:47, bytes:2820, used:0.069s, actions:userspace(pid=4192251794,slow_path(stp)) For some reason the ARP frames are not flooded to all ports as they should but only to port 1. As a workaround I moved ovs-vsctl -- set Bridge br0 rstp_enable=true to the end and is executed after br0.vlan0 is created. With this everything works as expected. However this allows for a short window where the interfaces are already in the bridge but RSTP is not enabled yet. --> commands: ovs-vsctl add-br br0 ovs-vsctl -- set bridge br0 other-config:hwaddr=00:14:5a:03:52:05 ovs-vsctl -- set Bridge br0 other_config:rstp-priority=32768 ovs-vsctl -- set Bridge br0 other_config:rstp-forward-delay=15 ovs-vsctl -- set Bridge br0 other_config:rstp-max-age=20 ovs-vsctl -- set Bridge br0 other_config:rstp-transmit-hold-count=6 ip l s br0 down ovs-vsctl add-port br0 eth0 ovs-vsctl -- set port eth0 trunks=[] ovs-vsctl -- set port eth0 tag=[] ovs-vsctl -- set port eth0 vlan_mode=trunk ovs-vsctl -- set port eth0 protected=false ovs-vsctl -- set Interface eth0 ofport_request=100 ovs-vsctl -- set Port eth0 other_config:rstp-port-priority=128 ovs-vsctl -- set Port eth0 other_config:rstp-port-auto-edge=true ovs-vsctl -- remove Port eth0 other_config rstp-path-cost ovs-vsctl -- set Port eth0 other_config:rstp-enable=true ip l s eth0 up ovs-vsctl add-port br0 eth1 ovs-vsctl -- set port eth1 trunks=[] ovs-vsctl -- set port eth1 tag=[] ovs-vsctl -- set port eth1 vlan_mode=trunk ovs-vsctl -- set port eth1 protected=true ovs-vsctl -- set Interface eth1 ofport_request=101 ovs-vsctl -- set Port eth1 other_config:rstp-port-priority=128 ovs-vsctl -- set Port eth1 other_config:rstp-port-auto-edge=false ovs-vsctl -- remove Port eth1 other_config rstp-path-cost ovs-vsctl -- set Port eth1 other_config:rstp-enable=true ip l s eth1 up ovs-vsctl add-port br0 eth2 ovs-vsctl -- set port eth2 trunks=[] ovs-vsctl -- set port eth2 tag=[] ovs-vsctl -- set port eth2 vlan_mode=trunk ovs-vsctl -- set port eth2 protected=true ovs-vsctl -- set Interface eth2 ofport_request=102 ovs-vsctl -- set Port eth2 other_config:rstp-port-priority=128 ovs-vsctl -- set Port eth2 other_config:rstp-port-auto-edge=false ovs-vsctl -- remove Port eth2 other_config rstp-path-cost ovs-vsctl -- set Port eth2 other_config:rstp-enable=true ip l s eth2 up ovs-vsctl add-port br0 br0.vlan0 ovs-vsctl -- set interface br0.vlan0 type=internal ovs-vsctl -- set port br0.vlan0 tag=0 ovs-vsctl -- set interface br0.vlan0 "mac=\"00:14:5a:03:52:05\"" ip l s br0.vlan0 up ip a a 192.168.1.20/24 brd + dev br0.vlan0 ovs-vsctl -- set Bridge br0 rstp_enable=true !Notice that rstp_enable=true is set at the end. This results again in: root at RM4:~# ovs-dpctl show system at ovs-system: lookups: hit:32 missed:183 lost:0 flows: 0 masks: hit:211 total:0 hit/pkt:0.98 port 0: ovs-system (internal) port 1: br0 (internal) port 2: eth0 port 3: eth1 port 4: eth2 port 5: br0.vlan0 (internal: open failed (File exists)) However the flow dump shows: root at RM4:~# ovs-dpctl dump-flows recirc_id(0),in_port(3),eth(src=e8:39:35:34:d4:60,dst=00:14:5a:03:52:05),eth_type(0x0800),ipv4(frag=no), packets:2, bytes:196, used:0.940s, actions:5 recirc_id(0),in_port(3),eth(src=00:14:5a:09:15:7c,dst=ff:ff:ff:ff:ff:ff),eth_type(0x0800),ipv4(frag=no), packets:0, bytes:0, used:never, actions:1,5 recirc_id(0),in_port(3),eth(dst=01:80:c2:00:00:00),eth_type(0/0xffff), packets:1, bytes:60, used:1.273s, actions:userspace(pid=3595029779,slow_path(stp)) recirc_id(0),in_port(4),eth(dst=01:80:c2:00:00:00),eth_type(0/0xffff), packets:1, bytes:60, used:1.353s, actions:userspace(pid=3595029779,slow_path(stp)) recirc_id(0),in_port(5),eth(src=00:14:5a:03:52:05,dst=e8:39:35:34:d4:60),eth_type(0x0800),ipv4(frag=no), packets:2, bytes:196, used:0.941s, actions:3 recirc_id(0),in_port(3),eth(src=e8:39:35:34:d4:60,dst=ff:ff:ff:ff:ff:ff),eth_type(0x0806),arp(sip=192.168.1.2,tip=192.168.1.99,op=1/0xff), packets:2, bytes:120, used:0.205s, actions:1,5 The ping to 192.168.1.20 works as expected. I've run a ping to 192.168.1.99 which doesn't exist to see the flow which floods the ARP frame to all virtual ports (1,5) and not only port 1 (br0). Does anyone have any insight as why this happens? What can I do to help debug this? BR Matthias From ankaiah.nallamekala at wipro.com Tue Aug 8 14:07:25 2017 From: ankaiah.nallamekala at wipro.com (ankaiah.nallamekala at wipro.com) Date: Tue, 8 Aug 2017 14:07:25 +0000 Subject: [ovs-discuss] Regarding CFM/OAM support in Openvswitch Message-ID: Hi All, I am trying to test CFM Link monitoring in the openvswitch. My Test Setup is given Below: (port P1) -----------(port2) Linux bridge(port p3) ---------------(port p4) P1 - Linux server 1 with ovs P2 & P3 - Linux server 2 and normal linux bridge P4 - Linux server 3 with ovs [cid:image001.png at 01D3107D.C23EFA60] Configured CFM in the linux_machine_1 and Linux_machine_3 using the below command : Linux_server1 : ovs-vsctl set Interface eth0 cfm_mpid=4000 Linux_server3 : ovs-vsctl set Interface eth0 cfm_mpid=5000 When I shut one of the bridge interface in Linux server 2, I am able to see the fault notification like below 2017-08-08T11:08:53.904Z|00003|cfm(monitor19)|INFO|enp4s0f2: CFM faults changed from [] to [recv]. This fault detection was done using CCM(continuity Check message) protocol. Ethernet CFM/OAM supports Loopback protocol(LBM) and Link Trace protocol(LTM), Is ovs is supporting these two protocols as well, if so could you please describe how to use these two protocols. I am using ovs 2.5 version. Thanks, Anki The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 12121 bytes Desc: image001.png URL: From dball at vmware.com Tue Aug 8 16:26:38 2017 From: dball at vmware.com (Darrell Ball) Date: Tue, 8 Aug 2017 16:26:38 +0000 Subject: [ovs-discuss] [openvswitch 2.8.0 dpdk] testsuite: 1211 1212 1213 1214 1215 1217 1218 1219 1220 1221 1222 1224 1225 1226 2338 failed In-Reply-To: References: Message-ID: <328530F9-3E9F-43F5-81C4-E35052A9B54F@vmware.com> From: on behalf of James Page Date: Tuesday, August 8, 2017 at 2:49 AM To: "bugs at openvswitch.org" Subject: [ovs-discuss] [openvswitch 2.8.0 dpdk] testsuite: 1211 1212 1213 1214 1215 1217 1218 1219 1220 1221 1222 1224 1225 1226 2338 failed Hi I'm cutting builds from branch-2.8 in preparation for the ovs 2.8.0 release for Ubuntu; we build and test two sets of binaries - a vanilla one and one with dpdk enabled. I see test failures on all of the "ofproto-dpif - conntrack" tests with the DPDK build and with the ovn ACL test (see attached logs). Vanilla build is fine. James These are generic tests and should not be run with-dpdk set. If you run these tests --with-dpdk, some tests will consider the packets coming an actual dpdk interface, which they are not. In this case, the packets will be marked with a bad checksum. Are you able to run these tests as we do without ??with-dpdk? ? Thanks Darrell Also tracking this in Ubuntu under [0]. Cheers James [0] https://bugs.launchpad.net/ubuntu/+source/openvswitch/+bug/1709272 -------------- next part -------------- An HTML attachment was scrubbed... URL: From blp at ovn.org Tue Aug 8 16:56:08 2017 From: blp at ovn.org (Ben Pfaff) Date: Tue, 8 Aug 2017 09:56:08 -0700 Subject: [ovs-discuss] Regarding CFM/OAM support in Openvswitch In-Reply-To: References: Message-ID: <20170808165608.GZ6175@ovn.org> On Tue, Aug 08, 2017 at 02:07:25PM +0000, ankaiah.nallamekala at wipro.com wrote: > Ethernet CFM/OAM supports Loopback protocol(LBM) and Link Trace > protocol(LTM), Is ovs is supporting these two protocols as well, if so > could you please describe how to use these two protocols. OVS doesn't support those. From blp at ovn.org Tue Aug 8 20:18:47 2017 From: blp at ovn.org (Ben Pfaff) Date: Tue, 8 Aug 2017 13:18:47 -0700 Subject: [ovs-discuss] How does OVS ensure only the first packet of a flow is upcalled? In-Reply-To: <85062f1.6ab0.15d4029d2fc.Coremail.keyaozhang@126.com> References: <85062f1.6ab0.15d4029d2fc.Coremail.keyaozhang@126.com> Message-ID: <20170808201847.GL6175@ovn.org> On Fri, Jul 14, 2017 at 04:14:29PM +0800, ??? wrote: > The document of ovs says the datapath is a flow-based software > switch. A flow consists of many packets. Datapath needs to handle > every packet. When it does't match any datapath flows, it will do > upcall. Vswitchd needs to handle upcalls and send netlink messages to > datapath to install the datapath flows. But before the datapath flows > are added, another packet of the same flow arrived, will the packet be > upcalled? That means if I send packets at faster rate, more upcalls > will be expected? Yes, more than one packet in a flow can go through an upcall. It's unusual, though, because most flows start out with a single packet and do not continue until they receive a response. From blp at ovn.org Tue Aug 8 21:58:21 2017 From: blp at ovn.org (Ben Pfaff) Date: Tue, 8 Aug 2017 14:58:21 -0700 Subject: [ovs-discuss] Lost connectivity when having multiple ports In-Reply-To: <08a79dda-8699-18e4-6069-cae82bf8f5a8@gti.uvigo.es> References: <08a79dda-8699-18e4-6069-cae82bf8f5a8@gti.uvigo.es> Message-ID: <20170808215821.GT6175@ovn.org> On Mon, Jul 24, 2017 at 01:04:34PM +0200, Pablo Pousada wrote: > I've been encountering an error on the testbed I'm building, where having > multiple ports added to a ovs bridge blocks all outwards communication. > > Example: Having the following setup, i have connectivity through the eth0.3 > port: > > root at LEDE:~# ovs-vsctl show > 41ae4f8f-55db-4cd0-8dd1-3e7b001d8f54 > Bridge "br0" > Controller "tcp:192.168.1.151" > Port "br0" > Interface "br0" > type: internal > Port "eth0.3" > Interface "eth0.3" > > Whenever I add another port to that bridge, inward packages are received, > but outward packages are never sent. The problem persists with or without > controller. > > ?Does anyone have any info on where the problem might be? > > I'm using Open vSwitch version 2.5.0 over LEDE. This sounds like the second question here: http://docs.openvswitch.org/en/latest/faq/issues/ From joe at ovn.org Tue Aug 8 22:43:39 2017 From: joe at ovn.org (Joe Stringer) Date: Tue, 8 Aug 2017 15:43:39 -0700 Subject: [ovs-discuss] [openvswitch 2.8.0 dpdk] testsuite: 1211 1212 1213 1214 1215 1217 1218 1219 1220 1221 1222 1224 1225 1226 2338 failed In-Reply-To: <328530F9-3E9F-43F5-81C4-E35052A9B54F@vmware.com> References: <328530F9-3E9F-43F5-81C4-E35052A9B54F@vmware.com> Message-ID: On 8 August 2017 at 09:26, Darrell Ball wrote: > > > > > From: on behalf of James Page > > Date: Tuesday, August 8, 2017 at 2:49 AM > To: "bugs at openvswitch.org" > Subject: [ovs-discuss] [openvswitch 2.8.0 dpdk] testsuite: 1211 1212 1213 > 1214 1215 1217 1218 1219 1220 1221 1222 1224 1225 1226 2338 failed > > > > Hi > > > > I'm cutting builds from branch-2.8 in preparation for the ovs 2.8.0 release > for Ubuntu; we build and test two sets of binaries - a vanilla one and one > with dpdk enabled. > > > > I see test failures on all of the "ofproto-dpif - conntrack" tests with the > DPDK build and with the ovn ACL test (see attached logs). Vanilla build is > fine. > > > > James > > > > These are generic tests and should not be run with-dpdk set. > > If you run these tests --with-dpdk, some tests will consider the packets > coming an actual dpdk interface, which they are not. > > In this case, the packets will be marked with a bad checksum. > > > > Are you able to run these tests as we do without ??with-dpdk? ? Hmm, this seems surprising to me - I thought that "--with-dpdk" mostly just enables another netdevice implementation. Why would this affect input/output with netdev-dummy devices? For what it's worth, I tried a run of the testsuite with OVS built "--with-dpdk" on branch-2.7 and it worked fine: https://travis-ci.org/joestringer/openvswitch/jobs/262439494 The test failures for the first few are hard-failures (ie ovs uses WAIT_UNTIL for something that never succeeds), examples below where OVS was waiting to receive packets that never arrive: ../../tests/ofproto-dpif.at:9016: ovs-appctl netdev-dummy/receive p2 'in_port(2),eth(src=50:54:00:00:00:0a,dst=50:54:00:00:00:09),eth_type(0x0800),ipv4(src=10.1.1.2,dst=10.1.1.1,proto=17,tos=0,ttl=64,frag=no),udp(src=2,dst=1)' ../../tests/ofproto-dpif.at:9018: hard failure --- Some of the later failures are a bit more interesting: ../../tests/ofproto-dpif.at:9161: ovs-appctl netdev-dummy/receive p2 'in_port(2),eth(src=50:54:00:00:00:0a,dst=50:54:00:00:00:09),eth_type(0x0800),ipv4(src=10.1.1.2,dst=10.1.1.1,proto=17,tos=0,ttl=64,frag=no),udp(src=2,dst=1)' ../../tests/ofproto-dpif.at:9164: cat ovs-vswitchd.log | strip_ufid | filter_flow_install --- - 2017-08-08 09:39:36.051525087 +0000 +++ /build/openvswitch-NQWKUM/openvswitch-2.8.0~git20170807.17b6e3ce8/_dpdk/tests/testsuite.dir/at-groups/1214/stdout 2017-08-08 09:39:36.046218819 +0000 @@ -1,5 +1,4 @@ -ct_state(+new-est+trk),recirc_id(0x1),in_port(2),packet_type(ns=0,id=0),eth_type(0x0800),ipv4(frag=no), actions:drop -ct_state(-new+est+trk),recirc_id(0x1),in_port(2),packet_type(ns=0,id=0),eth_type(0x0800),ipv4(proto=17,frag=no), actions:1 +ct_state(-new-est+trk),recirc_id(0x1),in_port(2),packet_type(ns=0,id=0),eth_type(0x0800),ipv4(frag=no), actions:drop recirc_id(0),in_port(1),packet_type(ns=0,id=0),eth_type(0x0800),ipv4(proto=17,frag=no), actions:ct(commit),2 recirc_id(0),in_port(2),packet_type(ns=0,id=0),eth_type(0x0800),ipv4(proto=17,frag=no), actions:ct,recirc(0x1) --- ../../tests/ofproto-dpif.at:9738: ovs-appctl netdev-dummy/receive p1 '50540000000950540000000a080045000028258e40004006ff3d0a0101020a01010100020001396bb55e8cadbf8a5010000a5ec10000' ../../tests/ofproto-dpif.at:9740: ovs-appctl revalidator/purge ../../tests/ofproto-dpif.at:9744: cat ofctl_monitor.log --- /dev/null 2017-04-26 10:10:32.404961898 +0000 +++ /build/openvswitch-NQWKUM/openvswitch-2.8.0~git20170807.17b6e3ce8/_dpdk/tests/testsuite.dir/at-groups/1225/stdout 2017-08-08 09:40:40.454215126 +0000 @@ -0,0 +1,22 @@ +NXT_PACKET_IN (xid=0x0): table_id=1 cookie=0x1 total_len=54 ct_state=inv|trk,in_port=1 (via action) data_len=54 (unbuffered) +tcp,vlan_tci=0x0000,dl_src=50:54:00:00:00:0a,dl_dst=50:54:00:00:00:09,nw_src=10.1.1.2,nw_dst=10.1.1.1,nw_tos=0,nw_ecn=0,nw_ttl=64,tp_src=2,tp_dst=1,tcp_flags=ack tcp_csum:629b +NXT_PACKET_IN (xid=0x0): table_id=1 cookie=0x1 total_len=55 ct_state=inv|trk,in_port=1 (via action) data_len=55 (unbuffered) +tcp,vlan_tci=0x0000,dl_src=50:54:00:00:00:0a,dl_dst=50:54:00:00:00:09,nw_src=10.1.1.2,nw_dst=10.1.1.1,nw_tos=0,nw_ecn=0,nw_ttl=64,tp_src=2,tp_dst=1,tcp_flags=psh|ack tcp_csum:5892 +NXT_PACKET_IN (xid=0x0): table_id=1 cookie=0x1 total_len=54 ct_state=inv|trk,in_port=2 (via action) data_len=54 (unbuffered) --- Perhaps the activation of DPDK code is somehow adding extra checks on things like packet checksums, but the packet passing through are not fully formed so they get marked as invalid? From dball at vmware.com Tue Aug 8 22:52:36 2017 From: dball at vmware.com (Darrell Ball) Date: Tue, 8 Aug 2017 22:52:36 +0000 Subject: [ovs-discuss] [openvswitch 2.8.0 dpdk] testsuite: 1211 1212 1213 1214 1215 1217 1218 1219 1220 1221 1222 1224 1225 1226 2338 failed In-Reply-To: References: <328530F9-3E9F-43F5-81C4-E35052A9B54F@vmware.com> Message-ID: <3BE3DE67-700C-4EE6-AE21-9A9C3EA834BA@vmware.com> -----Original Message----- From: Joe Stringer Date: Tuesday, August 8, 2017 at 3:43 PM To: Darrell Ball Cc: James Page , "bugs at openvswitch.org" Subject: Re: [ovs-discuss] [openvswitch 2.8.0 dpdk] testsuite: 1211 1212 1213 1214 1215 1217 1218 1219 1220 1221 1222 1224 1225 1226 2338 failed On 8 August 2017 at 09:26, Darrell Ball wrote: > > > > > From: on behalf of James Page > > Date: Tuesday, August 8, 2017 at 2:49 AM > To: "bugs at openvswitch.org" > Subject: [ovs-discuss] [openvswitch 2.8.0 dpdk] testsuite: 1211 1212 1213 > 1214 1215 1217 1218 1219 1220 1221 1222 1224 1225 1226 2338 failed > > > > Hi > > > > I'm cutting builds from branch-2.8 in preparation for the ovs 2.8.0 release > for Ubuntu; we build and test two sets of binaries - a vanilla one and one > with dpdk enabled. > > > > I see test failures on all of the "ofproto-dpif - conntrack" tests with the > DPDK build and with the ovn ACL test (see attached logs). Vanilla build is > fine. > > > > James > > > > These are generic tests and should not be run with-dpdk set. > > If you run these tests --with-dpdk, some tests will consider the packets > coming an actual dpdk interface, which they are not. > > In this case, the packets will be marked with a bad checksum. > > > > Are you able to run these tests as we do without ??with-dpdk? ? Hmm, this seems surprising to me - I thought that "--with-dpdk" mostly just enables another netdevice implementation. Why would this affect input/output with netdev-dummy devices? For what it's worth, I tried a run of the testsuite with OVS built "--with-dpdk" on branch-2.7 and it worked fine: https://urldefense.proofpoint.com/v2/url?u=https-3A__travis-2Dci.org_joestringer_openvswitch_jobs_262439494&d=DwIFaQ&c=uilaK90D4TOVoH58JNXRgQ&r=BVhFA09CGX7JQ5Ih-uZnsw&m=2rYtIAwBngD_iZxhgs9_RxL9aNIlVqYJNRfdSppMEKw&s=j1JxZ5I8Yj0xapAPLtfpPqwTHiqQEUmUf2ZBdqdJkOo&e= The test failures for the first few are hard-failures (ie ovs uses WAIT_UNTIL for something that never succeeds), examples below where OVS was waiting to receive packets that never arrive: ../../tests/ofproto-dpif.at:9016: ovs-appctl netdev-dummy/receive p2 'in_port(2),eth(src=50:54:00:00:00:0a,dst=50:54:00:00:00:09),eth_type(0x0800),ipv4(src=10.1.1.2,dst=10.1.1.1,proto=17,tos=0,ttl=64,frag=no),udp(src=2,dst=1)' ../../tests/ofproto-dpif.at:9018: hard failure --- Some of the later failures are a bit more interesting: ../../tests/ofproto-dpif.at:9161: ovs-appctl netdev-dummy/receive p2 'in_port(2),eth(src=50:54:00:00:00:0a,dst=50:54:00:00:00:09),eth_type(0x0800),ipv4(src=10.1.1.2,dst=10.1.1.1,proto=17,tos=0,ttl=64,frag=no),udp(src=2,dst=1)' ../../tests/ofproto-dpif.at:9164: cat ovs-vswitchd.log | strip_ufid | filter_flow_install --- - 2017-08-08 09:39:36.051525087 +0000 +++ /build/openvswitch-NQWKUM/openvswitch-2.8.0~git20170807.17b6e3ce8/_dpdk/tests/testsuite.dir/at-groups/1214/stdout 2017-08-08 09:39:36.046218819 +0000 @@ -1,5 +1,4 @@ -ct_state(+new-est+trk),recirc_id(0x1),in_port(2),packet_type(ns=0,id=0),eth_type(0x0800),ipv4(frag=no), actions:drop -ct_state(-new+est+trk),recirc_id(0x1),in_port(2),packet_type(ns=0,id=0),eth_type(0x0800),ipv4(proto=17,frag=no), actions:1 +ct_state(-new-est+trk),recirc_id(0x1),in_port(2),packet_type(ns=0,id=0),eth_type(0x0800),ipv4(frag=no), actions:drop recirc_id(0),in_port(1),packet_type(ns=0,id=0),eth_type(0x0800),ipv4(proto=17,frag=no), actions:ct(commit),2 recirc_id(0),in_port(2),packet_type(ns=0,id=0),eth_type(0x0800),ipv4(proto=17,frag=no), actions:ct,recirc(0x1) --- ../../tests/ofproto-dpif.at:9738: ovs-appctl netdev-dummy/receive p1 '50540000000950540000000a080045000028258e40004006ff3d0a0101020a01010100020001396bb55e8cadbf8a5010000a5ec10000' ../../tests/ofproto-dpif.at:9740: ovs-appctl revalidator/purge ../../tests/ofproto-dpif.at:9744: cat ofctl_monitor.log --- /dev/null 2017-04-26 10:10:32.404961898 +0000 +++ /build/openvswitch-NQWKUM/openvswitch-2.8.0~git20170807.17b6e3ce8/_dpdk/tests/testsuite.dir/at-groups/1225/stdout 2017-08-08 09:40:40.454215126 +0000 @@ -0,0 +1,22 @@ +NXT_PACKET_IN (xid=0x0): table_id=1 cookie=0x1 total_len=54 ct_state=inv|trk,in_port=1 (via action) data_len=54 (unbuffered) +tcp,vlan_tci=0x0000,dl_src=50:54:00:00:00:0a,dl_dst=50:54:00:00:00:09,nw_src=10.1.1.2,nw_dst=10.1.1.1,nw_tos=0,nw_ecn=0,nw_ttl=64,tp_src=2,tp_dst=1,tcp_flags=ack tcp_csum:629b +NXT_PACKET_IN (xid=0x0): table_id=1 cookie=0x1 total_len=55 ct_state=inv|trk,in_port=1 (via action) data_len=55 (unbuffered) +tcp,vlan_tci=0x0000,dl_src=50:54:00:00:00:0a,dl_dst=50:54:00:00:00:09,nw_src=10.1.1.2,nw_dst=10.1.1.1,nw_tos=0,nw_ecn=0,nw_ttl=64,tp_src=2,tp_dst=1,tcp_flags=psh|ack tcp_csum:5892 +NXT_PACKET_IN (xid=0x0): table_id=1 cookie=0x1 total_len=54 ct_state=inv|trk,in_port=2 (via action) data_len=54 (unbuffered) [Darrell] Thanks 2.7 will work fine. I have already traced the errors and know why they are occurred; the new HWOL bad checksum flags are not initialized. I sent a patch this morning https://mail.openvswitch.org/pipermail/ovs-dev/2017-August/337042.html --- Perhaps the activation of DPDK code is somehow adding extra checks on things like packet checksums, but the packet passing through are not fully formed so they get marked as invalid? From blp at ovn.org Tue Aug 8 23:07:41 2017 From: blp at ovn.org (Ben Pfaff) Date: Tue, 8 Aug 2017 16:07:41 -0700 Subject: [ovs-discuss] [openvswitch 2.8.0 dpdk] testsuite: 1211 1212 1213 1214 1215 1217 1218 1219 1220 1221 1222 1224 1225 1226 2338 failed In-Reply-To: <3BE3DE67-700C-4EE6-AE21-9A9C3EA834BA@vmware.com> References: <328530F9-3E9F-43F5-81C4-E35052A9B54F@vmware.com> <3BE3DE67-700C-4EE6-AE21-9A9C3EA834BA@vmware.com> Message-ID: <20170808230741.GV6175@ovn.org> On Tue, Aug 08, 2017 at 10:52:36PM +0000, Darrell Ball wrote: > > > -----Original Message----- > From: Joe Stringer > Date: Tuesday, August 8, 2017 at 3:43 PM > To: Darrell Ball > Cc: James Page , "bugs at openvswitch.org" > Subject: Re: [ovs-discuss] [openvswitch 2.8.0 dpdk] testsuite: 1211 1212 1213 1214 1215 1217 1218 1219 1220 1221 1222 1224 1225 1226 2338 failed > > On 8 August 2017 at 09:26, Darrell Ball wrote: > > > > > > > > > > From: on behalf of James Page > > > > Date: Tuesday, August 8, 2017 at 2:49 AM > > To: "bugs at openvswitch.org" > > Subject: [ovs-discuss] [openvswitch 2.8.0 dpdk] testsuite: 1211 1212 1213 > > 1214 1215 1217 1218 1219 1220 1221 1222 1224 1225 1226 2338 failed > > > > > > > > Hi > > > > > > > > I'm cutting builds from branch-2.8 in preparation for the ovs 2.8.0 release > > for Ubuntu; we build and test two sets of binaries - a vanilla one and one > > with dpdk enabled. > > > > > > > > I see test failures on all of the "ofproto-dpif - conntrack" tests with the > > DPDK build and with the ovn ACL test (see attached logs). Vanilla build is > > fine. > > > > > > > > James > > > > > > > > These are generic tests and should not be run with-dpdk set. > > > > If you run these tests --with-dpdk, some tests will consider the packets > > coming an actual dpdk interface, which they are not. > > > > In this case, the packets will be marked with a bad checksum. > > > > > > > > Are you able to run these tests as we do without ??with-dpdk? ? > > Hmm, this seems surprising to me - I thought that "--with-dpdk" mostly > just enables another netdevice implementation. Why would this affect > input/output with netdev-dummy devices? > > For what it's worth, I tried a run of the testsuite with OVS built > "--with-dpdk" on branch-2.7 and it worked fine: > https://urldefense.proofpoint.com/v2/url?u=https-3A__travis-2Dci.org_joestringer_openvswitch_jobs_262439494&d=DwIFaQ&c=uilaK90D4TOVoH58JNXRgQ&r=BVhFA09CGX7JQ5Ih-uZnsw&m=2rYtIAwBngD_iZxhgs9_RxL9aNIlVqYJNRfdSppMEKw&s=j1JxZ5I8Yj0xapAPLtfpPqwTHiqQEUmUf2ZBdqdJkOo&e= > > The test failures for the first few are hard-failures (ie ovs uses > WAIT_UNTIL for something that never succeeds), examples below where > OVS was waiting to receive packets that never arrive: > > ../../tests/ofproto-dpif.at:9016: ovs-appctl netdev-dummy/receive p2 > 'in_port(2),eth(src=50:54:00:00:00:0a,dst=50:54:00:00:00:09),eth_type(0x0800),ipv4(src=10.1.1.2,dst=10.1.1.1,proto=17,tos=0,ttl=64,frag=no),udp(src=2,dst=1)' > ../../tests/ofproto-dpif.at:9018: hard failure > > --- > > Some of the later failures are a bit more interesting: > > ../../tests/ofproto-dpif.at:9161: ovs-appctl netdev-dummy/receive p2 > 'in_port(2),eth(src=50:54:00:00:00:0a,dst=50:54:00:00:00:09),eth_type(0x0800),ipv4(src=10.1.1.2,dst=10.1.1.1,proto=17,tos=0,ttl=64,frag=no),udp(src=2,dst=1)' > ../../tests/ofproto-dpif.at:9164: cat ovs-vswitchd.log | strip_ufid | > filter_flow_install > --- - 2017-08-08 09:39:36.051525087 +0000 > +++ /build/openvswitch-NQWKUM/openvswitch-2.8.0~git20170807.17b6e3ce8/_dpdk/tests/testsuite.dir/at-groups/1214/stdout > 2017-08-08 09:39:36.046218819 +0000 > @@ -1,5 +1,4 @@ > -ct_state(+new-est+trk),recirc_id(0x1),in_port(2),packet_type(ns=0,id=0),eth_type(0x0800),ipv4(frag=no), > actions:drop > -ct_state(-new+est+trk),recirc_id(0x1),in_port(2),packet_type(ns=0,id=0),eth_type(0x0800),ipv4(proto=17,frag=no), > actions:1 > +ct_state(-new-est+trk),recirc_id(0x1),in_port(2),packet_type(ns=0,id=0),eth_type(0x0800),ipv4(frag=no), > actions:drop > recirc_id(0),in_port(1),packet_type(ns=0,id=0),eth_type(0x0800),ipv4(proto=17,frag=no), > actions:ct(commit),2 > recirc_id(0),in_port(2),packet_type(ns=0,id=0),eth_type(0x0800),ipv4(proto=17,frag=no), > actions:ct,recirc(0x1) > > --- > > ../../tests/ofproto-dpif.at:9738: ovs-appctl netdev-dummy/receive p1 > '50540000000950540000000a080045000028258e40004006ff3d0a0101020a01010100020001396bb55e8cadbf8a5010000a5ec10000' > ../../tests/ofproto-dpif.at:9740: ovs-appctl revalidator/purge > ../../tests/ofproto-dpif.at:9744: cat ofctl_monitor.log > --- /dev/null 2017-04-26 10:10:32.404961898 +0000 > +++ /build/openvswitch-NQWKUM/openvswitch-2.8.0~git20170807.17b6e3ce8/_dpdk/tests/testsuite.dir/at-groups/1225/stdout > 2017-08-08 09:40:40.454215126 +0000 > @@ -0,0 +1,22 @@ > +NXT_PACKET_IN (xid=0x0): table_id=1 cookie=0x1 total_len=54 > ct_state=inv|trk,in_port=1 (via action) data_len=54 (unbuffered) > +tcp,vlan_tci=0x0000,dl_src=50:54:00:00:00:0a,dl_dst=50:54:00:00:00:09,nw_src=10.1.1.2,nw_dst=10.1.1.1,nw_tos=0,nw_ecn=0,nw_ttl=64,tp_src=2,tp_dst=1,tcp_flags=ack > tcp_csum:629b > +NXT_PACKET_IN (xid=0x0): table_id=1 cookie=0x1 total_len=55 > ct_state=inv|trk,in_port=1 (via action) data_len=55 (unbuffered) > +tcp,vlan_tci=0x0000,dl_src=50:54:00:00:00:0a,dl_dst=50:54:00:00:00:09,nw_src=10.1.1.2,nw_dst=10.1.1.1,nw_tos=0,nw_ecn=0,nw_ttl=64,tp_src=2,tp_dst=1,tcp_flags=psh|ack > tcp_csum:5892 > +NXT_PACKET_IN (xid=0x0): table_id=1 cookie=0x1 total_len=54 > ct_state=inv|trk,in_port=2 (via action) data_len=54 (unbuffered) > > > [Darrell] > Thanks > 2.7 will work fine. > I have already traced the errors and know why they are occurred; the new HWOL bad checksum flags are not initialized. > I sent a patch this morning > https://mail.openvswitch.org/pipermail/ovs-dev/2017-August/337042.html It wasn't clear that this fixed unit test breakage. Would you mind adding that to the commit message? From blp at ovn.org Tue Aug 8 23:08:51 2017 From: blp at ovn.org (Ben Pfaff) Date: Tue, 8 Aug 2017 16:08:51 -0700 Subject: [ovs-discuss] [openvswitch 2.8.0 dpdk] testsuite: 1211 1212 1213 1214 1215 1217 1218 1219 1220 1221 1222 1224 1225 1226 2338 failed In-Reply-To: <328530F9-3E9F-43F5-81C4-E35052A9B54F@vmware.com> References: <328530F9-3E9F-43F5-81C4-E35052A9B54F@vmware.com> Message-ID: <20170808230851.GW6175@ovn.org> On Tue, Aug 08, 2017 at 04:26:38PM +0000, Darrell Ball wrote: > > > From: on behalf of James Page > Date: Tuesday, August 8, 2017 at 2:49 AM > To: "bugs at openvswitch.org" > Subject: [ovs-discuss] [openvswitch 2.8.0 dpdk] testsuite: 1211 1212 1213 1214 1215 1217 1218 1219 1220 1221 1222 1224 1225 1226 2338 failed > > Hi > > I'm cutting builds from branch-2.8 in preparation for the ovs 2.8.0 release for Ubuntu; we build and test two sets of binaries - a vanilla one and one with dpdk enabled. > > I see test failures on all of the "ofproto-dpif - conntrack" tests with the DPDK build and with the ovn ACL test (see attached logs). Vanilla build is fine. > > James > > These are generic tests and should not be run with-dpdk set. > If you run these tests --with-dpdk, some tests will consider the packets coming an actual dpdk interface, which they are not. > In this case, the packets will be marked with a bad checksum. All of the tests in the testsuite should always pass, or be skipped, regardless of configuration, so if some of the tests are inappropriate for a given configuration then they need AT_SKIP_IF([...]) to ensure that they get skipped. From dball at vmware.com Tue Aug 8 23:14:04 2017 From: dball at vmware.com (Darrell Ball) Date: Tue, 8 Aug 2017 23:14:04 +0000 Subject: [ovs-discuss] [openvswitch 2.8.0 dpdk] testsuite: 1211 1212 1213 1214 1215 1217 1218 1219 1220 1221 1222 1224 1225 1226 2338 failed In-Reply-To: <20170808230851.GW6175@ovn.org> References: <328530F9-3E9F-43F5-81C4-E35052A9B54F@vmware.com> <20170808230851.GW6175@ovn.org> Message-ID: <28DB22E3-387A-4300-88D3-A8AD92CF6911@vmware.com> -----Original Message----- From: Ben Pfaff Date: Tuesday, August 8, 2017 at 4:08 PM To: Darrell Ball Cc: James Page , "bugs at openvswitch.org" Subject: Re: [ovs-discuss] [openvswitch 2.8.0 dpdk] testsuite: 1211 1212 1213 1214 1215 1217 1218 1219 1220 1221 1222 1224 1225 1226 2338 failed On Tue, Aug 08, 2017 at 04:26:38PM +0000, Darrell Ball wrote: > > > From: on behalf of James Page > Date: Tuesday, August 8, 2017 at 2:49 AM > To: "bugs at openvswitch.org" > Subject: [ovs-discuss] [openvswitch 2.8.0 dpdk] testsuite: 1211 1212 1213 1214 1215 1217 1218 1219 1220 1221 1222 1224 1225 1226 2338 failed > > Hi > > I'm cutting builds from branch-2.8 in preparation for the ovs 2.8.0 release for Ubuntu; we build and test two sets of binaries - a vanilla one and one with dpdk enabled. > > I see test failures on all of the "ofproto-dpif - conntrack" tests with the DPDK build and with the ovn ACL test (see attached logs). Vanilla build is fine. > > James > > These are generic tests and should not be run with-dpdk set. > If you run these tests --with-dpdk, some tests will consider the packets coming an actual dpdk interface, which they are not. > In this case, the packets will be marked with a bad checksum. All of the tests in the testsuite should always pass, or be skipped, regardless of configuration, so if some of the tests are inappropriate for a given configuration then they need AT_SKIP_IF([...]) to ensure that they get skipped. sure; that is why I sent the patch. From dball at vmware.com Tue Aug 8 23:14:42 2017 From: dball at vmware.com (Darrell Ball) Date: Tue, 8 Aug 2017 23:14:42 +0000 Subject: [ovs-discuss] [openvswitch 2.8.0 dpdk] testsuite: 1211 1212 1213 1214 1215 1217 1218 1219 1220 1221 1222 1224 1225 1226 2338 failed In-Reply-To: <20170808230741.GV6175@ovn.org> References: <328530F9-3E9F-43F5-81C4-E35052A9B54F@vmware.com> <3BE3DE67-700C-4EE6-AE21-9A9C3EA834BA@vmware.com> <20170808230741.GV6175@ovn.org> Message-ID: <40610D2A-934F-4CE9-A902-A20759D0AE43@vmware.com> -----Original Message----- From: Ben Pfaff Date: Tuesday, August 8, 2017 at 4:07 PM To: Darrell Ball Cc: Joe Stringer , "bugs at openvswitch.org" Subject: Re: [ovs-discuss] [openvswitch 2.8.0 dpdk] testsuite: 1211 1212 1213 1214 1215 1217 1218 1219 1220 1221 1222 1224 1225 1226 2338 failed On Tue, Aug 08, 2017 at 10:52:36PM +0000, Darrell Ball wrote: > > > -----Original Message----- > From: Joe Stringer > Date: Tuesday, August 8, 2017 at 3:43 PM > To: Darrell Ball > Cc: James Page , "bugs at openvswitch.org" > Subject: Re: [ovs-discuss] [openvswitch 2.8.0 dpdk] testsuite: 1211 1212 1213 1214 1215 1217 1218 1219 1220 1221 1222 1224 1225 1226 2338 failed > > On 8 August 2017 at 09:26, Darrell Ball wrote: > > > > > > > > > > From: on behalf of James Page > > > > Date: Tuesday, August 8, 2017 at 2:49 AM > > To: "bugs at openvswitch.org" > > Subject: [ovs-discuss] [openvswitch 2.8.0 dpdk] testsuite: 1211 1212 1213 > > 1214 1215 1217 1218 1219 1220 1221 1222 1224 1225 1226 2338 failed > > > > > > > > Hi > > > > > > > > I'm cutting builds from branch-2.8 in preparation for the ovs 2.8.0 release > > for Ubuntu; we build and test two sets of binaries - a vanilla one and one > > with dpdk enabled. > > > > > > > > I see test failures on all of the "ofproto-dpif - conntrack" tests with the > > DPDK build and with the ovn ACL test (see attached logs). Vanilla build is > > fine. > > > > > > > > James > > > > > > > > These are generic tests and should not be run with-dpdk set. > > > > If you run these tests --with-dpdk, some tests will consider the packets > > coming an actual dpdk interface, which they are not. > > > > In this case, the packets will be marked with a bad checksum. > > > > > > > > Are you able to run these tests as we do without ??with-dpdk? ? > > Hmm, this seems surprising to me - I thought that "--with-dpdk" mostly > just enables another netdevice implementation. Why would this affect > input/output with netdev-dummy devices? > > For what it's worth, I tried a run of the testsuite with OVS built > "--with-dpdk" on branch-2.7 and it worked fine: > https://urldefense.proofpoint.com/v2/url?u=https-3A__travis-2Dci.org_joestringer_openvswitch_jobs_262439494&d=DwIFaQ&c=uilaK90D4TOVoH58JNXRgQ&r=BVhFA09CGX7JQ5Ih-uZnsw&m=2rYtIAwBngD_iZxhgs9_RxL9aNIlVqYJNRfdSppMEKw&s=j1JxZ5I8Yj0xapAPLtfpPqwTHiqQEUmUf2ZBdqdJkOo&e= > > The test failures for the first few are hard-failures (ie ovs uses > WAIT_UNTIL for something that never succeeds), examples below where > OVS was waiting to receive packets that never arrive: > > ../../tests/ofproto-dpif.at:9016: ovs-appctl netdev-dummy/receive p2 > 'in_port(2),eth(src=50:54:00:00:00:0a,dst=50:54:00:00:00:09),eth_type(0x0800),ipv4(src=10.1.1.2,dst=10.1.1.1,proto=17,tos=0,ttl=64,frag=no),udp(src=2,dst=1)' > ../../tests/ofproto-dpif.at:9018: hard failure > > --- > > Some of the later failures are a bit more interesting: > > ../../tests/ofproto-dpif.at:9161: ovs-appctl netdev-dummy/receive p2 > 'in_port(2),eth(src=50:54:00:00:00:0a,dst=50:54:00:00:00:09),eth_type(0x0800),ipv4(src=10.1.1.2,dst=10.1.1.1,proto=17,tos=0,ttl=64,frag=no),udp(src=2,dst=1)' > ../../tests/ofproto-dpif.at:9164: cat ovs-vswitchd.log | strip_ufid | > filter_flow_install > --- - 2017-08-08 09:39:36.051525087 +0000 > +++ /build/openvswitch-NQWKUM/openvswitch-2.8.0~git20170807.17b6e3ce8/_dpdk/tests/testsuite.dir/at-groups/1214/stdout > 2017-08-08 09:39:36.046218819 +0000 > @@ -1,5 +1,4 @@ > -ct_state(+new-est+trk),recirc_id(0x1),in_port(2),packet_type(ns=0,id=0),eth_type(0x0800),ipv4(frag=no), > actions:drop > -ct_state(-new+est+trk),recirc_id(0x1),in_port(2),packet_type(ns=0,id=0),eth_type(0x0800),ipv4(proto=17,frag=no), > actions:1 > +ct_state(-new-est+trk),recirc_id(0x1),in_port(2),packet_type(ns=0,id=0),eth_type(0x0800),ipv4(frag=no), > actions:drop > recirc_id(0),in_port(1),packet_type(ns=0,id=0),eth_type(0x0800),ipv4(proto=17,frag=no), > actions:ct(commit),2 > recirc_id(0),in_port(2),packet_type(ns=0,id=0),eth_type(0x0800),ipv4(proto=17,frag=no), > actions:ct,recirc(0x1) > > --- > > ../../tests/ofproto-dpif.at:9738: ovs-appctl netdev-dummy/receive p1 > '50540000000950540000000a080045000028258e40004006ff3d0a0101020a01010100020001396bb55e8cadbf8a5010000a5ec10000' > ../../tests/ofproto-dpif.at:9740: ovs-appctl revalidator/purge > ../../tests/ofproto-dpif.at:9744: cat ofctl_monitor.log > --- /dev/null 2017-04-26 10:10:32.404961898 +0000 > +++ /build/openvswitch-NQWKUM/openvswitch-2.8.0~git20170807.17b6e3ce8/_dpdk/tests/testsuite.dir/at-groups/1225/stdout > 2017-08-08 09:40:40.454215126 +0000 > @@ -0,0 +1,22 @@ > +NXT_PACKET_IN (xid=0x0): table_id=1 cookie=0x1 total_len=54 > ct_state=inv|trk,in_port=1 (via action) data_len=54 (unbuffered) > +tcp,vlan_tci=0x0000,dl_src=50:54:00:00:00:0a,dl_dst=50:54:00:00:00:09,nw_src=10.1.1.2,nw_dst=10.1.1.1,nw_tos=0,nw_ecn=0,nw_ttl=64,tp_src=2,tp_dst=1,tcp_flags=ack > tcp_csum:629b > +NXT_PACKET_IN (xid=0x0): table_id=1 cookie=0x1 total_len=55 > ct_state=inv|trk,in_port=1 (via action) data_len=55 (unbuffered) > +tcp,vlan_tci=0x0000,dl_src=50:54:00:00:00:0a,dl_dst=50:54:00:00:00:09,nw_src=10.1.1.2,nw_dst=10.1.1.1,nw_tos=0,nw_ecn=0,nw_ttl=64,tp_src=2,tp_dst=1,tcp_flags=psh|ack > tcp_csum:5892 > +NXT_PACKET_IN (xid=0x0): table_id=1 cookie=0x1 total_len=54 > ct_state=inv|trk,in_port=2 (via action) data_len=54 (unbuffered) > > > [Darrell] > Thanks > 2.7 will work fine. > I have already traced the errors and know why they are occurred; the new HWOL bad checksum flags are not initialized. > I sent a patch this morning > https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.openvswitch.org_pipermail_ovs-2Ddev_2017-2DAugust_337042.html&d=DwIDaQ&c=uilaK90D4TOVoH58JNXRgQ&r=BVhFA09CGX7JQ5Ih-uZnsw&m=MwNl-8_LVDZtAOJim0AV2D1rvxDNCFyZyAlyZbX800o&s=LIf5eJnGN7sWYROPWiABnJMlh3CibXHY9yxSOATPfxE&e= It wasn't clear that this fixed unit test breakage. Would you mind adding that to the commit message? sure; will add and resend. From ankaiah.nallamekala at wipro.com Wed Aug 9 03:12:22 2017 From: ankaiah.nallamekala at wipro.com (ankaiah.nallamekala at wipro.com) Date: Wed, 9 Aug 2017 03:12:22 +0000 Subject: [ovs-discuss] Regarding CFM/OAM support in Openvswitch In-Reply-To: <20170808165608.GZ6175@ovn.org> References: <20170808165608.GZ6175@ovn.org> Message-ID: Thanks a lot Ben Pfaff for prompt response. Both BFD and CFM (CCM) can be used to monitor connectivity between a pair of Ethernet devices., Could you please share the major differences between BFD & CFM CCM in openvswitch. Kindly share/point me if you have any link/document which describes this functionality. Thanks, Anki -----Original Message----- From: Ben Pfaff [mailto:blp at ovn.org] Sent: Tuesday, August 8, 2017 10:26 PM To: Ankaiah Nallamekala (MFG & Tech) Cc: ovs-dev at openvswitch.org; ovs-discuss at openvswitch.org Subject: Re: [ovs-discuss] Regarding CFM/OAM support in Openvswitch ** This mail has been sent from an external source. Treat hyperlinks and attachments in this email with caution** On Tue, Aug 08, 2017 at 02:07:25PM +0000, ankaiah.nallamekala at wipro.com wrote: > Ethernet CFM/OAM supports Loopback protocol(LBM) and Link Trace > protocol(LTM), Is ovs is supporting these two protocols as well, if so > could you please describe how to use these two protocols. OVS doesn't support those. ______________________________________________________________________ This email has been scanned by the Symantec Email Security.cloud service. For more information please visit http://www.symanteccloud.com ______________________________________________________________________ The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From blp at ovn.org Wed Aug 9 03:40:49 2017 From: blp at ovn.org (Ben Pfaff) Date: Tue, 8 Aug 2017 20:40:49 -0700 Subject: [ovs-discuss] Regarding CFM/OAM support in Openvswitch In-Reply-To: References: <20170808165608.GZ6175@ovn.org> Message-ID: <20170809034049.GH6175@ovn.org> On Wed, Aug 09, 2017 at 03:12:22AM +0000, ankaiah.nallamekala at wipro.com wrote: > Both BFD and CFM (CCM) can be used to monitor connectivity between a > pair of Ethernet devices., Could you please share the major > differences between BFD & CFM CCM in openvswitch. They're both about the same. From ankaiah.nallamekala at wipro.com Wed Aug 9 03:42:11 2017 From: ankaiah.nallamekala at wipro.com (ankaiah.nallamekala at wipro.com) Date: Wed, 9 Aug 2017 03:42:11 +0000 Subject: [ovs-discuss] Regarding CFM/OAM support in Openvswitch In-Reply-To: <20170809034049.GH6175@ovn.org> References: <20170808165608.GZ6175@ovn.org> <20170809034049.GH6175@ovn.org> Message-ID: Thanks a lot Ben. Thanks, Anki -----Original Message----- From: Ben Pfaff [mailto:blp at ovn.org] Sent: Wednesday, August 9, 2017 9:11 AM To: Ankaiah Nallamekala (MFG & Tech) Cc: ovs-dev at openvswitch.org; ovs-discuss at openvswitch.org Subject: Re: [ovs-discuss] Regarding CFM/OAM support in Openvswitch ** This mail has been sent from an external source. Treat hyperlinks and attachments in this email with caution** On Wed, Aug 09, 2017 at 03:12:22AM +0000, ankaiah.nallamekala at wipro.com wrote: > Both BFD and CFM (CCM) can be used to monitor connectivity between a > pair of Ethernet devices., Could you please share the major > differences between BFD & CFM CCM in openvswitch. They're both about the same. ______________________________________________________________________ This email has been scanned by the Symantec Email Security.cloud service. For more information please visit http://www.symanteccloud.com ______________________________________________________________________ The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com From remsolutions2010 at gmail.com Wed Aug 9 04:44:49 2017 From: remsolutions2010 at gmail.com (Ricky) Date: Tue, 8 Aug 2017 21:44:49 -0700 Subject: [ovs-discuss] Strange behaviour with VLANs and Bridges and ARP. In-Reply-To: References: Message-ID: <2475cf0a-5fe9-7b57-2a65-cb81ab2118cf@gmail.com> I have run into a similar problem myself and have not found the solution. The ARP traffic from one direction makes it to OVS, but does not get sent to device it needs to go to. It my case OVS pretty much isn't sending any ARP packets out from itself except to the other OVS instances I have a GRE tunnel with. I'm running version 2.5.0. Please let me know if you made any progress on your issue. On 08/07/2017 07:19 PM, Schlacta, Christopher wrote: > Ping. Anybody? Hello? > > On Wed, Aug 2, 2017 at 10:32 PM, Schlacta, Christopher > wrote: >> So this is a bit hard to explain, but I hope you'll follow. I have >> two hosts, density and densetsu. they each host VMs and CEPH nodes >> using libvirt and ceph and they're connected to a smart switch using >> openvswitch and there are a bunch of VLANs. 5, 6, 10, 20, and 30. >> Most "normal" traffic goes along VLAN 10. That's just the LAN VLAN. >> So here's what the ovs-vsctl show looks like on each host: >> >> >> density: >> aarcane at density:~$ sudo ovs-vsctl show >> YubiKey for `aarcane': >> f2ae0266-6cae-44f0-8ca5-9d6f66562ff4 >> Bridge "br0" >> Port lan >> tag: 10 >> Interface lan >> type: internal >> Port "vnet0" >> trunks: [5, 6, 10, 20, 30] >> Interface "vnet0" >> Port "eth1" >> Interface "eth1" >> Port "vnet1" >> trunks: [5, 6, 10, 20, 30] >> Interface "vnet1" >> Port "br0" >> Interface "br0" >> type: internal >> ovs_version: "2.7.0" >> >> >> densetsu: >> aarcane at densetsu:~$ sudo ovs-vsctl show >> 2d6843ee-2bb6-48b8-a979-ba7f64bf5ebc >> Bridge "br0" >> Port "eth0" >> Interface "eth0" >> Port lan >> tag: 10 >> Interface lan >> type: internal >> Port "br0" >> Interface "br0" >> type: internal >> ovs_version: "2.7.0" >> >> >> The problem is when I try to ping the opposite machine (densetsu to >> density or vice versa), the ARP packets get sent with appropriate >> information through BR0 and out the eth device all tagged with VLAN >> 10, but the *inbound* arp packet is never sent to the lan interface. >> I see it at the br0 and the eth interface, but not the destination >> host's lan interface. Furthermore, the destination never seems to see >> this or respond to it, so it's then impossible for the to initiate >> contact without adding entries to the ethers file. >> >> This is well and good, but it also means that other systems on the >> network also cannot connect to them for purposes of administration and >> management, and this is very problematic. >> >> I've not made any changes to openflow. They've been able to >> communicate with each other for a long time. This change happened >> with a recent kernel upgrade. Not sure how to fix it or if it's a >> bug. Again, note: All IP traffic seems to work fine. ICMP works >> without issue, TCP, etc. It's only the ARP protocol that seems to not >> be passing inward when it should be. > _______________________________________________ > discuss mailing list > discuss at openvswitch.org > https://mail.openvswitch.org/mailman/listinfo/ovs-discuss From ppousada at gti.uvigo.es Wed Aug 9 07:04:43 2017 From: ppousada at gti.uvigo.es (Pablo Pousada) Date: Wed, 9 Aug 2017 09:04:43 +0200 Subject: [ovs-discuss] Lost connectivity when having multiple ports In-Reply-To: <20170808215821.GT6175@ovn.org> References: <08a79dda-8699-18e4-6069-cae82bf8f5a8@gti.uvigo.es> <20170808215821.GT6175@ovn.org> Message-ID: <4e773e38-d079-f19c-854f-72b1853cd39c@gti.uvigo.es> No, I considered looping because we are working on a complex network, and tested it removing any possible looping on it. However, after some testing, we came to the conclusion it was being caused some kind of hardware limitations, since we were working with devices not so powerful. We replaced the devices for others a bit more powerful, and it worked for a while, until we took that one over the limit too building something a bit more complex, with a similar problem and still no loops, supporting our theory of being some hardware limitation. I am still working on finding out exactly what is going wrong, so we can take it into account for future developing, but haven't found anything specific yet. El 08/08/17 a las 23:58, Ben Pfaff escribi?: > On Mon, Jul 24, 2017 at 01:04:34PM +0200, Pablo Pousada wrote: >> I've been encountering an error on the testbed I'm building, where having >> multiple ports added to a ovs bridge blocks all outwards communication. >> >> Example: Having the following setup, i have connectivity through the eth0.3 >> port: >> >> root at LEDE:~# ovs-vsctl show >> 41ae4f8f-55db-4cd0-8dd1-3e7b001d8f54 >> Bridge "br0" >> Controller "tcp:192.168.1.151" >> Port "br0" >> Interface "br0" >> type: internal >> Port "eth0.3" >> Interface "eth0.3" >> >> Whenever I add another port to that bridge, inward packages are received, >> but outward packages are never sent. The problem persists with or without >> controller. >> >> ?Does anyone have any info on where the problem might be? >> >> I'm using Open vSwitch version 2.5.0 over LEDE. > This sounds like the second question here: > http://docs.openvswitch.org/en/latest/faq/issues/ From batmanustc at gmail.com Wed Aug 9 09:23:20 2017 From: batmanustc at gmail.com (Sam) Date: Wed, 9 Aug 2017 17:23:20 +0800 Subject: [ovs-discuss] Why my AT_CHECK() can't work? Message-ID: Hi all, I'm using autotest to test ovs, and I write a new *.at file using only one AT_CHECK sentence like this: AT_CHECK([ovs-appctl dpdk/bond-show dpdkb2], [0], [stdout]) > AT_CHECK([[sed '/ACTIVE/p' stdout | head -4]], [0], [[LACP actor_state > ACTIVE AGGREGATION SYNC COLLECTING DISTRIBUTING > partner_state ACTIVE AGGREGATION SYNC COLLECTING DISTRIBUTING > LACP actor_state ACTIVE AGGREGATION SYNC COLLECTING DISTRIBUTING > partner_state ACTIVE AGGREGATION SYNC COLLECTING DISTRIBUTING]]) but this *.at file failed, log is: 789. netdev-dpdk.at:23: testing netdev-dpdk - dpdk/bond-show ... > ./netdev-dpdk.at:27: ovs-appctl dpdk/bond-show dpdkb2 > stdout: > ---- dpdkb2 ---- > bond_mode: 4 > slave 0: > active > mac address ec:f4:bb:e1:1a:40 > Link Up - speed 10000 Mbps - full-duplex > LACP actor_state ACTIVE AGGREGATION SYNC COLLECTING DISTRIBUTING > partner_state ACTIVE AGGREGATION SYNC COLLECTING DISTRIBUTING > rx pkts=268449, bytes=16502449, mcasts=0, drop=0, errs=0, nombufs=0 > tx pkts=261, bytes=32020, errs=0 > slave 1: > active > mac address ec:f4:bb:e1:1a:42 > Link Up - speed 10000 Mbps - full-duplex > LACP actor_state ACTIVE AGGREGATION SYNC COLLECTING DISTRIBUTING > partner_state ACTIVE AGGREGATION SYNC COLLECTING DISTRIBUTING > rx pkts=296190, bytes=17934647, mcasts=0, drop=0, errs=0, nombufs=0 > tx pkts=254, bytes=31496, errs=0 > ./netdev-dpdk.at:28: sed '/ACTIVE/p' stdout | head -4 > --- - 2017-08-09 16:59:18.802810195 +0800 > +++ /home/gangyewei-3/mvs/mvs/tests/testsuite.dir/at-groups/789/stdout > 2017-08-09 16:59:18.801176471 +0800 > @@ -1,4 +1,5 @@ > -LACP actor_state ACTIVE AGGREGATION SYNC COLLECTING DISTRIBUTING > - partner_state ACTIVE AGGREGATION SYNC COLLECTING DISTRIBUTING > -LACP actor_state ACTIVE AGGREGATION SYNC COLLECTING DISTRIBUTING > - partner_state ACTIVE AGGREGATION SYNC COLLECTING DISTRIBUTING > +---- dpdkb2 ---- > +bond_mode: 4 > + > +slave 0: > + > 789. netdev-dpdk.at:23: 789. netdev-dpdk - dpdk/bond-show ( > netdev-dpdk.at:23): FAILED (netdev-dpdk.at:28) 1. I don't know what "+" "-" means, and why there are "+" and "-"? 2. I run `ovs-appctl dpdk/bond-show dpdkb2 | sed -n '/ACTIVE/p' | head -4` in command line, result is: > LACP actor_state ACTIVE AGGREGATION SYNC COLLECTING DISTRIBUTING > partner_state ACTIVE AGGREGATION SYNC COLLECTING DISTRIBUTING > LACP actor_state ACTIVE AGGREGATION SYNC COLLECTING DISTRIBUTING > partner_state ACTIVE AGGREGATION SYNC COLLECTING DISTRIBUTING That's exactly what I matched in AT_CHECK, why it fails? Autotest is really hard to use... -------------- next part -------------- An HTML attachment was scrubbed... URL: From batmanustc at gmail.com Wed Aug 9 09:45:43 2017 From: batmanustc at gmail.com (Sam) Date: Wed, 9 Aug 2017 17:45:43 +0800 Subject: [ovs-discuss] Why my AT_CHECK() can't work? In-Reply-To: References: Message-ID: Then I change commd into `awk '/ACTIVE/' stdout | head -4`, it failed again, log is : ./netdev-dpdk.at:28: awk '/ACTIVE/' stdout | head -4 > --- - 2017-08-09 17:41:24.809066088 +0800 > +++ /home/gangyewei-3/mvs/mvs/tests/testsuite.dir/at-groups/789/stdout > 2017-08-09 17:41:24.807150522 +0800 > @@ -1,5 +1,5 @@ > -LACP actor_state ACTIVE AGGREGATION SYNC COLLECTING DISTRIBUTING > - partner_state ACTIVE AGGREGATION SYNC COLLECTING DISTRIBUTING > -LACP actor_state ACTIVE AGGREGATION SYNC COLLECTING DISTRIBUTING > - partner_state ACTIVE AGGREGATION SYNC COLLECTING DISTRIBUTING > +LACP actor_state ACTIVE AGGREGATION SYNC COLLECTING DISTRIBUTING > + partner_state ACTIVE AGGREGATION SYNC COLLECTING DISTRIBUTING > +LACP actor_state ACTIVE AGGREGATION SYNC COLLECTING DISTRIBUTING > + partner_state ACTIVE AGGREGATION SYNC COLLECTING DISTRIBUTING > 789. netdev-dpdk.at:23: 789. netdev-dpdk - dpdk/bond-show ( > netdev-dpdk.at:23): FAILED (netdev-dpdk.at:28) I don't know where is the difference.... 2017-08-09 17:15 GMT+08:00 Sam : > Hi all, > > I'm using autotest to test ovs, and I write a new *.at file using only one > AT_CHECK sentence like this: > > AT_CHECK([ovs-appctl dpdk/bond-show dpdkb2], [0], [stdout]) >> AT_CHECK([[sed '/ACTIVE/p' stdout | head -4]], [0], [[LACP actor_state >> ACTIVE AGGREGATION SYNC COLLECTING DISTRIBUTING >> partner_state ACTIVE AGGREGATION SYNC COLLECTING DISTRIBUTING >> LACP actor_state ACTIVE AGGREGATION SYNC COLLECTING DISTRIBUTING >> partner_state ACTIVE AGGREGATION SYNC COLLECTING DISTRIBUTING]]) > > > but this *.at file failed, log is: > > 789. netdev-dpdk.at:23: testing netdev-dpdk - dpdk/bond-show ... >> ./netdev-dpdk.at:27: ovs-appctl dpdk/bond-show dpdkb2 >> stdout: >> ---- dpdkb2 ---- >> bond_mode: 4 >> slave 0: >> active >> mac address ec:f4:bb:e1:1a:40 >> Link Up - speed 10000 Mbps - full-duplex >> LACP actor_state ACTIVE AGGREGATION SYNC COLLECTING DISTRIBUTING >> partner_state ACTIVE AGGREGATION SYNC COLLECTING DISTRIBUTING >> rx pkts=268449, bytes=16502449, mcasts=0, drop=0, errs=0, nombufs=0 >> tx pkts=261, bytes=32020, errs=0 >> slave 1: >> active >> mac address ec:f4:bb:e1:1a:42 >> Link Up - speed 10000 Mbps - full-duplex >> LACP actor_state ACTIVE AGGREGATION SYNC COLLECTING DISTRIBUTING >> partner_state ACTIVE AGGREGATION SYNC COLLECTING DISTRIBUTING >> rx pkts=296190, bytes=17934647, mcasts=0, drop=0, errs=0, nombufs=0 >> tx pkts=254, bytes=31496, errs=0 >> ./netdev-dpdk.at:28: sed '/ACTIVE/p' stdout | head -4 >> --- - 2017-08-09 16:59:18.802810195 +0800 >> +++ /home/gangyewei-3/mvs/mvs/tests/testsuite.dir/at-groups/789/stdout >> 2017-08-09 16:59:18.801176471 +0800 >> @@ -1,4 +1,5 @@ >> -LACP actor_state ACTIVE AGGREGATION SYNC COLLECTING DISTRIBUTING >> - partner_state ACTIVE AGGREGATION SYNC COLLECTING DISTRIBUTING >> -LACP actor_state ACTIVE AGGREGATION SYNC COLLECTING DISTRIBUTING >> - partner_state ACTIVE AGGREGATION SYNC COLLECTING DISTRIBUTING >> +---- dpdkb2 ---- >> +bond_mode: 4 >> + >> +slave 0: >> + >> 789. netdev-dpdk.at:23: 789. netdev-dpdk - dpdk/bond-show ( >> netdev-dpdk.at:23): FAILED (netdev-dpdk.at:28) > > > 1. I don't know what "+" "-" means, and why there are "+" and "-"? > 2. I run `ovs-appctl dpdk/bond-show dpdkb2 | sed -n '/ACTIVE/p' | head > -4`, result is: > >> LACP actor_state ACTIVE AGGREGATION SYNC COLLECTING DISTRIBUTING >> partner_state ACTIVE AGGREGATION SYNC COLLECTING DISTRIBUTING >> LACP actor_state ACTIVE AGGREGATION SYNC COLLECTING DISTRIBUTING >> partner_state ACTIVE AGGREGATION SYNC COLLECTING DISTRIBUTING > > That's exactly what I matched in AT_CHECK, why it fails? > > Autotest is really hard to use... > > 2017-08-09 17:23 GMT+08:00 Sam : > Hi all, > > I'm using autotest to test ovs, and I write a new *.at file using only one > AT_CHECK sentence like this: > > AT_CHECK([ovs-appctl dpdk/bond-show dpdkb2], [0], [stdout]) >> AT_CHECK([[sed '/ACTIVE/p' stdout | head -4]], [0], [[LACP actor_state >> ACTIVE AGGREGATION SYNC COLLECTING DISTRIBUTING >> partner_state ACTIVE AGGREGATION SYNC COLLECTING DISTRIBUTING >> LACP actor_state ACTIVE AGGREGATION SYNC COLLECTING DISTRIBUTING >> partner_state ACTIVE AGGREGATION SYNC COLLECTING DISTRIBUTING]]) > > > but this *.at file failed, log is: > > 789. netdev-dpdk.at:23: testing netdev-dpdk - dpdk/bond-show ... >> ./netdev-dpdk.at:27: ovs-appctl dpdk/bond-show dpdkb2 >> stdout: >> ---- dpdkb2 ---- >> bond_mode: 4 >> slave 0: >> active >> mac address ec:f4:bb:e1:1a:40 >> Link Up - speed 10000 Mbps - full-duplex >> LACP actor_state ACTIVE AGGREGATION SYNC COLLECTING DISTRIBUTING >> partner_state ACTIVE AGGREGATION SYNC COLLECTING DISTRIBUTING >> rx pkts=268449, bytes=16502449, mcasts=0, drop=0, errs=0, nombufs=0 >> tx pkts=261, bytes=32020, errs=0 >> slave 1: >> active >> mac address ec:f4:bb:e1:1a:42 >> Link Up - speed 10000 Mbps - full-duplex >> LACP actor_state ACTIVE AGGREGATION SYNC COLLECTING DISTRIBUTING >> partner_state ACTIVE AGGREGATION SYNC COLLECTING DISTRIBUTING >> rx pkts=296190, bytes=17934647, mcasts=0, drop=0, errs=0, nombufs=0 >> tx pkts=254, bytes=31496, errs=0 >> ./netdev-dpdk.at:28: sed '/ACTIVE/p' stdout | head -4 >> --- - 2017-08-09 16:59:18.802810195 +0800 >> +++ /home/gangyewei-3/mvs/mvs/tests/testsuite.dir/at-groups/789/stdout >> 2017-08-09 16:59:18.801176471 +0800 >> @@ -1,4 +1,5 @@ >> -LACP actor_state ACTIVE AGGREGATION SYNC COLLECTING DISTRIBUTING >> - partner_state ACTIVE AGGREGATION SYNC COLLECTING DISTRIBUTING >> -LACP actor_state ACTIVE AGGREGATION SYNC COLLECTING DISTRIBUTING >> - partner_state ACTIVE AGGREGATION SYNC COLLECTING DISTRIBUTING >> +---- dpdkb2 ---- >> +bond_mode: 4 >> + >> +slave 0: >> + >> 789. netdev-dpdk.at:23: 789. netdev-dpdk - dpdk/bond-show ( >> netdev-dpdk.at:23): FAILED (netdev-dpdk.at:28) > > > 1. I don't know what "+" "-" means, and why there are "+" and "-"? > 2. I run `ovs-appctl dpdk/bond-show dpdkb2 | sed -n '/ACTIVE/p' | head -4` > in command line, result is: > >> LACP actor_state ACTIVE AGGREGATION SYNC COLLECTING DISTRIBUTING >> partner_state ACTIVE AGGREGATION SYNC COLLECTING DISTRIBUTING >> LACP actor_state ACTIVE AGGREGATION SYNC COLLECTING DISTRIBUTING >> partner_state ACTIVE AGGREGATION SYNC COLLECTING DISTRIBUTING > > That's exactly what I matched in AT_CHECK, why it fails? > > Autotest is really hard to use... > -------------- next part -------------- An HTML attachment was scrubbed... URL: From blue at veracity.io Wed Aug 9 14:54:51 2017 From: blue at veracity.io (Blue Lang) Date: Wed, 9 Aug 2017 09:54:51 -0500 Subject: [ovs-discuss] Strange behaviour with VLANs and Bridges and ARP. In-Reply-To: <2475cf0a-5fe9-7b57-2a65-cb81ab2118cf@gmail.com> References: <2475cf0a-5fe9-7b57-2a65-cb81ab2118cf@gmail.com> Message-ID: The only place I've seen this is with VMWARE vswitch not forwarding ARP on ESX. That doesn't sound like it's any part of your issue. When you say "smart switch using openvswitch," what do you mean exactly? Thanks, On Tue, Aug 8, 2017 at 11:44 PM, Ricky wrote: > I have run into a similar problem myself and have not found the solution. > The ARP traffic from one direction makes it to OVS, but does not get sent > to device it needs to go to. It my case OVS pretty much isn't sending any > ARP packets out from itself except to the other OVS instances I have a GRE > tunnel with. I'm running version 2.5.0. > > Please let me know if you made any progress on your issue. > > > On 08/07/2017 07:19 PM, Schlacta, Christopher wrote: > >> Ping. Anybody? Hello? >> >> On Wed, Aug 2, 2017 at 10:32 PM, Schlacta, Christopher >> wrote: >> >>> So this is a bit hard to explain, but I hope you'll follow. I have >>> two hosts, density and densetsu. they each host VMs and CEPH nodes >>> using libvirt and ceph and they're connected to a smart switch using >>> openvswitch and there are a bunch of VLANs. 5, 6, 10, 20, and 30. >>> Most "normal" traffic goes along VLAN 10. That's just the LAN VLAN. >>> So here's what the ovs-vsctl show looks like on each host: >>> >>> >>> density: >>> aarcane at density:~$ sudo ovs-vsctl show >>> YubiKey for `aarcane': >>> f2ae0266-6cae-44f0-8ca5-9d6f66562ff4 >>> Bridge "br0" >>> Port lan >>> tag: 10 >>> Interface lan >>> type: internal >>> Port "vnet0" >>> trunks: [5, 6, 10, 20, 30] >>> Interface "vnet0" >>> Port "eth1" >>> Interface "eth1" >>> Port "vnet1" >>> trunks: [5, 6, 10, 20, 30] >>> Interface "vnet1" >>> Port "br0" >>> Interface "br0" >>> type: internal >>> ovs_version: "2.7.0" >>> >>> >>> densetsu: >>> aarcane at densetsu:~$ sudo ovs-vsctl show >>> 2d6843ee-2bb6-48b8-a979-ba7f64bf5ebc >>> Bridge "br0" >>> Port "eth0" >>> Interface "eth0" >>> Port lan >>> tag: 10 >>> Interface lan >>> type: internal >>> Port "br0" >>> Interface "br0" >>> type: internal >>> ovs_version: "2.7.0" >>> >>> >>> The problem is when I try to ping the opposite machine (densetsu to >>> density or vice versa), the ARP packets get sent with appropriate >>> information through BR0 and out the eth device all tagged with VLAN >>> 10, but the *inbound* arp packet is never sent to the lan interface. >>> I see it at the br0 and the eth interface, but not the destination >>> host's lan interface. Furthermore, the destination never seems to see >>> this or respond to it, so it's then impossible for the to initiate >>> contact without adding entries to the ethers file. >>> >>> This is well and good, but it also means that other systems on the >>> network also cannot connect to them for purposes of administration and >>> management, and this is very problematic. >>> >>> I've not made any changes to openflow. They've been able to >>> communicate with each other for a long time. This change happened >>> with a recent kernel upgrade. Not sure how to fix it or if it's a >>> bug. Again, note: All IP traffic seems to work fine. ICMP works >>> without issue, TCP, etc. It's only the ARP protocol that seems to not >>> be passing inward when it should be. >>> >> _______________________________________________ >> discuss mailing list >> discuss at openvswitch.org >> https://mail.openvswitch.org/mailman/listinfo/ovs-discuss >> > > > _______________________________________________ > discuss mailing list > discuss at openvswitch.org > https://mail.openvswitch.org/mailman/listinfo/ovs-discuss > -- Blue Lang PM *| *Veracity 3423 Piedmont Rd NE Suite 350 Atlanta, GA 30305 Cell: (770) 265-1381 <+17702651381> https://www.linkedin.com/in/bluelang/ blue at veracity.io www.veracity.io -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Veracity-horizontal-logo-tiny_sig.png Type: image/png Size: 5372 bytes Desc: not available URL: From jirix.x.prokes at intel.com Wed Aug 9 15:54:50 2017 From: jirix.x.prokes at intel.com (Prokes, JiriX X) Date: Wed, 9 Aug 2017 15:54:50 +0000 Subject: [ovs-discuss] ovs-vswitchd crash during startup when br-ex has assigned IP address and br-ex is UP Message-ID: We are using kolla/kolla-ansible to deploy openstack. Used configuration is ovs + vxlan + old (Opendaylight) Opendaylight needs to have IP address assigned to br-ex bridge to enable connectivity via floatingIP to VMs. Ovs is running in docker container. After deployment ovs container is up and running and br-ex is in state DOWN ip addr show br-ex 12: br-ex: mtu 1500 qdisc noqueue state DOWN qlen 1000 link/ether 68:05:ca:32:62:93 brd ff:ff:ff:ff:ff:ff Then we assign IP and set it UP ip addr show br-ex 12: br-ex: mtu 1500 qdisc noqueue state UNKNOWN qlen 1000 link/ether 68:05:ca:3a:19:33 brd ff:ff:ff:ff:ff:ff inet 10.0.2.16/24 scope global br-ex valid_lft forever preferred_lft forever inet6 fe80::6a05:caff:fe3a:1933/64 scope link valid_lft forever preferred_lft forever Then ovs container is restarted docker restart openvswitch-vswitchd Which cause ovs-vswitchd crash. Expected behavior is that ovs-vswitchd starts correctly. Running command: 'start-ovs' /usr/local/bin/start-ovs: line 8: 22 Segmentation fault (core dumped) /usr/sbin/ovs-vswitchd unix:/run/openvswitch/db.sock -vconsole:emer -vsyslog:err -vfile:info --mlockall --log-file=/var/log/kolla/openvswitch/ovs-vswitchd.log Log: 2017-08-09T14:13:58.536Z|00001|vlog|INFO|opened log file /var/log/kolla/openvswitch/ovs-vswitchd.log 2017-08-09T14:13:58.540Z|00002|ovs_numa|INFO|Discovered 36 CPU cores on NUMA node 0 2017-08-09T14:13:58.540Z|00003|ovs_numa|INFO|Discovered 36 CPU cores on NUMA node 1 2017-08-09T14:13:58.540Z|00004|ovs_numa|INFO|Discovered 2 NUMA nodes and 72 CPU cores 2017-08-09T14:13:58.540Z|00005|reconnect|INFO|unix:/run/openvswitch/db.sock: connecting... 2017-08-09T14:13:58.540Z|00006|reconnect|INFO|unix:/run/openvswitch/db.sock: connected 2017-08-09T14:13:58.543Z|00007|dpdk|INFO|DPDK Disabled - Use other_config:dpdk-init to enable 2017-08-09T14:13:58.548Z|00008|ofproto_dpif|INFO|system at ovs-system: Datapath supports recirculation 2017-08-09T14:13:58.548Z|00009|ofproto_dpif|INFO|system at ovs-system: VLAN header stack length probed as 1 2017-08-09T14:13:58.548Z|00010|ofproto_dpif|INFO|system at ovs-system: MPLS label stack length probed as 1 2017-08-09T14:13:58.548Z|00011|ofproto_dpif|INFO|system at ovs-system: Datapath does not support truncate action 2017-08-09T14:13:58.548Z|00012|ofproto_dpif|INFO|system at ovs-system: Datapath supports unique flow ids 2017-08-09T14:13:58.548Z|00013|ofproto_dpif|INFO|system at ovs-system: Datapath does not support clone action 2017-08-09T14:13:58.548Z|00014|ofproto_dpif|INFO|system at ovs-system: Max sample nesting level probed as 3 2017-08-09T14:13:58.548Z|00015|ofproto_dpif|INFO|system at ovs-system: Datapath does not support eventmask in conntrack action 2017-08-09T14:13:58.548Z|00016|ofproto_dpif|INFO|system at ovs-system: Datapath supports ct_state 2017-08-09T14:13:58.548Z|00017|ofproto_dpif|INFO|system at ovs-system: Datapath supports ct_zone 2017-08-09T14:13:58.548Z|00018|ofproto_dpif|INFO|system at ovs-system: Datapath supports ct_mark 2017-08-09T14:13:58.548Z|00019|ofproto_dpif|INFO|system at ovs-system: Datapath supports ct_label 2017-08-09T14:13:58.548Z|00020|ofproto_dpif|INFO|system at ovs-system: Datapath supports ct_state_nat 2017-08-09T14:13:58.548Z|00021|ofproto_dpif|INFO|system at ovs-system: Datapath does not support ct_orig_tuple 2017-08-09T14:13:58.786Z|00001|ofproto_dpif_upcall(handler1)|INFO|received packet on unassociated datapath port 0 2017-08-09T14:13:58.786Z|00022|ofproto|WARN|br-ex: ignoring port br-ex (65535) because netdev br-ex cannot be opened (File exists) 2017-08-09T14:13:58.786Z|00023|bridge|INFO|bridge br-ex: added interface ens785f3 on port 1 2017-08-09T14:13:58.786Z|00024|bridge|WARN|could not open network device br-ex (File exists) 2017-08-09T14:13:58.786Z|00025|bridge|INFO|bridge br-ex: added interface br-ex-int-patch on port 2 2017-08-09T14:13:58.786Z|00026|bridge|INFO|bridge br-int: added interface br-int on port 65534 2017-08-09T14:13:58.786Z|00027|bridge|INFO|bridge br-int: added interface br-ex-patch on port 1 2017-08-09T14:13:58.786Z|00028|bridge|INFO|bridge br-ex: using datapath ID 00006805ca326293 2017-08-09T14:13:58.787Z|00029|in_band|ERR|br-ex: failed to initialize in-band control: cannot open datapath local port br-ex (File exists) ovs-vswitchd (Open vSwitch) 2.7.90 Built from source: OVS_BRANCH: bf090264e68d160d0ae70ebc93d59bc09d34cc8b OVS_REPO: http://github.com/openvswitch/ovs cat /proc/version Linux version 3.10.0-514.el7.x86_64 (builder at kbuilder.dev.centos.org) (gcc version 4.8.5 20150623 (Red Hat 4.8.5-11) (GCC) ) #1 SMP Tue Nov 22 16:42:41 UTC 2016 Centos 7.3 -------------------------------------------------------------- Intel Research and Development Ireland Limited Registered in Ireland Registered Office: Collinstown Industrial Park, Leixlip, County Kildare Registered Number: 308263 This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. -------------- next part -------------- An HTML attachment was scrubbed... URL: From blp at ovn.org Wed Aug 9 16:25:17 2017 From: blp at ovn.org (Ben Pfaff) Date: Wed, 9 Aug 2017 09:25:17 -0700 Subject: [ovs-discuss] [ovs-dev] Why my AT_CHECK() can't work? In-Reply-To: References: Message-ID: <20170809162517.GN6175@ovn.org> On Wed, Aug 09, 2017 at 05:23:20PM +0800, Sam wrote: > Hi all, > > I'm using autotest to test ovs, and I write a new *.at file using only one > AT_CHECK sentence like this: > > AT_CHECK([ovs-appctl dpdk/bond-show dpdkb2], [0], [stdout]) > > AT_CHECK([[sed '/ACTIVE/p' stdout | head -4]], [0], [[LACP actor_state > > ACTIVE AGGREGATION SYNC COLLECTING DISTRIBUTING > > partner_state ACTIVE AGGREGATION SYNC COLLECTING DISTRIBUTING > > LACP actor_state ACTIVE AGGREGATION SYNC COLLECTING DISTRIBUTING > > partner_state ACTIVE AGGREGATION SYNC COLLECTING DISTRIBUTING]]) > I think you forgot -n in your sed command. From blp at ovn.org Wed Aug 9 17:21:51 2017 From: blp at ovn.org (Ben Pfaff) Date: Wed, 9 Aug 2017 10:21:51 -0700 Subject: [ovs-discuss] ovs-vswitchd crash during startup when br-ex has assigned IP address and br-ex is UP In-Reply-To: References: Message-ID: <20170809172151.GQ6175@ovn.org> On Wed, Aug 09, 2017 at 03:54:50PM +0000, Prokes, JiriX X wrote: > We are using kolla/kolla-ansible to deploy openstack. > Used configuration is ovs + vxlan + old (Opendaylight) > > Opendaylight needs to have IP address assigned to br-ex bridge to enable connectivity via floatingIP to VMs. > Ovs is running in docker container. > After deployment ovs container is up and running and br-ex is in state DOWN > ip addr show br-ex > 12: br-ex: mtu 1500 qdisc noqueue state DOWN qlen 1000 > link/ether 68:05:ca:32:62:93 brd ff:ff:ff:ff:ff:ff > Then we assign IP and set it UP > > ip addr show br-ex > 12: br-ex: mtu 1500 qdisc noqueue state UNKNOWN qlen 1000 > link/ether 68:05:ca:3a:19:33 brd ff:ff:ff:ff:ff:ff > inet 10.0.2.16/24 scope global br-ex > valid_lft forever preferred_lft forever > inet6 fe80::6a05:caff:fe3a:1933/64 scope link > valid_lft forever preferred_lft forever > > Then ovs container is restarted > docker restart openvswitch-vswitchd > > Which cause ovs-vswitchd crash. Thank you for the report. I believe that this is the bug fixed by the following commit. This bug fix is on master, in 2.7.2, and in the branch for the upcoming 2.8.0 release. commit 66a9ef7a87f77a25ed568f55c1789eb6075b6abe Author: Ben Pfaff Date: Mon Jul 17 09:54:54 2017 -0700 connmgr: Fix crash when in_band_create() fails. update_in_band_remotes() created an in-band manager and then tried to work with it without first checking whether creation had succeeded. If it failed, this led to a segfault. Reported-by: Numan Siddique Reported-at: https://mail.openvswitch.org/pipermail/ovs-dev/2017-July/335530.html Signed-off-by: Ben Pfaff Acked-by: Justin Pettit From blp at ovn.org Wed Aug 9 20:20:14 2017 From: blp at ovn.org (Ben Pfaff) Date: Wed, 9 Aug 2017 13:20:14 -0700 Subject: [ovs-discuss] TLS and SNI support In-Reply-To: References: Message-ID: <20170809202014.GG6175@ovn.org> On Mon, Aug 07, 2017 at 11:41:27AM -0700, Shivaram Mysore wrote: > Does OVS have plans to support SSL with SNI (Server Name Indication) [1] > > [1] > https://wiki.openssl.org/index.php/SSL_and_TLS_Protocols#Server_Name_Indication As we talked about yesterday, this is easy from the client side once DNS is supported. We're talking about targeting DNS support as a feature for OVS 2.9. From shivaram.mysore at gmail.com Wed Aug 9 20:21:11 2017 From: shivaram.mysore at gmail.com (Shivaram Mysore) Date: Wed, 9 Aug 2017 13:21:11 -0700 Subject: [ovs-discuss] TLS and SNI support In-Reply-To: <20170809202014.GG6175@ovn.org> References: <20170809202014.GG6175@ovn.org> Message-ID: Excellent. Thanks very much Ben. Regards /Shivaram On Wed, Aug 9, 2017 at 1:20 PM, Ben Pfaff wrote: > On Mon, Aug 07, 2017 at 11:41:27AM -0700, Shivaram Mysore wrote: > > Does OVS have plans to support SSL with SNI (Server Name Indication) [1] > > > > [1] > > https://wiki.openssl.org/index.php/SSL_and_TLS_Protocols#Server_Name_ > Indication > > As we talked about yesterday, this is easy from the client side once DNS > is supported. We're talking about targeting DNS support as a feature > for OVS 2.9. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chiuchuihui at gmail.com Wed Aug 9 21:05:39 2017 From: chiuchuihui at gmail.com (Chui Hui Chiu) Date: Wed, 9 Aug 2017 16:05:39 -0500 Subject: [ovs-discuss] Starting point for extending OVS Message-ID: Hello, We are students trying to extend OVS in the Linux environment for our research works. We have primitive understandings of OVS after reading the documents. However, we are uncertain whether we are on the adequate track. The new features of our design and our speculated starting points are 1) Feature Collecting statistics (e.g. total bytes transferred) at each switch port. Speculated starting point netdev_linux_get_stats() in lib/netdev-linux.c 2) Feature Post processing statistics collected in (1). Speculated starting point lib/dpif-netlink.c Adding our algorithm. 3) Feature In-band exchange of processed statistics in (2) between OVSs. Speculated starting point lib/dpif-netlink.c We still do not know how to inject our own control packets into datapath. Do we have to trace how OVS processes the "PACKET_OUT" OpenFlow message? 4) Feature Good performance comparable to original OVS. Speculated starting point lib/dpif-netlink.c and datapath/datapath.c Customizing existing dpif to call only kernel-level functions in datapath/ to achieve (1), (2), and (3). Please give your valuable suggestions and comments. Many thanks in advance! -------------- next part -------------- An HTML attachment was scrubbed... URL: From aarcane at aarcane.org Wed Aug 9 23:36:37 2017 From: aarcane at aarcane.org (Schlacta, Christopher) Date: Wed, 9 Aug 2017 16:36:37 -0700 Subject: [ovs-discuss] Strange behaviour with VLANs and Bridges and ARP. In-Reply-To: References: <2475cf0a-5fe9-7b57-2a65-cb81ab2118cf@gmail.com> Message-ID: My configuration looks like this: Smart switch --on shelf. --- br0 --on density <-- Inbound ARP requests for 'lan' IP appear here. --- --- lan --on density, assigned vlan 10, lan IP <-- Inbound ARP requests for 'lan' IP DO NOT appear here. No response is sent. ---br0 --on densetsu --- ---lan --on densetsu, Assigned vlan 10 Additionally, any other PC on vlan 10 is unable to ping into density or densetsu until the respective destination pings out to the respective origin. After the client has it's ARP table populated, all communication flows seamlessly. Furthermore, the "lan" interfaces always have different MAC addresses and reject manual MAC assignments from wicked. (Open suse server network management system), so I can't just pre-fill ethers file on the various client systems. On Wed, Aug 9, 2017 at 7:54 AM, Blue Lang wrote: > The only place I've seen this is with VMWARE vswitch not forwarding ARP on > ESX. That doesn't sound like it's any part of your issue. > > When you say "smart switch using openvswitch," what do you mean exactly? > > Thanks, > > On Tue, Aug 8, 2017 at 11:44 PM, Ricky wrote: >> >> I have run into a similar problem myself and have not found the solution. >> The ARP traffic from one direction makes it to OVS, but does not get sent to >> device it needs to go to. It my case OVS pretty much isn't sending any ARP >> packets out from itself except to the other OVS instances I have a GRE >> tunnel with. I'm running version 2.5.0. >> >> Please let me know if you made any progress on your issue. >> >> >> On 08/07/2017 07:19 PM, Schlacta, Christopher wrote: >>> >>> Ping. Anybody? Hello? >>> >>> On Wed, Aug 2, 2017 at 10:32 PM, Schlacta, Christopher >>> wrote: >>>> >>>> So this is a bit hard to explain, but I hope you'll follow. I have >>>> two hosts, density and densetsu. they each host VMs and CEPH nodes >>>> using libvirt and ceph and they're connected to a smart switch using >>>> openvswitch and there are a bunch of VLANs. 5, 6, 10, 20, and 30. >>>> Most "normal" traffic goes along VLAN 10. That's just the LAN VLAN. >>>> So here's what the ovs-vsctl show looks like on each host: >>>> >>>> >>>> density: >>>> aarcane at density:~$ sudo ovs-vsctl show >>>> YubiKey for `aarcane': >>>> f2ae0266-6cae-44f0-8ca5-9d6f66562ff4 >>>> Bridge "br0" >>>> Port lan >>>> tag: 10 >>>> Interface lan >>>> type: internal >>>> Port "vnet0" >>>> trunks: [5, 6, 10, 20, 30] >>>> Interface "vnet0" >>>> Port "eth1" >>>> Interface "eth1" >>>> Port "vnet1" >>>> trunks: [5, 6, 10, 20, 30] >>>> Interface "vnet1" >>>> Port "br0" >>>> Interface "br0" >>>> type: internal >>>> ovs_version: "2.7.0" >>>> >>>> >>>> densetsu: >>>> aarcane at densetsu:~$ sudo ovs-vsctl show >>>> 2d6843ee-2bb6-48b8-a979-ba7f64bf5ebc >>>> Bridge "br0" >>>> Port "eth0" >>>> Interface "eth0" >>>> Port lan >>>> tag: 10 >>>> Interface lan >>>> type: internal >>>> Port "br0" >>>> Interface "br0" >>>> type: internal >>>> ovs_version: "2.7.0" >>>> >>>> >>>> The problem is when I try to ping the opposite machine (densetsu to >>>> density or vice versa), the ARP packets get sent with appropriate >>>> information through BR0 and out the eth device all tagged with VLAN >>>> 10, but the *inbound* arp packet is never sent to the lan interface. >>>> I see it at the br0 and the eth interface, but not the destination >>>> host's lan interface. Furthermore, the destination never seems to see >>>> this or respond to it, so it's then impossible for the to initiate >>>> contact without adding entries to the ethers file. >>>> >>>> This is well and good, but it also means that other systems on the >>>> network also cannot connect to them for purposes of administration and >>>> management, and this is very problematic. >>>> >>>> I've not made any changes to openflow. They've been able to >>>> communicate with each other for a long time. This change happened >>>> with a recent kernel upgrade. Not sure how to fix it or if it's a >>>> bug. Again, note: All IP traffic seems to work fine. ICMP works >>>> without issue, TCP, etc. It's only the ARP protocol that seems to not >>>> be passing inward when it should be. >>> >>> _______________________________________________ >>> discuss mailing list >>> discuss at openvswitch.org >>> https://mail.openvswitch.org/mailman/listinfo/ovs-discuss >> >> >> >> _______________________________________________ >> discuss mailing list >> discuss at openvswitch.org >> https://mail.openvswitch.org/mailman/listinfo/ovs-discuss > > > > > -- > Blue Lang > PM | Veracity > > 3423 Piedmont Rd NE > > Suite 350 > > Atlanta, GA 30305 > > Cell: (770) 265-1381 > https://www.linkedin.com/in/bluelang/ > blue at veracity.io > www.veracity.io > > _______________________________________________ > discuss mailing list > discuss at openvswitch.org > https://mail.openvswitch.org/mailman/listinfo/ovs-discuss > From arunkumar.rg at gmail.com Thu Aug 10 00:34:58 2017 From: arunkumar.rg at gmail.com (Arunkumar Rg) Date: Thu, 10 Aug 2017 06:04:58 +0530 Subject: [ovs-discuss] ovsdb-server replication: Does not work when set-sync-exclude-tables option is used Message-ID: Hi, Issue summary: -------------- On setting, "ovsdb-server/set-sync-exclude-tables" for certain tables, ovsdb-server replication does not work. i.e the ovsdb-server which connects to the active ovsdb-server doesn't become 'backup'. Expected: --------- ovsdb-server which connects to active ovsdb-server should become 'backup' and recieve sync for all the tables except for the tables specified in the ctl command "ovsdb-server/set-sync-exclude-tables". Reproduction steps: ------------------- ["db:Hardware_vtep"---OVSDB-SERVER(Active)-(ptcp:3.1.1.2:7000 )-]------------------[-OVSDB-SERVER(Backup)---"db:Hardware_vtep"] 1. Start two ovsdb-server instances with db schema as "Hardware_vtep". Lets call them instance-1 and instance-2. ps -ef | grep ovsdb-server root 2704 2093 0 19:56 ? 00:00:03 ovsdb-server /opt/ovsdb/db/vtep.db --remote=punix:/opt/ovsdb/db/db.sock --unixctl=/opt/ovsdb/ovsdb-server.ctl 2. At instance-1: Add an entry in 'Manager' table. vtep-ctl --db=unix:/opt/ovsdb/db/db.sock set-manager ssl: 10.133.130.126:6640 ovsdb-client dump unix:/opt/ovsdb/db/db.sock <<---showing only the tables which is relevant to this issue. Global table _uuid managers other_config switches ------------------------------------ -------------------------------------- ------------ -------- 4121ba6c-a729-45b1-8f69-806b32584d04 [73affd9e-07f0-422f-a394-47ae2a1ab499] {} Manager table _uuid inactivity_probe is_connected max_backoff other_config status target ------------------------------------ ---------------- ------------ ----------- ------------ ------- ------------------------- 73affd9e-07f0-422f-a394-47ae2a1ab499 [] false [] {} "ssl:10.133.130.126:6640" 3. Now do ovsdb replication related configs: 3.1. At instance-1: ovs-appctl -t /opt/ovsdb/ovsdb-server.ctl ovsdb-server/add-remote ptcp:7000:3.1.1.2 3.2 At instance-2: ovs-appctl -t /opt/ovsdb/ovsdb-server.ctl ovsdb-server/set-active-ovsdb-server tcp:3.1.1.2:7000 ovs-appctl -t /opt/ovsdb/ovsdb-server.ctl ovsdb-server/set-sync-exclude-tables hardware_vtep:Manager ovs-appctl -t /opt/ovsdb/ovsdb-server.ctl ovsdb-server/connect-active-ovsdb-server 4. Issue reproduced now!! Instance-2 will not become 'Backup' and it'll remain in 'Active' state. This seem to be due to the following error, while processing the notification for 'Global' table: "Aug 9 12:26:38 Pollux daemon.err ovsdb-server: ovs|00070|ovsdb_error|ERR|unexpected ovsdb error: referential integrity violation: Table Global column managers row 4121ba6c-a729-45b1-8f69-806b32584d04 references nonexistent row 5dbedec1-8221-435f-89b3-503867d0e987 in t" Note: In the hardware_vtep schema, 'Global' table has a reference to 'Manager' table. Additional inputs: ------------------ bash-3.2# ovsdb-server --version ovsdb-server (Open vSwitch) 2.7.0 Linux version 4.1.14 Thanks, Arun. -------------- next part -------------- An HTML attachment was scrubbed... URL: From arunkumar.rg at gmail.com Thu Aug 10 00:42:37 2017 From: arunkumar.rg at gmail.com (Arunkumar Rg) Date: Thu, 10 Aug 2017 06:12:37 +0530 Subject: [ovs-discuss] How to subscribe to bugs@openvswitch.org?? Message-ID: Hi, I have one basic question: In the below page, I see subscribe option for most of the mailing lists except for bugs and security. So if I want to subscribe to the mailing list 'bugs', what should I do?? Thanks, Arun. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jpettit at ovn.org Thu Aug 10 07:04:09 2017 From: jpettit at ovn.org (Justin Pettit) Date: Thu, 10 Aug 2017 00:04:09 -0700 Subject: [ovs-discuss] How to subscribe to bugs@openvswitch.org?? In-Reply-To: References: Message-ID: > On Aug 9, 2017, at 5:42 PM, Arunkumar Rg wrote: > > Hi, > > I have one basic question: > > In the below page, I see subscribe option for most of the mailing lists except for bugs and security. > > So if I want to subscribe to the mailing list 'bugs', what should I do?? "bugs" just forwards to this "discuss" mailing list. The "security" mailing list is invitation-only, and has a very limited number of members to handle security incidents. Hope that helps. --Justin From WBAHACER at 126.com Thu Aug 10 13:21:58 2017 From: WBAHACER at 126.com (Furong) Date: Thu, 10 Aug 2017 21:21:58 +0800 Subject: [ovs-discuss] How to make OVS working with IVSHMEM ? Message-ID: Hello, I encounter a problem with running ovs with IVSHMEM. I've followed the guide of INSTALL.DPDK.md of ovs-2.5.0 to use IVSHMEM. Firstly, I started ovs-vswitchd using "./sbin/ovs-vswitchd --dpdk -c 0x1 -n 4 --proc-type=primary -- --pidfile --detach", and I added dpdk ports(dpdk0,dpdk1) and dpdk rings(dpdkr0) to ovs. Then, I started ./openvswitch-2.5.0/tests/test-dpdkr using "./test-dpdkr -c 1 -n 4 --proc-type=secondary -- -n 0", but the EAL initialization of this program was stucked at " EAL: Detected 16 lcore(s)" Does anybody has successful experience with running ovs with IVSHMEM? Please share with me. Many thanks!!! From jiaojianbing at huawei.com Fri Aug 11 06:24:35 2017 From: jiaojianbing at huawei.com (Jiaojianbing) Date: Fri, 11 Aug 2017 06:24:35 +0000 Subject: [ovs-discuss] question about mtu of vxlan port Message-ID: dear, There is a question about mtu of vxlan port. In below scene, there are two node(compute or vm), and we send udp packets between two docker with nic?s(eth0) mtu setting to 1500. Vxlan port?s mtu is 65485 setting in ovs code(we don?t change it). It works well that packet can be sent and receive to/from other docker. But we add conntrack flow table in interface of one bridge, such as: ovs-ofctl add-flow $1 "table=0,arp,action=resubmit(,1)" ovs-ofctl add-flow $1 "table=0,ip,action=ct(commit,zone=1,table=1)" ovs-ofctl add-flow $1 "table=1,actions=NORMAL" 1? It is ok with packet length <= 1450 bytes; 2? but when we send packet length > 1450 bytes, such as 2000 bytes, the packet will be dropped at the vxlan port in the sending node. 3? if we modi the mtu of vxlan port from 65485 to 1450, it works well when packet length >=1450. First when send big udp packet(len>1450), it will be fragged when send from one docker. when add conntrack flow table, udp packet(length>1450) will be deal with do_execute_actions in which ?case OVS_ACTION_ATTR_CT? will be called. In this switch case, handle_fragments routine is called to defrag udp frags. When packet comes to vxlan port, packet is aggregated to one packet with length >1450, then it is compared with mtu of vxlan port, it is less than 65485(mtu length of vxlan port) so it does not frag and pass through to eth0 (mtu=1450), then in routine output_ip it return error code of -90. When no conntrack flow table is added, big udp packet will not go through ?case OVS_ACTION_ATTR_CT? in do_execute_actions, then defrag will not been done. So eack frags with lengh 1450, can go through vxlan port and eth0. so my question is, why the mtu of vxlan port is set to 65485(so big!), and can it be modified to 1450? [cid:image001.png at 01D312A9.51C60020] -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 21279 bytes Desc: image001.png URL: From swethaj.10 at gmail.com Fri Aug 11 06:26:20 2017 From: swethaj.10 at gmail.com (swetha Jagadish) Date: Fri, 11 Aug 2017 11:56:20 +0530 Subject: [ovs-discuss] Error reported : When Group Add Request size exceeds 65535 Message-ID: Hi, When i try to add a group with 3000 action buckets, error is observered *[2017-07-31 12:05:00.823] ovs-vswitchd: ovs|00607|ofp_util|WARN|OpenFlow message bucket length 40 exceeds remaining buckets data size 24* *[2017-07-31 12:05:00.823] ovs-vswitchd: ovs|00608|connmgr|INFO|br0<->unix: sending OFPGMFC_BAD_BUCKET error reply to OFPT_GROUP_MOD message* When debugged further, i could see that since the since the bucket_lenght > 65000 this error is observed as this is the maximum message size supported. Need suggestions to overcome on the above issue. --Much thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: From jiaojianbing at huawei.com Fri Aug 11 06:46:37 2017 From: jiaojianbing at huawei.com (Jiaojianbing) Date: Fri, 11 Aug 2017 06:46:37 +0000 Subject: [ovs-discuss] question about mtu of vxlan port Message-ID: dear, There is a question about mtu of vxlan port. In below scene, there are two node(compute or vm), and we send udp packets between two docker with nic?s(eth0) mtu setting to 1500. Vxlan port?s mtu is 65485 setting in ovs code(we don?t change it). It works well that packet can be sent and receive to/from other docker. But we add conntrack flow table in interface of one bridge, such as: ovs-ofctl add-flow $1 "table=0,arp,action=resubmit(,1)" ovs-ofctl add-flow $1 "table=0,ip,action=ct(commit,zone=1,table=1)" ovs-ofctl add-flow $1 "table=1,actions=NORMAL" 1? It is ok with packet length <= 1450 bytes; 2? but when we send packet length > 1450 bytes, such as 2000 bytes, the packet will be dropped at the vxlan port in the sending node. 3? if we modi the mtu of vxlan port from 65485 to 1450, it works well when packet length >=1450. First when send big udp packet(len>1450), it will be fragged when send from one docker. when add conntrack flow table, udp packet(length>1450) will be deal with do_execute_actions in which ?case OVS_ACTION_ATTR_CT? will be called. In this switch case, handle_fragments routine is called to defrag udp frags. When packet comes to vxlan port, packet is aggregated to one packet with length >1450, then it is compared with mtu of vxlan port, it is less than 65485(mtu length of vxlan port) so it does not frag and pass through to eth0 (mtu=1450), then in routine output_ip it return error code of -90. When no conntrack flow table is added, big udp packet will not go through ?case OVS_ACTION_ATTR_CT? in do_execute_actions, then defrag will not been done. So eack frags with lengh 1450, can go through vxlan port and eth0. so my question is, why the mtu of vxlan port is set to 65485(so big!), and can it be modified to 1450? [scene]: [ Docker0] [ Docker1] | | [br_int] [br_int] | | [br_tunnel] [br_tunnel] | | | [vxlan port] | [vxlan port] | | | [eth0] - - - - - - - - |- - - - - - - - - - -- -- - [eth0] | node1 | node 2 -------------- next part -------------- An HTML attachment was scrubbed... URL: From vivek.v.srivastava at ericsson.com Fri Aug 11 08:48:20 2017 From: vivek.v.srivastava at ericsson.com (Vivek Srivastava V) Date: Fri, 11 Aug 2017 08:48:20 +0000 Subject: [ovs-discuss] BFD with 'option : remote_ip = flow' Message-ID: Hi, We are creating VxLAN tunnel port/interface in OVS with option : remote_ip = flow and the tunnel remote_ip is set using openflow rules. This works well, however with this option we cannot use the BFD monitoring for multiple remote TEPs, with BFD config/status interface available in interface table (as we have only one tunnel interface in this case). So I have following questions - 1. Is there any way to configure/manage BFD sessions to destinations, independent of the tunnel port/interface created? 2. Does OVS support multi-hop BFD? In roadmap? Regards, Vivek -------------- next part -------------- An HTML attachment was scrubbed... URL: From anton.gulenko at tu-berlin.de Fri Aug 11 10:56:59 2017 From: anton.gulenko at tu-berlin.de (Gulenko, Anton) Date: Fri, 11 Aug 2017 10:56:59 +0000 Subject: [ovs-discuss] Inband Network Telemetry with OVS Message-ID: <51bb4d50ea5f402a97a4c58b009281dc@ex-mbx-09.tubit.win.tu-berlin.de> Dear OVS devs and community, I would like to experiment with Inband Network Telemtry (INT) on OVS (http://p4.org/wp-content/uploads/fixed/INT/INT-current-spec.pdf). So far I did not find any direct support for this, so my first question is: did I miss something? If not, my second question is: where would you suggest to start? I found some prototyping effort on making a P4-enabled OVS (https://github.com/blp/ovs-reviews/releases/tag/p4-workshop), but it seems very rudimentary. So I suppose my best bet would be to dig into the datapath code and implement some prototypical INT support there? Are there any thoughts or plans on supporting P4's idea of INT in the OVS community? Cheers, Anton? -------------- next part -------------- An HTML attachment was scrubbed... URL: From blp at ovn.org Fri Aug 11 15:31:04 2017 From: blp at ovn.org (Ben Pfaff) Date: Fri, 11 Aug 2017 08:31:04 -0700 Subject: [ovs-discuss] Inband Network Telemetry with OVS In-Reply-To: <51bb4d50ea5f402a97a4c58b009281dc@ex-mbx-09.tubit.win.tu-berlin.de> References: <51bb4d50ea5f402a97a4c58b009281dc@ex-mbx-09.tubit.win.tu-berlin.de> Message-ID: <20170811153104.GJ6175@ovn.org> On Fri, Aug 11, 2017 at 10:56:59AM +0000, Gulenko, Anton wrote: > Dear OVS devs and community, > > I would like to experiment with Inband Network Telemtry (INT) on OVS (http://p4.org/wp-content/uploads/fixed/INT/INT-current-spec.pdf). > So far I did not find any direct support for this, so my first question is: did I miss something? > > If not, my second question is: where would you suggest to start? > I found some prototyping effort on making a P4-enabled OVS (https://github.com/blp/ovs-reviews/releases/tag/p4-workshop), but it seems very rudimentary. > So I suppose my best bet would be to dig into the datapath code and implement some prototypical INT support there? > > Are there any thoughts or plans on supporting P4's idea of INT in the OVS community? Probably, the best place to start for now is PISCES, which is a P4-enabled version of Open vSwitch: http://pisces.cs.princeton.edu/ From blp at ovn.org Fri Aug 11 15:42:51 2017 From: blp at ovn.org (Ben Pfaff) Date: Fri, 11 Aug 2017 08:42:51 -0700 Subject: [ovs-discuss] Error reported : When Group Add Request size exceeds 65535 In-Reply-To: References: Message-ID: <20170811154251.GK6175@ovn.org> On Fri, Aug 11, 2017 at 11:56:20AM +0530, swetha Jagadish wrote: > When i try to add a group with 3000 action buckets, error is observered > > > *[2017-07-31 12:05:00.823] ovs-vswitchd: ovs|00607|ofp_util|WARN|OpenFlow > message bucket length 40 exceeds remaining buckets data size 24* > > *[2017-07-31 12:05:00.823] ovs-vswitchd: ovs|00608|connmgr|INFO|br0<->unix: > sending OFPGMFC_BAD_BUCKET error reply to OFPT_GROUP_MOD message* > > When debugged further, i could see that since the since the bucket_lenght > > 65000 this error is observed as this is the maximum message size > supported. > > Need suggestions to overcome on the above issue. You can add the buckets a few at a time. From blp at ovn.org Fri Aug 11 15:53:31 2017 From: blp at ovn.org (Ben Pfaff) Date: Fri, 11 Aug 2017 08:53:31 -0700 Subject: [ovs-discuss] BFD with 'option : remote_ip = flow' In-Reply-To: References: Message-ID: <20170811155331.GL6175@ovn.org> On Fri, Aug 11, 2017 at 08:48:20AM +0000, Vivek Srivastava V wrote: > 1. Is there any way to configure/manage BFD sessions to destinations, > independent of the tunnel port/interface created? Not currently. If you have a good idea for how to extend the OVS BFD support to be more flexible, we'd accept patches. > 2. Does OVS support multi-hop BFD? In roadmap? No. I hadn't heard of multi-hop BFD before, so I looked around a bit and found RFC 5883. That RFC, though, doesn't really provide a specification for how to do this. Is there a detailed specification somewhere else? From pssharma at rocketmail.com Fri Aug 11 18:52:16 2017 From: pssharma at rocketmail.com (Prem Shankar Sharma) Date: Fri, 11 Aug 2017 18:52:16 +0000 (UTC) Subject: [ovs-discuss] getting build errors while building ovs2.7.0 References: <839487988.78900.1502477536287.ref@mail.yahoo.com> Message-ID: <839487988.78900.1502477536287@mail.yahoo.com> Hi,I'm getting some build errors while trying to build ovs2.7.0 on redhat 7.2. I cloned 2.7.0 from git and tried to run - make and make modules_install (to build kernel module). The output of both of them is reporting some issues like: .../root/nf/ovs2.7/ovs/datapath/linux/compat/include/linux/netdevice.h:113:2: error: too few arguments to function ?netdev_master_upper_dev_link_rh?/root/nf/ovs2.7/ovs/datapath/linux/compat/include/linux/netdevice.h:115:0: warning: "netdev_master_upper_dev_link" redefined [enabled by default] ...depmod: WARNING: /lib/modules/3.10.0-693.el7.x86_64/kernel/net/openvswitch/vport-vxlan.ko.xz needs unknown symbol ovs_netdev_link depmod: WARNING: /lib/modules/3.10.0-693.el7.x86_64/kernel/net/openvswitch/vport-vxlan.ko.xz needs unknown symbol ovs_netdev_tunnel_destroy depmod: WARNING: /lib/modules/3.10.0-693.el7.x86_64/kernel/net/openvswitch/vport-vxlan.ko.xz needs unknown symbol __ovs_vport_ops_register ,,,depmod: WARNING: /lib/modules/3.10.0-693.el7.x86_64/kernel/net/openvswitch/vport-geneve.ko.xz needs unknown symbol ovs_netdev_link depmod: WARNING: /lib/modules/3.10.0-693.el7.x86_64/kernel/net/openvswitch/vport-geneve.ko.xz needs unknown symbol ovs_netdev_tunnel_destroy depmod: WARNING: /lib/modules/3.10.0-693.el7.x86_64/kernel/net/openvswitch/vport-geneve.ko.xz needs unknown symbol __ovs_vport_ops_register ...depmod: WARNING: /lib/modules/3.10.0-693.el7.x86_64/kernel/net/openvswitch/vport-gre.ko.xz needs unknown symbol ovs_netdev_link depmod: WARNING: /lib/modules/3.10.0-693.el7.x86_64/kernel/net/openvswitch/vport-gre.ko.xz needs unknown symbol ovs_netdev_tunnel_destroy make[2]: Leaving directory `/usr/src/kernels/3.10.0-693.el7.x86_64' ... Running make install on the other hand goes fine without any issue. Could someone please suggest some soln., workaround? Am I missing something? ? Here's the detailed output: [root at compute-b ovs]# uname -a Linux compute-b 3.10.0-693.el7.x86_64 #1 SMP Thu Jul 6 19:56:57 EDT 2017 x86_64 x86_64 x86_64 GNU/Linux [root at compute-b ovs]# make make? all-recursive make[1]: Entering directory `/root/nf/ovs2.7/ovs' Making all in datapath make[2]: Entering directory `/root/nf/ovs2.7/ovs/datapath' Making all in linux make[3]: Entering directory `/root/nf/ovs2.7/ovs/datapath/linux' make -C /lib/modules/3.10.0-693.el7.x86_64/build M=/root/nf/ovs2.7/ovs/datapath/linux modules make[4]: Entering directory `/usr/src/kernels/3.10.0-693.el7.x86_64' ? CC [M]? /root/nf/ovs2.7/ovs/datapath/linux/actions.o In file included from include/net/inet_sock.h:24:0, ???????????????? from include/net/ip.h:30, ???????????????? from /root/nf/ovs2.7/ovs/datapath/linux/compat/include/net/ip.h:4, ???????????????? from /root/nf/ovs2.7/ovs/datapath/linux/compat/include/linux/netfilter_ipv6.h:7, ???????????????? from /root/nf/ovs2.7/ovs/datapath/linux/actions.c:25: /root/nf/ovs2.7/ovs/datapath/linux/compat/include/linux/netdevice.h: In function ?rpl_netdev_master_upper_dev_link?: /root/nf/ovs2.7/ovs/datapath/linux/compat/include/linux/netdevice.h:113:2: error: too few arguments to function ?netdev_master_upper_dev_link_rh? ? return netdev_master_upper_dev_link(dev, upper_dev); ? ^ In file included from /root/nf/ovs2.7/ovs/datapath/linux/compat/include/linux/netdevice.h:4:0, ???????????????? from include/net/inet_sock.h:24, ???????????????? from include/net/ip.h:30, ???????????????? from /root/nf/ovs2.7/ovs/datapath/linux/compat/include/net/ip.h:4, ???????????????? from /root/nf/ovs2.7/ovs/datapath/linux/compat/include/linux/netfilter_ipv6.h:7, ???????????????? from /root/nf/ovs2.7/ovs/datapath/linux/actions.c:25: include/linux/netdevice.h:3884:5: note: declared here ?int netdev_master_upper_dev_link_rh(struct net_device *dev, ???? ^ In file included from include/net/inet_sock.h:24:0, ???????????????? from include/net/ip.h:30, ???????????????? from /root/nf/ovs2.7/ovs/datapath/linux/compat/include/net/ip.h:4, ???????????????? from /root/nf/ovs2.7/ovs/datapath/linux/compat/include/linux/netfilter_ipv6.h:7, ???????????????? from /root/nf/ovs2.7/ovs/datapath/linux/actions.c:25: /root/nf/ovs2.7/ovs/datapath/linux/compat/include/linux/netdevice.h: At top level: /root/nf/ovs2.7/ovs/datapath/linux/compat/include/linux/netdevice.h:115:0: warning: "netdev_master_upper_dev_link" redefined [enabled by default] ?#define netdev_master_upper_dev_link rpl_netdev_master_upper_dev_link ?^ In file included from /root/nf/ovs2.7/ovs/datapath/linux/compat/include/linux/netdevice.h:4:0, ???????????????? from include/net/inet_sock.h:24, ???????????????? from include/net/ip.h:30, ???????????????? from /root/nf/ovs2.7/ovs/datapath/linux/compat/include/net/ip.h:4, ???????????????? from /root/nf/ovs2.7/ovs/datapath/linux/compat/include/linux/netfilter_ipv6.h:7, ???????????????? from /root/nf/ovs2.7/ovs/datapath/linux/actions.c:25: include/linux/netdevice.h:3887:0: note: this is the location of the previous definition ?#define netdev_master_upper_dev_link netdev_master_upper_dev_link_rh ?^ make[5]: *** [/root/nf/ovs2.7/ovs/datapath/linux/actions.o] Error 1 make[4]: *** [_module_/root/nf/ovs2.7/ovs/datapath/linux] Error 2 make[4]: Leaving directory `/usr/src/kernels/3.10.0-693.el7.x86_64' make[3]: *** [default] Error 2 make[3]: Leaving directory `/root/nf/ovs2.7/ovs/datapath/linux' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/root/nf/ovs2.7/ovs/datapath' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/root/nf/ovs2.7/ovs' make: *** [all] Error 2 [root at compute-b ovs]# make install make? install-recursive make[1]: Entering directory `/root/nf/ovs2.7/ovs' Making install in datapath make[2]: Entering directory `/root/nf/ovs2.7/ovs/datapath' Making install in linux make[3]: Entering directory `/root/nf/ovs2.7/ovs/datapath/linux' make[3]: Nothing to be done for `install'. make[3]: Leaving directory `/root/nf/ovs2.7/ovs/datapath/linux' make[3]: Entering directory `/root/nf/ovs2.7/ovs/datapath' make[4]: Entering directory `/root/nf/ovs2.7/ovs/datapath' make[4]: Nothing to be done for `install-exec-am'. make[4]: Nothing to be done for `install-data-am'. make[4]: Leaving directory `/root/nf/ovs2.7/ovs/datapath' make[3]: Leaving directory `/root/nf/ovs2.7/ovs/datapath' make[2]: Leaving directory `/root/nf/ovs2.7/ovs/datapath' make[2]: Entering directory `/root/nf/ovs2.7/ovs' make[3]: Entering directory `/root/nf/ovs2.7/ovs/datapath' make[3]: `distfiles' is up to date. make[3]: Leaving directory `/root/nf/ovs2.7/ovs/datapath' make[3]: Entering directory `/root/nf/ovs2.7/ovs' ?/usr/bin/mkdir -p '/root/nf/ovs2.7/ovs/install/lib' ?/bin/sh ./libtool?? --mode=install /usr/bin/install -c?? lib/libopenvswitch.la lib/libsflow.la ofproto/libofproto.la ovsdb/libovsdb.la vtep/libvtep.la ovn/lib/libovn.la '/root/nf/ovs2.7/ovs/install/lib' libtool: install: /usr/bin/install -c lib/.libs/libopenvswitch.lai /root/nf/ovs2.7/ovs/install/lib/libopenvswitch.la libtool: install: /usr/bin/install -c lib/.libs/libsflow.lai /root/nf/ovs2.7/ovs/install/lib/libsflow.la libtool: install: /usr/bin/install -c ofproto/.libs/libofproto.lai /root/nf/ovs2.7/ovs/install/lib/libofproto.la libtool: install: /usr/bin/install -c ovsdb/.libs/libovsdb.lai /root/nf/ovs2.7/ovs/install/lib/libovsdb.la libtool: install: /usr/bin/install -c vtep/.libs/libvtep.lai /root/nf/ovs2.7/ovs/install/lib/libvtep.la libtool: install: /usr/bin/install -c ovn/lib/.libs/libovn.lai /root/nf/ovs2.7/ovs/install/lib/libovn.la libtool: install: /usr/bin/install -c lib/.libs/libopenvswitch.a /root/nf/ovs2.7/ovs/install/lib/libopenvswitch.a libtool: install: chmod 644 /root/nf/ovs2.7/ovs/install/lib/libopenvswitch.a libtool: install: ranlib /root/nf/ovs2.7/ovs/install/lib/libopenvswitch.a libtool: install: /usr/bin/install -c lib/.libs/libsflow.a /root/nf/ovs2.7/ovs/install/lib/libsflow.a libtool: install: chmod 644 /root/nf/ovs2.7/ovs/install/lib/libsflow.a libtool: install: ranlib /root/nf/ovs2.7/ovs/install/lib/libsflow.a libtool: install: /usr/bin/install -c ofproto/.libs/libofproto.a /root/nf/ovs2.7/ovs/install/lib/libofproto.a libtool: install: chmod 644 /root/nf/ovs2.7/ovs/install/lib/libofproto.a libtool: install: ranlib /root/nf/ovs2.7/ovs/install/lib/libofproto.a libtool: install: /usr/bin/install -c ovsdb/.libs/libovsdb.a /root/nf/ovs2.7/ovs/install/lib/libovsdb.a libtool: install: chmod 644 /root/nf/ovs2.7/ovs/install/lib/libovsdb.a libtool: install: ranlib /root/nf/ovs2.7/ovs/install/lib/libovsdb.a libtool: install: /usr/bin/install -c vtep/.libs/libvtep.a /root/nf/ovs2.7/ovs/install/lib/libvtep.a libtool: install: chmod 644 /root/nf/ovs2.7/ovs/install/lib/libvtep.a libtool: install: ranlib /root/nf/ovs2.7/ovs/install/lib/libvtep.a libtool: install: /usr/bin/install -c ovn/lib/.libs/libovn.a /root/nf/ovs2.7/ovs/install/lib/libovn.a libtool: install: chmod 644 /root/nf/ovs2.7/ovs/install/lib/libovn.a libtool: install: ranlib /root/nf/ovs2.7/ovs/install/lib/libovn.a libtool: finish: PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/root/bin:/sbin" ldconfig -n /root/nf/ovs2.7/ovs/install/lib ---------------------------------------------------------------------- Libraries have been installed in: ?? /root/nf/ovs2.7/ovs/install/lib If you ever happen to want to link against installed libraries in a given directory, LIBDIR, you must either use libtool, and specify the full pathname of the library, or use the `-LLIBDIR' flag during linking and do at least one of the following: ?? - add LIBDIR to the `LD_LIBRARY_PATH' environment variable ???? during execution ?? - add LIBDIR to the `LD_RUN_PATH' environment variable ???? during linking ?? - use the `-Wl,-rpath -Wl,LIBDIR' linker flag ?? - have your system administrator add LIBDIR to `/etc/ld.so.conf' See any operating system documentation about shared libraries for more information, such as the ld(1) and ld.so(8) manual pages. ---------------------------------------------------------------------- ?/usr/bin/mkdir -p '/root/nf/ovs2.7/ovs/install/bin' ? /bin/sh ./libtool?? --mode=install /usr/bin/install -c utilities/ovs-appctl utilities/ovs-testcontroller utilities/ovs-dpctl utilities/ovs-ofctl utilities/ovs-vsctl ovsdb/ovsdb-tool ovsdb/ovsdb-client vtep/vtep-ctl ovn/controller/ovn-controller ovn/controller-vtep/ovn-controller-vtep ovn/northd/ovn-northd ovn/utilities/ovn-nbctl ovn/utilities/ovn-sbctl ovn/utilities/ovn-trace '/root/nf/ovs2.7/ovs/install/bin' libtool: install: /usr/bin/install -c utilities/ovs-appctl /root/nf/ovs2.7/ovs/install/bin/ovs-appctl libtool: install: /usr/bin/install -c utilities/ovs-testcontroller /root/nf/ovs2.7/ovs/install/bin/ovs-testcontroller libtool: install: /usr/bin/install -c utilities/ovs-dpctl /root/nf/ovs2.7/ovs/install/bin/ovs-dpctl libtool: install: /usr/bin/install -c utilities/ovs-ofctl /root/nf/ovs2.7/ovs/install/bin/ovs-ofctl libtool: install: /usr/bin/install -c utilities/ovs-vsctl /root/nf/ovs2.7/ovs/install/bin/ovs-vsctl libtool: install: /usr/bin/install -c ovsdb/ovsdb-tool /root/nf/ovs2.7/ovs/install/bin/ovsdb-tool libtool: install: /usr/bin/install -c ovsdb/ovsdb-client /root/nf/ovs2.7/ovs/install/bin/ovsdb-client libtool: install: /usr/bin/install -c vtep/vtep-ctl /root/nf/ovs2.7/ovs/install/bin/vtep-ctl libtool: install: /usr/bin/install -c ovn/controller/ovn-controller /root/nf/ovs2.7/ovs/install/bin/ovn-controller libtool: install: /usr/bin/install -c ovn/controller-vtep/ovn-controller-vtep /root/nf/ovs2.7/ovs/install/bin/ovn-controller-vtep libtool: install: /usr/bin/install -c ovn/northd/ovn-northd /root/nf/ovs2.7/ovs/install/bin/ovn-northd libtool: install: /usr/bin/install -c ovn/utilities/ovn-nbctl /root/nf/ovs2.7/ovs/install/bin/ovn-nbctl libtool: install: /usr/bin/install -c ovn/utilities/ovn-sbctl /root/nf/ovs2.7/ovs/install/bin/ovn-sbctl libtool: install: /usr/bin/install -c ovn/utilities/ovn-trace /root/nf/ovs2.7/ovs/install/bin/ovn-trace ?/usr/bin/mkdir -p '/root/nf/ovs2.7/ovs/install/bin' ?/usr/bin/install -c utilities/ovs-docker utilities/ovs-pki utilities/ovs-dpctl-top utilities/ovs-l3ping utilities/ovs-parse-backtrace utilities/ovs-pcap utilities/ovs-tcpdump utilities/ovs-tcpundump utilities/ovs-test utilities/ovs-vlan-test ovn/utilities/ovn-docker-overlay-driver ovn/utilities/ovn-docker-underlay-driver '/root/nf/ovs2.7/ovs/install/bin' ?/usr/bin/mkdir -p '/root/nf/ovs2.7/ovs/install/sbin' ? /bin/sh ./libtool?? --mode=install /usr/bin/install -c utilities/ovs-vlan-bug-workaround vswitchd/ovs-vswitchd ovsdb/ovsdb-server '/root/nf/ovs2.7/ovs/install/sbin' libtool: install: /usr/bin/install -c utilities/ovs-vlan-bug-workaround /root/nf/ovs2.7/ovs/install/sbin/ovs-vlan-bug-workaround libtool: install: /usr/bin/install -c vswitchd/ovs-vswitchd /root/nf/ovs2.7/ovs/install/sbin/ovs-vswitchd libtool: install: /usr/bin/install -c ovsdb/ovsdb-server /root/nf/ovs2.7/ovs/install/sbin/ovsdb-server ?/usr/bin/mkdir -p '/root/nf/ovs2.7/ovs/install/sbin' ?/usr/bin/install -c utilities/bugtool/ovs-bugtool '/root/nf/ovs2.7/ovs/install/sbin' ?/usr/bin/mkdir -p '/root/nf/ovs2.7/ovs/install/bash_completion.d' ?/usr/bin/install -c utilities/ovs-appctl-bashcomp.bash utilities/ovs-vsctl-bashcomp.bash '/root/nf/ovs2.7/ovs/install/bash_completion.d' /usr/bin/mkdir -p /root/nf/ovs2.7/ovs/install/run/openvswitch /usr/bin/mkdir -p /root/nf/ovs2.7/ovs/install/lib/openvswitch/pki /usr/bin/mkdir -p /root/nf/ovs2.7/ovs/install/log/openvswitch /usr/bin/mkdir -p /root/nf/ovs2.7/ovs/install/openvswitch /usr/bin/mkdir -p /root/nf/ovs2.7/ovs/install/openvswitch for plugin in utilities/bugtool/plugins/kernel-info/openvswitch.xml utilities/bugtool/plugins/network-status/openvswitch.xml utilities/bugtool/plugins/system-configuration.xml utilities/bugtool/plugins/system-logs/openvswitch.xml utilities/bugtool/plugins/system-configuration/openvswitch.xml ovn/utilities/bugtool/plugins/network-status/ovn.xml; do \ ? stem=`echo "$plugin" | sed 's,ovn/,,'`; \ ? stem=`echo "$stem" | sed 's,utilities/bugtool/plugins/,,'`; \ ? dir=`expr "$stem" : '\(.*\)/[^/]*$'`; \ ? /usr/bin/mkdir -p "/root/nf/ovs2.7/ovs/install/share/openvswitch/bugtool-plugins/$dir"; \ ? /usr/bin/install -c -m 644 "./$plugin" "/root/nf/ovs2.7/ovs/install/share/openvswitch/bugtool-plugins/$stem"; \ done /usr/bin/mkdir -p python/ovs sed \ ??? -e '/^##/d' \ ??????????????? -e 's,[@]pkgdatadir[@],/root/nf/ovs2.7/ovs/install/share/openvswitch,g' \ ??????????????? -e 's,[@]RUNDIR[@],/root/nf/ovs2.7/ovs/install/run/openvswitch,g' \ ??????????????? -e 's,[@]LOGDIR[@],/root/nf/ovs2.7/ovs/install/log/openvswitch,g' \ ??????????????? -e 's,[@]bindir[@],/root/nf/ovs2.7/ovs/install/bin,g' \ ??????????????? -e 's,[@]sysconfdir[@],/root/nf/ovs2.7/ovs/install,g' \ ??????????????? -e 's,[@]DBDIR[@],/root/nf/ovs2.7/ovs/install/openvswitch,g' \ ??? < ./python/ovs/dirs.py.template \ ??? > python/ovs/dirs.py.tmp /usr/bin/mkdir -p /root/nf/ovs2.7/ovs/install/share/openvswitch/python/ovs /usr/bin/install -c -m 644 python/ovs/dirs.py.tmp /root/nf/ovs2.7/ovs/install/share/openvswitch/python/ovs/dirs.py rm python/ovs/dirs.py.tmp ?/usr/bin/mkdir -p '/root/nf/ovs2.7/ovs/install/share/man/man1' ?/usr/bin/install -c -m 644 utilities/ovs-pcap.1 utilities/ovs-tcpundump.1 ovsdb/ovsdb-tool.1 ovsdb/ovsdb-client.1 ovsdb/ovsdb-server.1 '/root/nf/ovs2.7/ovs/install/share/man/man1' ?/usr/bin/mkdir -p '/root/nf/ovs2.7/ovs/install/share/man/man5' ?/usr/bin/install -c -m 644 vswitchd/ovs-vswitchd.conf.db.5 vtep/vtep.5 ovn/ovn-sb.5 ovn/ovn-nb.5 '/root/nf/ovs2.7/ovs/install/share/man/man5' ?/usr/bin/mkdir -p '/root/nf/ovs2.7/ovs/install/share/man/man7' ?/usr/bin/install -c -m 644 lib/ovs-fields.7 ovn/ovn-architecture.7 '/root/nf/ovs2.7/ovs/install/share/man/man7' ?/usr/bin/mkdir -p '/root/nf/ovs2.7/ovs/install/share/man/man8' ?/usr/bin/install -c -m 644 utilities/ovs-appctl.8 utilities/ovs-ctl.8 utilities/ovs-testcontroller.8 utilities/ovs-dpctl.8 utilities/ovs-dpctl-top.8 utilities/ovs-l3ping.8 utilities/ovs-ofctl.8 utilities/ovs-parse-backtrace.8 utilities/ovs-pki.8 utilities/ovs-tcpdump.8 utilities/ovs-vlan-bug-workaround.8 utilities/ovs-test.8 utilities/ovs-vlan-test.8 utilities/ovs-vsctl.8 utilities/bugtool/ovs-bugtool.8 vswitchd/ovs-vswitchd.8 vtep/vtep-ctl.8 ovn/controller/ovn-controller.8 ovn/controller-vtep/ovn-controller-vtep.8 ovn/northd/ovn-northd.8 ovn/utilities/ovn-ctl.8 ovn/utilities/ovn-nbctl.8 ovn/utilities/ovn-sbctl.8 ovn/utilities/ovn-trace.8 '/root/nf/ovs2.7/ovs/install/share/man/man8' ?/usr/bin/mkdir -p '/root/nf/ovs2.7/ovs/install/share/openvswitch' ?/usr/bin/mkdir -p '/root/nf/ovs2.7/ovs/install/share/openvswitch/python/ovs/unixctl' ?/usr/bin/install -c -m 644? python/ovs/unixctl/__init__.py python/ovs/unixctl/client.py python/ovs/unixctl/server.py '/root/nf/ovs2.7/ovs/install/share/openvswitch/python/ovs/unixctl' ?/usr/bin/mkdir -p '/root/nf/ovs2.7/ovs/install/share/openvswitch/python/ovs/db' ?/usr/bin/install -c -m 644? python/ovs/db/__init__.py python/ovs/db/data.py python/ovs/db/error.py python/ovs/db/idl.py python/ovs/db/parser.py python/ovs/db/schema.py python/ovs/db/types.py '/root/nf/ovs2.7/ovs/install/share/openvswitch/python/ovs/db' ?/usr/bin/mkdir -p '/root/nf/ovs2.7/ovs/install/share/openvswitch/python/ovs' ?/usr/bin/install -c -m 644? python/ovs/__init__.py python/ovs/daemon.py python/ovs/fcntl_win.py python/ovs/fatal_signal.py python/ovs/json.py python/ovs/jsonrpc.py python/ovs/ovsuuid.py python/ovs/poller.py python/ovs/process.py python/ovs/reconnect.py python/ovs/socket_util.py python/ovs/stream.py python/ovs/timeval.py python/ovs/util.py python/ovs/version.py python/ovs/vlog.py python/ovs/winutils.py '/root/nf/ovs2.7/ovs/install/share/openvswitch/python/ovs' ?/usr/bin/mkdir -p '/root/nf/ovs2.7/ovs/install/share/openvswitch/python/ovstest' ?/usr/bin/install -c -m 644? python/ovstest/__init__.py python/ovstest/args.py python/ovstest/rpcserver.py python/ovstest/tcp.py python/ovstest/tests.py python/ovstest/udp.py python/ovstest/util.py python/ovstest/vswitch.py '/root/nf/ovs2.7/ovs/install/share/openvswitch/python/ovstest' ?/usr/bin/mkdir -p '/root/nf/ovs2.7/ovs/install/include/openflow' ?/usr/bin/install -c -m 644 include/openflow/intel-ext.h include/openflow/netronome-ext.h include/openflow/nicira-ext.h include/openflow/openflow-1.0.h include/openflow/openflow-1.1.h include/openflow/openflow-1.2.h include/openflow/openflow-1.3.h include/openflow/openflow-1.4.h include/openflow/openflow-1.5.h include/openflow/openflow-common.h include/openflow/openflow.h '/root/nf/ovs2.7/ovs/install/include/openflow' ?/usr/bin/mkdir -p '/root/nf/ovs2.7/ovs/install/include/openvswitch' ?/usr/bin/install -c -m 644 include/openvswitch/compiler.h include/openvswitch/dynamic-string.h include/openvswitch/hmap.h include/openvswitch/flow.h include/openvswitch/geneve.h include/openvswitch/json.h include/openvswitch/list.h include/openvswitch/netdev.h include/openvswitch/match.h include/openvswitch/meta-flow.h include/openvswitch/ofpbuf.h include/openvswitch/ofp-actions.h include/openvswitch/ofp-errors.h include/openvswitch/ofp-msgs.h include/openvswitch/ofp-parse.h include/openvswitch/ofp-print.h include/openvswitch/ofp-prop.h include/openvswitch/ofp-util.h include/openvswitch/packets.h include/openvswitch/shash.h include/openvswitch/thread.h include/openvswitch/token-bucket.h include/openvswitch/tun-metadata.h include/openvswitch/type-props.h include/openvswitch/types.h include/openvswitch/util.h include/openvswitch/uuid.h include/openvswitch/version.h include/openvswitch/vconn.h include/openvswitch/vlog.h '/root/nf/ovs2.7/ovs/install/include/openvswitch' ?/usr/bin/mkdir -p '/root/nf/ovs2.7/ovs/install/include/ovn' ?/usr/bin/install -c -m 644 include/ovn/actions.h include/ovn/expr.h include/ovn/lex.h '/root/nf/ovs2.7/ovs/install/include/ovn' ?/usr/bin/mkdir -p '/root/nf/ovs2.7/ovs/install/lib/pkgconfig' ?/usr/bin/install -c -m 644 ./lib/libopenvswitch.pc ./lib/libsflow.pc ./ofproto/libofproto.pc ./ovsdb/libovsdb.pc '/root/nf/ovs2.7/ovs/install/lib/pkgconfig' ?/usr/bin/mkdir -p '/root/nf/ovs2.7/ovs/install/share/openvswitch' ?/usr/bin/install -c -m 644 vswitchd/vswitch.ovsschema vtep/vtep.ovsschema ovn/ovn-sb.ovsschema ovn/ovn-nb.ovsschema '/root/nf/ovs2.7/ovs/install/share/openvswitch' ?/usr/bin/mkdir -p '/root/nf/ovs2.7/ovs/install/share/openvswitch/scripts' ?/usr/bin/install -c -m 644 utilities/ovs-lib '/root/nf/ovs2.7/ovs/install/share/openvswitch/scripts' ?/usr/bin/mkdir -p '/root/nf/ovs2.7/ovs/install/share/openvswitch/scripts' ?/usr/bin/install -c utilities/ovs-check-dead-ifs utilities/ovs-ctl utilities/ovs-save utilities/bugtool/ovs-bugtool-bfd-show utilities/bugtool/ovs-bugtool-cfm-show utilities/bugtool/ovs-bugtool-coverage-show utilities/bugtool/ovs-bugtool-fdb-show utilities/bugtool/ovs-bugtool-lacp-show utilities/bugtool/ovs-bugtool-list-dbs utilities/bugtool/ovs-bugtool-memory-show utilities/bugtool/ovs-bugtool-tc-class-show utilities/bugtool/ovs-bugtool-vsctl-show utilities/bugtool/ovs-bugtool-ovsdb-dump utilities/bugtool/ovs-bugtool-daemons-ver utilities/bugtool/ovs-bugtool-ovs-ofctl-show utilities/bugtool/ovs-bugtool-ovs-ofctl-dump-flows utilities/bugtool/ovs-bugtool-ovs-appctl-dpif utilities/bugtool/ovs-bugtool-bond-show utilities/bugtool/ovs-bugtool-conntrack-dump ovn/utilities/bugtool/ovn-bugtool-nbctl-show ovn/utilities/bugtool/ovn-bugtool-sbctl-show ovn/utilities/bugtool/ovn-bugtool-sbctl-lflow-list vtep/ovs-vtep ovn/utilities/ovn-ctl ovn/utilities/ovndb-servers.ocf '/root/nf/ovs2.7/ovs/install/share/openvswitch/scripts' make[3]: Leaving directory `/root/nf/ovs2.7/ovs' make[2]: Leaving directory `/root/nf/ovs2.7/ovs' make[1]: Leaving directory `/root/nf/ovs2.7/ovs' [root at compute-b ovs]# make modules_install cd datapath/linux && make modules_install make[1]: Entering directory `/root/nf/ovs2.7/ovs/datapath/linux' make -C /lib/modules/3.10.0-693.el7.x86_64/build M=/root/nf/ovs2.7/ovs/datapath/linux modules_install make[2]: Entering directory `/usr/src/kernels/3.10.0-693.el7.x86_64' ? DEPMOD? 3.10.0-693.el7.x86_64 depmod: WARNING: /lib/modules/3.10.0-693.el7.x86_64/kernel/net/openvswitch/vport-vxlan.ko.xz needs unknown symbol ovs_netdev_link depmod: WARNING: /lib/modules/3.10.0-693.el7.x86_64/kernel/net/openvswitch/vport-vxlan.ko.xz needs unknown symbol ovs_netdev_tunnel_destroy depmod: WARNING: /lib/modules/3.10.0-693.el7.x86_64/kernel/net/openvswitch/vport-vxlan.ko.xz needs unknown symbol __ovs_vport_ops_register depmod: WARNING: /lib/modules/3.10.0-693.el7.x86_64/kernel/net/openvswitch/vport-vxlan.ko.xz needs unknown symbol ovs_vport_ops_unregister depmod: WARNING: /lib/modules/3.10.0-693.el7.x86_64/kernel/net/openvswitch/vport-vxlan.ko.xz needs unknown symbol ovs_vport_alloc depmod: WARNING: /lib/modules/3.10.0-693.el7.x86_64/kernel/net/openvswitch/vport-vxlan.ko.xz needs unknown symbol ovs_vport_free depmod: WARNING: /lib/modules/3.10.0-693.el7.x86_64/kernel/net/openvswitch/vport-geneve.ko.xz needs unknown symbol ovs_netdev_link depmod: WARNING: /lib/modules/3.10.0-693.el7.x86_64/kernel/net/openvswitch/vport-geneve.ko.xz needs unknown symbol ovs_netdev_tunnel_destroy depmod: WARNING: /lib/modules/3.10.0-693.el7.x86_64/kernel/net/openvswitch/vport-geneve.ko.xz needs unknown symbol __ovs_vport_ops_register depmod: WARNING: /lib/modules/3.10.0-693.el7.x86_64/kernel/net/openvswitch/vport-geneve.ko.xz needs unknown symbol ovs_vport_ops_unregister depmod: WARNING: /lib/modules/3.10.0-693.el7.x86_64/kernel/net/openvswitch/vport-geneve.ko.xz needs unknown symbol ovs_vport_alloc depmod: WARNING: /lib/modules/3.10.0-693.el7.x86_64/kernel/net/openvswitch/vport-geneve.ko.xz needs unknown symbol ovs_vport_free depmod: WARNING: /lib/modules/3.10.0-693.el7.x86_64/kernel/net/openvswitch/vport-gre.ko.xz needs unknown symbol ovs_netdev_link depmod: WARNING: /lib/modules/3.10.0-693.el7.x86_64/kernel/net/openvswitch/vport-gre.ko.xz needs unknown symbol ovs_netdev_tunnel_destroy depmod: WARNING: /lib/modules/3.10.0-693.el7.x86_64/kernel/net/openvswitch/vport-gre.ko.xz needs unknown symbol __ovs_vport_ops_register depmod: WARNING: /lib/modules/3.10.0-693.el7.x86_64/kernel/net/openvswitch/vport-gre.ko.xz needs unknown symbol ovs_vport_ops_unregister depmod: WARNING: /lib/modules/3.10.0-693.el7.x86_64/kernel/net/openvswitch/vport-gre.ko.xz needs unknown symbol ovs_vport_alloc depmod: WARNING: /lib/modules/3.10.0-693.el7.x86_64/kernel/net/openvswitch/vport-gre.ko.xz needs unknown symbol ovs_vport_free make[2]: Leaving directory `/usr/src/kernels/3.10.0-693.el7.x86_64' depmod `sed -n 's/#define UTS_RELEASE "\([^"]*\)"/\1/p' /lib/modules/3.10.0-693.el7.x86_64/build/include/generated/utsrelease.h` make[1]: Leaving directory `/root/nf/ovs2.7/ovs/datapath/linux' Thanks.Prem -------------- next part -------------- An HTML attachment was scrubbed... URL: From aarcane at aarcane.org Sat Aug 12 09:46:32 2017 From: aarcane at aarcane.org (Schlacta, Christopher) Date: Sat, 12 Aug 2017 02:46:32 -0700 Subject: [ovs-discuss] Strange behaviour with VLANs and Bridges and ARP. In-Reply-To: References: <2475cf0a-5fe9-7b57-2a65-cb81ab2118cf@gmail.com> Message-ID: So as of right now, this is in effect on Kernel 4.12.4-1.g2a27bf2-default on OpenSUSE 42.3 (Using the Kernel:stable branch because some other apps require it) on every system with a vswitch called lan attached to a vswitch called br0 where the vswitch lan is the main access point to the rest of the network. I haven't tried any other configurations. That said, the only temporary solution I've found is to have a systemd timer trigger a gratuitious arp every minute or so, so that anybody *waiting* for an arp response will get notified where the host is and be able to finish the mount, ping, etc. when the gratuitous arp comes in. On Wed, Aug 9, 2017 at 4:36 PM, Schlacta, Christopher wrote: > My configuration looks like this: > > > Smart switch --on shelf. > --- br0 --on density <-- Inbound ARP requests for 'lan' IP appear here. > --- --- lan --on density, assigned vlan 10, lan IP <-- Inbound ARP > requests for 'lan' IP DO NOT appear here. No response is sent. > ---br0 --on densetsu > --- ---lan --on densetsu, Assigned vlan 10 > > Additionally, any other PC on vlan 10 is unable to ping into density > or densetsu until the respective destination pings out to the > respective origin. After the client has it's ARP table populated, all > communication flows seamlessly. > > Furthermore, the "lan" interfaces always have different MAC addresses > and reject manual MAC assignments from wicked. (Open suse server > network management system), so I can't just pre-fill ethers file on > the various client systems. > > > > On Wed, Aug 9, 2017 at 7:54 AM, Blue Lang wrote: >> The only place I've seen this is with VMWARE vswitch not forwarding ARP on >> ESX. That doesn't sound like it's any part of your issue. >> >> When you say "smart switch using openvswitch," what do you mean exactly? >> >> Thanks, >> >> On Tue, Aug 8, 2017 at 11:44 PM, Ricky wrote: >>> >>> I have run into a similar problem myself and have not found the solution. >>> The ARP traffic from one direction makes it to OVS, but does not get sent to >>> device it needs to go to. It my case OVS pretty much isn't sending any ARP >>> packets out from itself except to the other OVS instances I have a GRE >>> tunnel with. I'm running version 2.5.0. >>> >>> Please let me know if you made any progress on your issue. >>> >>> >>> On 08/07/2017 07:19 PM, Schlacta, Christopher wrote: >>>> >>>> Ping. Anybody? Hello? >>>> >>>> On Wed, Aug 2, 2017 at 10:32 PM, Schlacta, Christopher >>>> wrote: >>>>> >>>>> So this is a bit hard to explain, but I hope you'll follow. I have >>>>> two hosts, density and densetsu. they each host VMs and CEPH nodes >>>>> using libvirt and ceph and they're connected to a smart switch using >>>>> openvswitch and there are a bunch of VLANs. 5, 6, 10, 20, and 30. >>>>> Most "normal" traffic goes along VLAN 10. That's just the LAN VLAN. >>>>> So here's what the ovs-vsctl show looks like on each host: >>>>> >>>>> >>>>> density: >>>>> aarcane at density:~$ sudo ovs-vsctl show >>>>> YubiKey for `aarcane': >>>>> f2ae0266-6cae-44f0-8ca5-9d6f66562ff4 >>>>> Bridge "br0" >>>>> Port lan >>>>> tag: 10 >>>>> Interface lan >>>>> type: internal >>>>> Port "vnet0" >>>>> trunks: [5, 6, 10, 20, 30] >>>>> Interface "vnet0" >>>>> Port "eth1" >>>>> Interface "eth1" >>>>> Port "vnet1" >>>>> trunks: [5, 6, 10, 20, 30] >>>>> Interface "vnet1" >>>>> Port "br0" >>>>> Interface "br0" >>>>> type: internal >>>>> ovs_version: "2.7.0" >>>>> >>>>> >>>>> densetsu: >>>>> aarcane at densetsu:~$ sudo ovs-vsctl show >>>>> 2d6843ee-2bb6-48b8-a979-ba7f64bf5ebc >>>>> Bridge "br0" >>>>> Port "eth0" >>>>> Interface "eth0" >>>>> Port lan >>>>> tag: 10 >>>>> Interface lan >>>>> type: internal >>>>> Port "br0" >>>>> Interface "br0" >>>>> type: internal >>>>> ovs_version: "2.7.0" >>>>> >>>>> >>>>> The problem is when I try to ping the opposite machine (densetsu to >>>>> density or vice versa), the ARP packets get sent with appropriate >>>>> information through BR0 and out the eth device all tagged with VLAN >>>>> 10, but the *inbound* arp packet is never sent to the lan interface. >>>>> I see it at the br0 and the eth interface, but not the destination >>>>> host's lan interface. Furthermore, the destination never seems to see >>>>> this or respond to it, so it's then impossible for the to initiate >>>>> contact without adding entries to the ethers file. >>>>> >>>>> This is well and good, but it also means that other systems on the >>>>> network also cannot connect to them for purposes of administration and >>>>> management, and this is very problematic. >>>>> >>>>> I've not made any changes to openflow. They've been able to >>>>> communicate with each other for a long time. This change happened >>>>> with a recent kernel upgrade. Not sure how to fix it or if it's a >>>>> bug. Again, note: All IP traffic seems to work fine. ICMP works >>>>> without issue, TCP, etc. It's only the ARP protocol that seems to not >>>>> be passing inward when it should be. >>>> >>>> _______________________________________________ >>>> discuss mailing list >>>> discuss at openvswitch.org >>>> https://mail.openvswitch.org/mailman/listinfo/ovs-discuss >>> >>> >>> >>> _______________________________________________ >>> discuss mailing list >>> discuss at openvswitch.org >>> https://mail.openvswitch.org/mailman/listinfo/ovs-discuss >> >> >> >> >> -- >> Blue Lang >> PM | Veracity >> >> 3423 Piedmont Rd NE >> >> Suite 350 >> >> Atlanta, GA 30305 >> >> Cell: (770) 265-1381 >> https://www.linkedin.com/in/bluelang/ >> blue at veracity.io >> www.veracity.io >> >> _______________________________________________ >> discuss mailing list >> discuss at openvswitch.org >> https://mail.openvswitch.org/mailman/listinfo/ovs-discuss >> From WBAHACER at 126.com Sun Aug 13 05:03:37 2017 From: WBAHACER at 126.com (Furong) Date: Sun, 13 Aug 2017 13:03:37 +0800 Subject: [ovs-discuss] How to make OVS working with IVSHMEM ? In-Reply-To: <08f7761a-c183-9b2d-cd60-cfd7ea675609@126.com> References: <08f7761a-c183-9b2d-cd60-cfd7ea675609@126.com> Message-ID: <0c10c2fd-c844-c53d-f56e-8ee978ae3591@126.com> Hello, I've encountered a problem with running ovs with IVSHMEM. I've followed the guide of INSTALL.DPDK.md of ovs-2.5.0 to use IVSHMEM. Firstly, I started ovs-vswitchd using "./sbin/ovs-vswitchd --dpdk -c 0x1 -n 4 --proc-type=primary -- --pidfile --detach", and I added dpdk ports(dpdk0,dpdk1) and dpdk ring(dpdkr0) to ovs. Then, I started ./openvswitch-2.5.0/tests/test-dpdkr using "./test-dpdkr -c 1 -n 4 --proc-type=secondary -- -n 0", but the EAL initialization of this program was stucked after printing "EAL: Detected 16 lcore(s)" to stdout. Does anybody has successful experience with running ovs with IVSHMEM? Please share with me. Many thanks!!! From xiangxia.m.yue at gmail.com Mon Aug 14 01:09:30 2017 From: xiangxia.m.yue at gmail.com (Tonghao Zhang) Date: Mon, 14 Aug 2017 09:09:30 +0800 Subject: [ovs-discuss] Fedora 25+ with OVS kernel trainted? In-Reply-To: <805e79cd-13bd-127c-4081-21836a36a9a9@redhat.com> References: <805e79cd-13bd-127c-4081-21836a36a9a9@redhat.com> Message-ID: Hi This bug has been fixed in 4.11, 4.12 and 4.13 kernel version. and if you don't use the UFO, you can disable it. https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/commit/?id=8d63bee643f1fb53e472f0e135cae4eb99d62d19 On Sat, Aug 5, 2017 at 12:24 AM, Timothy M. Redaelli wrote: > On 07/31/2017 06:01 PM, Ziemowit Pierzycki wrote: >> Hi, >> >> I have a hypervisor with Fedora 25 on a few machines and ever since >> upgrading I started getting occasional messages: > [...] >> I noticed it's happening with Fedora 26 too. I'm using kernel >> 4.11.12-200.fc25.x86_64 in this particular example. I'm using OVS >> 2.5.0-4. Am I supposed to turn off GSO everywhere? I thought it was >> supposed to automatic. Thanks, > > Hi, > you can try to disable only UFO (ethtool -i dev ufo off) since it'll be > disabled in upstream kernel [1] > > [1]: > https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/commit/?id=5c3c6081b246b05ee5bb2fc1759a7c0c6a0b7c3b > _______________________________________________ > discuss mailing list > discuss at openvswitch.org > https://mail.openvswitch.org/mailman/listinfo/ovs-discuss From sara.gittlin at gmail.com Mon Aug 14 06:31:55 2017 From: sara.gittlin at gmail.com (Sara Gittlin) Date: Mon, 14 Aug 2017 09:31:55 +0300 Subject: [ovs-discuss] OVS megaflows In-Reply-To: References: Message-ID: Thanks you Joe the following citation is in a contradiction to the idea of pre-populating megaflows in kernel datapath . this is from http://docs.openvswitch.org/en/latest/faq/design/ "Q: Can OVS populate the kernel flow table in advance instead of in reaction to packets? A: No. There are several reasons: Kernel flows are not as sophisticated as OpenFlow flows, which means that some OpenFlow policies could require a large number of kernel flows. The ?conjunctive match? feature is an extreme example: the number of kernel flows it requires is the product of the number of flows in each dimension. With multiple OpenFlow flow tables and simple sets of actions, the number of kernel flows required can be as large as the product of the number of flows in each dimension. With more sophisticated actions, the number of kernel flows could be even larger. Open vSwitch is designed so that any version of OVS userspace interoperates with any version of the OVS kernel module. This forward and backward compatibility requires that userspace observe how the kernel module parses received packets. This is only possible in a straightforward way when userspace adds kernel flows in reaction to received packets." Thanks in advance - Sara On Mon, Jul 24, 2017 at 10:58 PM, Joe Stringer wrote: > On 23 July 2017 at 06:37, Sara Gittlin wrote: >> Hello, >> I understand that there is a support for megaflows in the kernel and netlink. >> I also understand that there is no megaflow implementation in ofproto. >> i.e. there is no implementation of compressing (if possible) all flows >> in ofproto table to megaflows and installing it in the datapath. is >> that correct ? > > That's right - rather than pre-populating a representation of the > entire OpenFlow state, the ofproto-dpif implementation uses an > "upcall" model where the datapath acts as a cache for forwarding > behaviour, and the cache is populated on-demand as traffic arrives. From bhanuprakash.bodireddy at intel.com Mon Aug 14 06:51:53 2017 From: bhanuprakash.bodireddy at intel.com (Bodireddy, Bhanuprakash) Date: Mon, 14 Aug 2017 06:51:53 +0000 Subject: [ovs-discuss] How to make OVS working with IVSHMEM ? In-Reply-To: <0c10c2fd-c844-c53d-f56e-8ee978ae3591@126.com> References: <08f7761a-c183-9b2d-cd60-cfd7ea675609@126.com> <0c10c2fd-c844-c53d-f56e-8ee978ae3591@126.com> Message-ID: <7EE4206A5F421D4FBA0A4623185DE2BD374C0D33@IRSMSX104.ger.corp.intel.com> >Hello, I've encountered a problem with running ovs with IVSHMEM. > >I've followed the guide of INSTALL.DPDK.md of ovs-2.5.0 to use IVSHMEM. > >Firstly, I started ovs-vswitchd using "./sbin/ovs-vswitchd --dpdk -c 0x1 -n 4 -- >proc-type=primary -- --pidfile --detach", and I added dpdk >ports(dpdk0,dpdk1) and dpdk ring(dpdkr0) to ovs. > >Then, I started ./openvswitch-2.5.0/tests/test-dpdkr using "./test-dpdkr -c 1 - >n 4 --proc-type=secondary -- -n 0", but the EAL initialization of this program >was stucked after printing "EAL: Detected 16 lcore(s)" to stdout. > >Does anybody has successful experience with running ovs with IVSHMEM? >Please share with me. Many thanks!!! Refer the link here https://github.com/openvswitch/ovs/blob/branch-2.6/INSTALL.DPDK-ADVANCED.md#ovstc I wrote this documentation and have a section(5.2) dedicated for IVSHMEM. With the steps mentioned in section 5.2, I could successfully verify IVSHMEM back in 2.6 release. You should patch Qemu 2.2 as mentioned in the install guide. Hope it helps you! - Bhanuprakash. From sara.gittlin at gmail.com Mon Aug 14 07:35:12 2017 From: sara.gittlin at gmail.com (Sara Gittlin) Date: Mon, 14 Aug 2017 10:35:12 +0300 Subject: [ovs-discuss] OVS megaflows In-Reply-To: References: Message-ID: I understand that this citation refers to the kernel microflows tables. the kernel megaflows table *can be* pre-populated. Correct ? Sara On Mon, Aug 14, 2017 at 9:31 AM, Sara Gittlin wrote: > Thanks you Joe > the following citation is in a contradiction to the idea of > pre-populating megaflows in kernel datapath . > this is from http://docs.openvswitch.org/en/latest/faq/design/ > > "Q: Can OVS populate the kernel flow table in advance instead of in > reaction to packets? > > A: No. There are several reasons: > > Kernel flows are not as sophisticated as OpenFlow flows, which means > that some OpenFlow policies could require a large number of kernel > flows. The ?conjunctive match? feature is an extreme example: the > number of kernel flows it requires is the product of the number of > flows in each dimension. > With multiple OpenFlow flow tables and simple sets of actions, the > number of kernel flows required can be as large as the product of the > number of flows in each dimension. With more sophisticated actions, > the number of kernel flows could be even larger. > Open vSwitch is designed so that any version of OVS userspace > interoperates with any version of the OVS kernel module. This forward > and backward compatibility requires that userspace observe how the > kernel module parses received packets. This is only possible in a > straightforward way when userspace adds kernel flows in reaction to > received packets." > > Thanks in advance - Sara > > On Mon, Jul 24, 2017 at 10:58 PM, Joe Stringer wrote: >> On 23 July 2017 at 06:37, Sara Gittlin wrote: >>> Hello, >>> I understand that there is a support for megaflows in the kernel and netlink. >>> I also understand that there is no megaflow implementation in ofproto. >>> i.e. there is no implementation of compressing (if possible) all flows >>> in ofproto table to megaflows and installing it in the datapath. is >>> that correct ? >> >> That's right - rather than pre-populating a representation of the >> entire OpenFlow state, the ofproto-dpif implementation uses an >> "upcall" model where the datapath acts as a cache for forwarding >> behaviour, and the cache is populated on-demand as traffic arrives. From joe at ovn.org Mon Aug 14 17:47:48 2017 From: joe at ovn.org (Joe Stringer) Date: Mon, 14 Aug 2017 10:47:48 -0700 Subject: [ovs-discuss] OVS megaflows In-Reply-To: References: Message-ID: The FAQ is referring to megaflows as well, the reasons are the same. Neither microflows nor megaflows can be pre-populated. On 14 August 2017 at 00:35, Sara Gittlin wrote: > I understand that this citation refers to the kernel microflows tables. > the kernel megaflows table *can be* pre-populated. Correct ? > Sara > > On Mon, Aug 14, 2017 at 9:31 AM, Sara Gittlin wrote: >> Thanks you Joe >> the following citation is in a contradiction to the idea of >> pre-populating megaflows in kernel datapath . >> this is from http://docs.openvswitch.org/en/latest/faq/design/ >> >> "Q: Can OVS populate the kernel flow table in advance instead of in >> reaction to packets? >> >> A: No. There are several reasons: >> >> Kernel flows are not as sophisticated as OpenFlow flows, which means >> that some OpenFlow policies could require a large number of kernel >> flows. The ?conjunctive match? feature is an extreme example: the >> number of kernel flows it requires is the product of the number of >> flows in each dimension. >> With multiple OpenFlow flow tables and simple sets of actions, the >> number of kernel flows required can be as large as the product of the >> number of flows in each dimension. With more sophisticated actions, >> the number of kernel flows could be even larger. >> Open vSwitch is designed so that any version of OVS userspace >> interoperates with any version of the OVS kernel module. This forward >> and backward compatibility requires that userspace observe how the >> kernel module parses received packets. This is only possible in a >> straightforward way when userspace adds kernel flows in reaction to >> received packets." >> >> Thanks in advance - Sara >> >> On Mon, Jul 24, 2017 at 10:58 PM, Joe Stringer wrote: >>> On 23 July 2017 at 06:37, Sara Gittlin wrote: >>>> Hello, >>>> I understand that there is a support for megaflows in the kernel and netlink. >>>> I also understand that there is no megaflow implementation in ofproto. >>>> i.e. there is no implementation of compressing (if possible) all flows >>>> in ofproto table to megaflows and installing it in the datapath. is >>>> that correct ? >>> >>> That's right - rather than pre-populating a representation of the >>> entire OpenFlow state, the ofproto-dpif implementation uses an >>> "upcall" model where the datapath acts as a cache for forwarding >>> behaviour, and the cache is populated on-demand as traffic arrives. From joe at ovn.org Mon Aug 14 17:48:05 2017 From: joe at ovn.org (Joe Stringer) Date: Mon, 14 Aug 2017 10:48:05 -0700 Subject: [ovs-discuss] getting build errors while building ovs2.7.0 In-Reply-To: <839487988.78900.1502477536287@mail.yahoo.com> References: <839487988.78900.1502477536287.ref@mail.yahoo.com> <839487988.78900.1502477536287@mail.yahoo.com> Message-ID: On 11 August 2017 at 11:52, Prem Shankar Sharma via discuss wrote: > Hi, > I'm getting some build errors while trying to build ovs2.7.0 on redhat 7.2. > I cloned 2.7.0 from git and tried to run - make and make modules_install (to > build kernel module). The output of both of them is reporting some issues > like: Hi Prem, The kernel module that comes with OVS 2.7.0 doesn't support Redhat 7.2 - RHEL7.2 is newer than OVS 2.7. You can use the module that is distributed with RHEL (and not compile the version from OVS tree), or wait for the upcoming OVS 2.8 release that is expected later this month. Alternatively if you are happy running on the master version of OVS, you might consider just cloning and building the top of tree from github. Cheers, Joe From aserdean at cloudbasesolutions.com Tue Aug 15 00:45:01 2017 From: aserdean at cloudbasesolutions.com (Alin Serdean) Date: Tue, 15 Aug 2017 00:45:01 +0000 Subject: [ovs-discuss] [openvswitch 2.8.90] testsuite: 537 539 541 545 765 767 1966 1968 1975 1977 1984 1986 1993 1995 2001 2002 2003 2004 2006 2011 2013 2020 2022 2029 2031 2038 2040 2047 2049 2056 2058 2065 2067 2074 2076 2083 2085 2092 2094 2101 2103 2110 2112 2119 2121 2128 Message-ID: <6FDA0CACF4BC624BBE12167875D71C9B40A34873@CBSEX1.cloudbase.local> To: Subject: [openvswitch 2.8.90] testsuite: 537 539 541 545 765 767 1966 1968 1975 1977 1984 1986 1993 1995 2001 2002 2003 2004 2006 2011 2013 2020 2022 2029 2031 2038 2040 2047 2049 2056 2058 2065 2067 2074 2076 2083 2085 2092 2094 2101 2103 2110 2112 2119 2121 2128 2130 2136 2138 2140 2148 2151 2238 2244 2247 2250 failed After patch: https://github.com/openvswitch/ovs/commit/e7164d96bcbcf79044a93f6e7acc68f05d8e3945 a lot of the python3 tests are failing. This is probably due to: +Traceback (most recent call last): + File "../.././appctl.py", line 75, in + main() + File "../.././appctl.py", line 60, in main + err_no, error, result = client.transact(args.command, args.argv) + File "c:\ovs\python\ovs\unixctl\client.py", line 39, in transact + error, reply = self._conn.transact_block(request) + File "c:\ovs\python\ovs\jsonrpc.py", line 326, in transact_block + error, reply = self.recv_block() + File "c:\ovs\python\ovs\jsonrpc.py", line 309, in recv_block + error, msg = self.recv() + File "c:\ovs\python\ovs\jsonrpc.py", line 273, in recv + data = data.decode('utf-8') +AttributeError: 'str' object has no attribute 'decode' Also using UTF-8 strings in Windows shells proves to be a bit of challenge. Me and @Alin Balutoiu are looking over changes needed on the Windows side as well. Since Python isn't quite my cup of tea I would like if you can oversee the patches that he will send out. Thanks, Alin. From lrichard at redhat.com Tue Aug 15 01:44:59 2017 From: lrichard at redhat.com (Lance Richardson) Date: Mon, 14 Aug 2017 21:44:59 -0400 (EDT) Subject: [ovs-discuss] [openvswitch 2.8.90] testsuite: 537 539 541 545 765 767 1966 1968 1975 1977 1984 1986 1993 1995 2001 2002 2003 2004 2006 2011 2013 2020 2022 2029 2031 2038 2040 2047 2049 2056 2058 2065 2067 2074 2076 2083 2085 2092 2094 2101 2103 2110 2112 2119 2121 2128 In-Reply-To: <6FDA0CACF4BC624BBE12167875D71C9B40A34873@CBSEX1.cloudbase.local> References: <6FDA0CACF4BC624BBE12167875D71C9B40A34873@CBSEX1.cloudbase.local> Message-ID: <1832630906.577832.1502761499513.JavaMail.zimbra@redhat.com> > From: "Alin Serdean" > To: bugs at openvswitch.org, "Alin Balutoiu" > Cc: "Terry Wilson" , "Lance Richardson" , "Russell Bryant" > Sent: Monday, August 14, 2017 8:45:01 PM > Subject: [openvswitch 2.8.90] testsuite: 537 539 541 545 765 767 1966 1968 1975 1977 1984 1986 1993 1995 2001 2002 > 2003 2004 2006 2011 2013 2020 2022 2029 2031 2038 2040 2047 2049 2056 2058 2065 2067 2074 2076 2083 2085 2092 2094 > 2101 2103 2110 2112 2119 2121 2128 > > To: > Subject: [openvswitch 2.8.90] testsuite: 537 539 541 545 765 767 1966 1968 > 1975 1977 1984 1986 1993 1995 2001 2002 2003 2004 2006 2011 2013 2020 > 2022 2029 2031 2038 2040 2047 2049 2056 2058 2065 2067 2074 2076 2083 > 2085 2092 2094 2101 2103 2110 2112 2119 2121 2128 2130 2136 2138 2140 > 2148 2151 2238 2244 2247 2250 failed > > After patch: > https://github.com/openvswitch/ovs/commit/e7164d96bcbcf79044a93f6e7acc68f05d8e3945 > a lot of the python3 tests are failing. > > This is probably due to: > +Traceback (most recent call last): > + File "../.././appctl.py", line 75, in > + main() > + File "../.././appctl.py", line 60, in main > + err_no, error, result = client.transact(args.command, args.argv) > + File "c:\ovs\python\ovs\unixctl\client.py", line 39, in transact > + error, reply = self._conn.transact_block(request) > + File "c:\ovs\python\ovs\jsonrpc.py", line 326, in transact_block > + error, reply = self.recv_block() > + File "c:\ovs\python\ovs\jsonrpc.py", line 309, in recv_block > + error, msg = self.recv() > + File "c:\ovs\python\ovs\jsonrpc.py", line 273, in recv > + data = data.decode('utf-8') > +AttributeError: 'str' object has no attribute 'decode' > > Also using UTF-8 strings in Windows shells proves to be a bit of challenge. > > Me and @Alin Balutoiu are looking over changes needed on the Windows side as > well. > > Since Python isn't quite my cup of tea I would like if you can oversee the > patches that he will send out. > > Thanks, > Alin. > Hi Alin, It seems that for the Python3 non-windows, self.stream.recv() returns socket.recv(), which always has a type of "bytes". For the windows case, self.stream.recv() returns get_decoded_buffer(recvBuffer) from python/ovs/winutils.py, which does: return bytes(recvBuffer).decode("utf-8") So for the windows Python3 case, the type of the value returned by self.stream.recv() will always be "str". I'm not sure why the windows case needs to do the utf-8 decode at the stream layer, but it would be nice if self.stream.recv() returned a consistent type that was independent of the OS. I'm happy to help, but I will be travelling tomorrow and will probably not be able to look any deeper until Wednesday. I don't know if such a thing exists, but e.g. a Vagrant setup that could build ovs and run the tests would be a huge help in avoiding this kind of breakage (just a thought...) Regards, Lance From aserdean at cloudbasesolutions.com Tue Aug 15 01:57:50 2017 From: aserdean at cloudbasesolutions.com (Alin Serdean) Date: Tue, 15 Aug 2017 01:57:50 +0000 Subject: [ovs-discuss] [openvswitch 2.8.90] testsuite: 537 539 541 545 765 767 1966 1968 1975 1977 1984 1986 1993 1995 2001 2002 2003 2004 2006 2011 2013 2020 2022 2029 2031 2038 2040 2047 2049 2056 2058 2065 2067 2074 2076 2083 2085 2092 2094 2101 2103 2110 2112 2119 21... In-Reply-To: <1832630906.577832.1502761499513.JavaMail.zimbra@redhat.com> References: <6FDA0CACF4BC624BBE12167875D71C9B40A34873@CBSEX1.cloudbase.local> <1832630906.577832.1502761499513.JavaMail.zimbra@redhat.com> Message-ID: <6FDA0CACF4BC624BBE12167875D71C9B40A349A5@CBSEX1.cloudbase.local> > -----Original Message----- > From: Lance Richardson [mailto:lrichard at redhat.com] > Sent: Tuesday, August 15, 2017 4:45 AM > To: Alin Serdean > Cc: bugs at openvswitch.org; Alin Balutoiu > ; Terry Wilson ; > Russell Bryant > Subject: Re: [openvswitch 2.8.90] testsuite: 537 539 541 545 765 767 1966 1968 > 1975 1977 1984 1986 1993 1995 2001 2002 2003 2004 2006 2011 2013 2020 2022 > 2029 2031 2038 2040 2047 2049 2056 2058 2065 2067 2074 2076 2083 2085 2092 > 2094 2101 2103 2110 2112 2119 21... > > > From: "Alin Serdean" > > To: bugs at openvswitch.org, "Alin Balutoiu" > > > > Cc: "Terry Wilson" , "Lance Richardson" > > , "Russell Bryant" > > Sent: Monday, August 14, 2017 8:45:01 PM > > Subject: [openvswitch 2.8.90] testsuite: 537 539 541 545 765 767 1966 > > 1968 1975 1977 1984 1986 1993 1995 2001 2002 > > 2003 2004 2006 2011 2013 2020 2022 2029 2031 2038 2040 2047 2049 2056 > > 2058 2065 2067 2074 2076 2083 2085 2092 2094 > > 2101 2103 2110 2112 2119 2121 2128 > > > > To: > > Subject: [openvswitch 2.8.90] testsuite: 537 539 541 545 765 767 1966 1968 > > 1975 1977 1984 1986 1993 1995 2001 2002 2003 2004 2006 2011 2013 2020 > > 2022 2029 2031 2038 2040 2047 2049 2056 2058 2065 2067 2074 2076 2083 > > 2085 2092 2094 2101 2103 2110 2112 2119 2121 2128 2130 2136 2138 2140 > > 2148 2151 2238 2244 2247 2250 failed > > > > After patch: > > > https://github.com/openvswitch/ovs/commit/e7164d96bcbcf79044a93f6e7a > cc > > 68f05d8e3945 a lot of the python3 tests are failing. > > > > This is probably due to: > > +Traceback (most recent call last): > > + File "../.././appctl.py", line 75, in > > + main() > > + File "../.././appctl.py", line 60, in main > > + err_no, error, result = client.transact(args.command, args.argv) > > + File "c:\ovs\python\ovs\unixctl\client.py", line 39, in transact > > + error, reply = self._conn.transact_block(request) > > + File "c:\ovs\python\ovs\jsonrpc.py", line 326, in transact_block > > + error, reply = self.recv_block() > > + File "c:\ovs\python\ovs\jsonrpc.py", line 309, in recv_block > > + error, msg = self.recv() > > + File "c:\ovs\python\ovs\jsonrpc.py", line 273, in recv > > + data = data.decode('utf-8') > > +AttributeError: 'str' object has no attribute 'decode' > > > > Also using UTF-8 strings in Windows shells proves to be a bit of challenge. > > > > Me and @Alin Balutoiu are looking over changes needed on the Windows > > side as well. > > > > Since Python isn't quite my cup of tea I would like if you can oversee > > the patches that he will send out. > > > > Thanks, > > Alin. > > > > Hi Alin, > > It seems that for the Python3 non-windows, self.stream.recv() returns > socket.recv(), which always has a type of "bytes". For the windows case, > self.stream.recv() returns > get_decoded_buffer(recvBuffer) from python/ovs/winutils.py, which does: > > return bytes(recvBuffer).decode("utf-8") > > So for the windows Python3 case, the type of the value returned by > self.stream.recv() will always be "str". > > I'm not sure why the windows case needs to do the utf-8 decode at the > stream layer, but it would be nice if self.stream.recv() returned a consistent > type that was independent of the OS. > > I'm happy to help, but I will be travelling tomorrow and will probably not be > able to look any deeper until Wednesday. > > I don't know if such a thing exists, but e.g. a Vagrant setup that could build > ovs and run the tests would be a huge help in avoiding this kind of breakage > (just a thought...) > > Regards, > > Lance Hi Lance, @Alin Balutoiu sent out two patches: https://patchwork.ozlabs.org/patch/801393/ ; https://patchwork.ozlabs.org/patch/801394/ which should make the code a bit more OS independent. Can you please review them when you have time? Regarding the Vagrant setup it is a great idea. The only downside, I have no idea how it deals with Windows images. I will look into if it is possible to setup Vagrant using Nano images (lowest disk requirement) because this would help a lot in the future. Thanks, Alin. From aserdean at cloudbasesolutions.com Tue Aug 15 03:44:09 2017 From: aserdean at cloudbasesolutions.com (Alin Serdean) Date: Tue, 15 Aug 2017 03:44:09 +0000 Subject: [ovs-discuss] Windows unit test CI unavailable Message-ID: <6FDA0CACF4BC624BBE12167875D71C9B40A34B05@CBSEX1.cloudbase.local> Hi, The Windows unit test CI will be down for approximately one month. We are moving the servers to a different zone. I will run unit tests daily and report bugs on bugs at openvswitch.org (in case of failures) until they are online. Thanks for understanding, Alin. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sara.gittlin at gmail.com Tue Aug 15 06:34:48 2017 From: sara.gittlin at gmail.com (Sara Gittlin) Date: Tue, 15 Aug 2017 09:34:48 +0300 Subject: [ovs-discuss] OVS megaflows In-Reply-To: References: Message-ID: Can i summarize: 1. Once N microflows are installed in the kernel cache: we can install a megaflow/s in kernel datapath, if it possible to generate a megaflow/s for them 2. These megaflow/s remain in the kernel megaflow cache as long as the associated flows are in userspace openflow tables, regardless of microflows eviction from kernel cache. Thanks in advance Sara On Mon, Aug 14, 2017 at 8:47 PM, Joe Stringer wrote: > The FAQ is referring to megaflows as well, the reasons are the same. > Neither microflows nor megaflows can be pre-populated. > > On 14 August 2017 at 00:35, Sara Gittlin wrote: >> I understand that this citation refers to the kernel microflows tables. >> the kernel megaflows table *can be* pre-populated. Correct ? >> Sara >> >> On Mon, Aug 14, 2017 at 9:31 AM, Sara Gittlin wrote: >>> Thanks you Joe >>> the following citation is in a contradiction to the idea of >>> pre-populating megaflows in kernel datapath . >>> this is from http://docs.openvswitch.org/en/latest/faq/design/ >>> >>> "Q: Can OVS populate the kernel flow table in advance instead of in >>> reaction to packets? >>> >>> A: No. There are several reasons: >>> >>> Kernel flows are not as sophisticated as OpenFlow flows, which means >>> that some OpenFlow policies could require a large number of kernel >>> flows. The ?conjunctive match? feature is an extreme example: the >>> number of kernel flows it requires is the product of the number of >>> flows in each dimension. >>> With multiple OpenFlow flow tables and simple sets of actions, the >>> number of kernel flows required can be as large as the product of the >>> number of flows in each dimension. With more sophisticated actions, >>> the number of kernel flows could be even larger. >>> Open vSwitch is designed so that any version of OVS userspace >>> interoperates with any version of the OVS kernel module. This forward >>> and backward compatibility requires that userspace observe how the >>> kernel module parses received packets. This is only possible in a >>> straightforward way when userspace adds kernel flows in reaction to >>> received packets." >>> >>> Thanks in advance - Sara >>> >>> On Mon, Jul 24, 2017 at 10:58 PM, Joe Stringer wrote: >>>> On 23 July 2017 at 06:37, Sara Gittlin wrote: >>>>> Hello, >>>>> I understand that there is a support for megaflows in the kernel and netlink. >>>>> I also understand that there is no megaflow implementation in ofproto. >>>>> i.e. there is no implementation of compressing (if possible) all flows >>>>> in ofproto table to megaflows and installing it in the datapath. is >>>>> that correct ? >>>> >>>> That's right - rather than pre-populating a representation of the >>>> entire OpenFlow state, the ofproto-dpif implementation uses an >>>> "upcall" model where the datapath acts as a cache for forwarding >>>> behaviour, and the cache is populated on-demand as traffic arrives. From joe at ovn.org Tue Aug 15 16:16:24 2017 From: joe at ovn.org (Joe Stringer) Date: Tue, 15 Aug 2017 09:16:24 -0700 Subject: [ovs-discuss] OVS megaflows In-Reply-To: References: Message-ID: On the first point - it's a little more subtle than that. A traffic flow (eg, a connection) must arrive at OVS, the first packet is sent through userspace, which causes userspace to install a megaflow into the datapath. Subsequently, if any traffic which matches that megaflow arrives, it will directly 'hit' the megaflow entry and execute the associated actions without going to userspace. Typically we use "microflow" to refer to a packet headers description which exact-matches all known fields, while "megaflow" allows a mask to be applied in addition to this, which allows the traffic which would otherwise be handled by multiple microflows to instead be handled by a single megaflow. There is no dependency between megaflows and microflows. Cheers, Joe From sara.gittlin at gmail.com Wed Aug 16 06:59:46 2017 From: sara.gittlin at gmail.com (Sara Gittlin) Date: Wed, 16 Aug 2017 09:59:46 +0300 Subject: [ovs-discuss] OVS megaflows In-Reply-To: References: Message-ID: Thank you Joe Few questions: 1. Are there 2 separate flow tables in the kernel data-path ? for microflows and megaflows ? 2. If the answer is yes : - When pkt arrives, is it first checked against the microflows table and if there is no match, then it checked against the megaflows table ? - Then if the pkt matches a megaflow - a new microflow will be generated by the kernel for this pkt ? this make sense to improve performance. Sara On Tue, Aug 15, 2017 at 7:16 PM, Joe Stringer wrote: > On the first point - it's a little more subtle than that. A traffic > flow (eg, a connection) must arrive at OVS, the first packet is sent > through userspace, which causes userspace to install a megaflow into > the datapath. Subsequently, if any traffic which matches that megaflow > arrives, it will directly 'hit' the megaflow entry and execute the > associated actions without going to userspace. Typically we use > "microflow" to refer to a packet headers description which > exact-matches all known fields, while "megaflow" allows a mask to be > applied in addition to this, which allows the traffic which would > otherwise be handled by multiple microflows to instead be handled by a > single megaflow. There is no dependency between megaflows and > microflows. > > Cheers, > Joe From sara.gittlin at gmail.com Wed Aug 16 07:34:45 2017 From: sara.gittlin at gmail.com (Sara Gittlin) Date: Wed, 16 Aug 2017 10:34:45 +0300 Subject: [ovs-discuss] OVS megaflows In-Reply-To: References: Message-ID: I took a look at the datapath code - saw only single table, which its entries are microflows and megaflows the megaflows are indicated by non-zero mask fields Sara On Wed, Aug 16, 2017 at 9:59 AM, Sara Gittlin wrote: > Thank you Joe > Few questions: > 1. Are there 2 separate flow tables in the kernel data-path ? for > microflows and megaflows ? > > 2. If the answer is yes : > - When pkt arrives, is it first checked against the microflows > table and if there is no match, then it checked against the megaflows > table ? > > - Then if the pkt matches a megaflow - a new microflow will be > generated by the kernel for this pkt ? this make sense to improve > performance. > > > Sara > > > On Tue, Aug 15, 2017 at 7:16 PM, Joe Stringer wrote: >> On the first point - it's a little more subtle than that. A traffic >> flow (eg, a connection) must arrive at OVS, the first packet is sent >> through userspace, which causes userspace to install a megaflow into >> the datapath. Subsequently, if any traffic which matches that megaflow >> arrives, it will directly 'hit' the megaflow entry and execute the >> associated actions without going to userspace. Typically we use >> "microflow" to refer to a packet headers description which >> exact-matches all known fields, while "megaflow" allows a mask to be >> applied in addition to this, which allows the traffic which would >> otherwise be handled by multiple microflows to instead be handled by a >> single megaflow. There is no dependency between megaflows and >> microflows. >> >> Cheers, >> Joe From vivek.v.srivastava at ericsson.com Wed Aug 16 10:54:58 2017 From: vivek.v.srivastava at ericsson.com (Vivek Srivastava V) Date: Wed, 16 Aug 2017 10:54:58 +0000 Subject: [ovs-discuss] BFD with 'option : remote_ip = flow' In-Reply-To: <20170811155331.GL6175@ovn.org> References: <20170811155331.GL6175@ovn.org> Message-ID: Hi Ben, Thanks for your response. Please see below inline. Regards, Vivek -----Original Message----- From: Ben Pfaff [mailto:blp at ovn.org] Sent: Friday, August 11, 2017 9:24 PM To: Vivek Srivastava V Cc: ovs-discuss at openvswitch.org Subject: Re: [ovs-discuss] BFD with 'option : remote_ip = flow' On Fri, Aug 11, 2017 at 08:48:20AM +0000, Vivek Srivastava V wrote: > 1. Is there any way to configure/manage BFD sessions to destinations, > independent of the tunnel port/interface created? Not currently. If you have a good idea for how to extend the OVS BFD support to be more flexible, we'd accept patches. [Viveks] We are planning to create a separate table/schema for maintaining independent BFD sessions. An entry in this BFD table can be identified by a session ID generated/configured and will have same columns as we have for BFD in interface table. In future we can choose to remove the BFD related fields from interface table and use a reference (session_id) from the BFD table. WDYT? > 2. Does OVS support multi-hop BFD? In roadmap? No. I hadn't heard of multi-hop BFD before, so I looked around a bit and found RFC 5883. That RFC, though, doesn't really provide a specification for how to do this. Is there a detailed specification somewhere else? [Viveks] Unfortunately I also couldn't find any implementation specific details about multihop BFD, other than RFC 5883 and some configuration related info available on the net. What I could gather is that it is mostly same as onehop BFD, with some additional considerations- 1. uses different UDP destination port 4784 (MUST) 2. suggests session authentication (SHOULD) 3. De-multiplexing (applicable only in case of multiple BFD sessions between same pair of TEPs) So I think we should be good with supporting the first item initially. From ray at oneunified.net Wed Aug 16 11:34:32 2017 From: ray at oneunified.net (Raymond Burkholder) Date: Wed, 16 Aug 2017 08:34:32 -0300 Subject: [ovs-discuss] BFD with 'option : remote_ip = flow' In-Reply-To: References: <20170811155331.GL6175@ovn.org> Message-ID: <810CCB72-BC0D-4EDF-9AFE-B1E3981A126E@oneunified.net> > On 16 Aug 2017, at 07:54, Vivek Srivastava V wrote: > > No. I hadn't heard of multi-hop BFD before, so I looked around a bit and found RFC 5883. That RFC, though, doesn't really provide a specification for how to do this. Is there a detailed specification somewhere else? > > [Viveks] Unfortunately I also couldn't find any implementation specific details about multihop BFD, other than RFC 5883 and some configuration related info available on the net. What I could gather is that it is mostly same as onehop BFD, with some additional considerations- Out of curiosity, would you be able to explain what your use case is? I gather you don?t have a BFD partner on the ?other end? of the layer 2 link? And that you are going across some sort of layer 3 network? And if that is a multi-hop l3 network, don?t things get a bit dicey in terms of time-outs, possible changes in packet flows, etc? -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From vivek.v.srivastava at ericsson.com Wed Aug 16 16:54:48 2017 From: vivek.v.srivastava at ericsson.com (Vivek Srivastava V) Date: Wed, 16 Aug 2017 16:54:48 +0000 Subject: [ovs-discuss] BFD with 'option : remote_ip = flow' In-Reply-To: <810CCB72-BC0D-4EDF-9AFE-B1E3981A126E@oneunified.net> References: <20170811155331.GL6175@ovn.org> <810CCB72-BC0D-4EDF-9AFE-B1E3981A126E@oneunified.net> Message-ID: -----Original Message----- From: Raymond Burkholder [mailto:ray at oneunified.net] Sent: Wednesday, August 16, 2017 5:05 PM To: Vivek Srivastava V Cc: ovs-discuss at openvswitch.org Subject: Re: [ovs-discuss] BFD with 'option : remote_ip = flow' > On 16 Aug 2017, at 07:54, Vivek Srivastava V wrote: > > No. I hadn't heard of multi-hop BFD before, so I looked around a bit and found RFC 5883. That RFC, though, doesn't really provide a specification for how to do this. Is there a detailed specification somewhere else? > > [Viveks] Unfortunately I also couldn't find any implementation > specific details about multihop BFD, other than RFC 5883 and some > configuration related info available on the net. What I could gather > is that it is mostly same as onehop BFD, with some additional > considerations- Out of curiosity, would you be able to explain what your use case is? I gather you don?t have a BFD partner on the ?other end? of the layer 2 link? And that you are going across some sort of layer 3 network? And if that is a multi-hop l3 network, don?t things get a bit dicey in terms of time-outs, possible changes in packet flows, etc? [Viveks] the use case is to monitor availability of DCGWs from computes in a DC with L3 fabric. There will be multiple (but limited) l3 hops in between. I believe BFD is still applicable in this scenario and it should be okay with possible change in packet flows/paths. Time-outs/false failure detections can be avoided with appropriate/tuned monitoring intervals. Do you see any other issues in this scenario? -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From gvrose8192 at gmail.com Wed Aug 16 17:19:18 2017 From: gvrose8192 at gmail.com (Greg Rose) Date: Wed, 16 Aug 2017 10:19:18 -0700 Subject: [ovs-discuss] question about mtu of vxlan port In-Reply-To: References: Message-ID: <89db6037-429c-6996-309a-feb92ac4128d@gmail.com> On 08/10/2017 11:46 PM, Jiaojianbing wrote: > dear, > > There is a question about mtu of vxlan port. In below scene, there are two node(compute or vm), and we send udp packets between > two docker with nic?s(eth0) mtu setting to 1500. > > Vxlan port?s mtu is 65485 setting in ovs code(we don?t change it). It works well that packet can be sent and receive to/from other > docker. > > But we add conntrack flow table in interface of one bridge, such as: > > ovs-ofctl add-flow $1 "table=0,arp,action=resubmit(,1)" > > ovs-ofctl add-flow $1 "table=0,ip,action=ct(commit,zone=1,table=1)" > > ovs-ofctl add-flow $1 "table=1,actions=NORMAL" > > 1?It is ok with packet length <= 1450 bytes; > > 2?but when we send packet length > 1450 bytes, such as 2000 bytes, the packet will be dropped at > > the vxlan port in the sending node. > > 3?if we modi the mtu of vxlan port from 65485 to 1450, it works well when packet length >=1450. > > First when send big udp packet(len>1450), it will be fragged when send from one docker. > > when add conntrack flow table, udp packet(length>1450) will be deal with do_execute_actions in which ?case OVS_ACTION_ATTR_CT? will > be called. In this switch case, handle_fragments routine is called to > > defrag udp frags. When packet comes to vxlan port, packet is aggregated to one packet with length >1450, then it is compared with > mtu of vxlan port, it is less than 65485(mtu length of vxlan port) > > so it does not frag and pass through to eth0 (mtu=1450), then in routine output_ip it return error code of -90. > > When no conntrack flow table is added, big udp packet will not go through ?case OVS_ACTION_ATTR_CT? in do_execute_actions, then > defrag will not been done. So eack frags with lengh 1450, can go through vxlan port and eth0. > > so my question is, why the mtu of vxlan port is set to 65485(so big!), and can it be modified to 1450? > > [scene]: > > [ Docker0] [ Docker1] > > | | > > [br_int] [br_int] > > | | > > [br_tunnel] [br_tunnel] > > | | | > > [vxlan port] | [vxlan port] > > | | | > > [eth0] - - - - - - - - |- - - - - - - - - - -- -- - [eth0] > > | > > node1 | node 2 > > Try leaving the vxlan port MTU as is (65485) and set the MTU for the eth0 physical ports on node1 and node2 to 1600. - Greg > > _______________________________________________ > discuss mailing list > discuss at openvswitch.org > https://mail.openvswitch.org/mailman/listinfo/ovs-discuss > From nusrat at attaresources.com Wed Aug 16 17:32:35 2017 From: nusrat at attaresources.com (nusrat at attaresources.com) Date: Wed, 16 Aug 2017 12:32:35 -0500 Subject: [ovs-discuss] Service chaining in openvswitch Message-ID: <599481b0.035f620a.64e2c.4dc6@mx.google.com> Hi, Is it possible to service chain in openvswitch w/o using opendaylight? For example, I have 4 ports configured to a bridge in ovs. The server on port 4 serves up http web pages, I want to make a call from a host on port 1 but I want that request to flow to port 2 and then port 3 and finally to port 4. Is this possible? thanks Sent from Mail for Windows 10 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jpettit at ovn.org Wed Aug 16 18:08:55 2017 From: jpettit at ovn.org (Justin Pettit) Date: Wed, 16 Aug 2017 11:08:55 -0700 Subject: [ovs-discuss] Service chaining in openvswitch In-Reply-To: <599481b0.035f620a.64e2c.4dc6@mx.google.com> References: <599481b0.035f620a.64e2c.4dc6@mx.google.com> Message-ID: <888837E9-98BF-407D-98DE-854E7A922386@ovn.org> > On Aug 16, 2017, at 10:32 AM, nusrat at attaresources.com wrote: > > Hi, > Is it possible to service chain in openvswitch w/o using opendaylight? For example, I have 4 ports configured to a bridge in ovs. The server on port 4 serves up http web pages, I want to make a call from a host on port 1 but I want that request to flow to port 2 and then port 3 and finally to port 4. > Is this possible? Yes, you should be able to do such a thing with OpenFlow rules through a controller or the ovs-ofctl command. --Justin From nusrat at attaresources.com Wed Aug 16 18:20:26 2017 From: nusrat at attaresources.com (Nusrat Atta) Date: Wed, 16 Aug 2017 13:20:26 -0500 Subject: [ovs-discuss] Service chaining in openvswitch In-Reply-To: <888837E9-98BF-407D-98DE-854E7A922386@ovn.org> References: <599481b0.035f620a.64e2c.4dc6@mx.google.com> <888837E9-98BF-407D-98DE-854E7A922386@ovn.org> Message-ID: Any tutorials or examples using ovs commands? I don't want to use it via open daylight, so that I can understand it better. Thanks Sent from my iPhone > On Aug 16, 2017, at 1:08 PM, Justin Pettit wrote: > > >> On Aug 16, 2017, at 10:32 AM, nusrat at attaresources.com wrote: >> >> Hi, >> Is it possible to service chain in openvswitch w/o using opendaylight? For example, I have 4 ports configured to a bridge in ovs. The server on port 4 serves up http web pages, I want to make a call from a host on port 1 but I want that request to flow to port 2 and then port 3 and finally to port 4. >> Is this possible? > > Yes, you should be able to do such a thing with OpenFlow rules through a controller or the ovs-ofctl command. > > --Justin > > From jpettit at ovn.org Wed Aug 16 18:25:58 2017 From: jpettit at ovn.org (Justin Pettit) Date: Wed, 16 Aug 2017 11:25:58 -0700 Subject: [ovs-discuss] Service chaining in openvswitch In-Reply-To: References: <599481b0.035f620a.64e2c.4dc6@mx.google.com> <888837E9-98BF-407D-98DE-854E7A922386@ovn.org> Message-ID: <54B64C7B-1FFD-42D7-A31D-6AED4A6CE85E@ovn.org> You should be able to find plenty with a web search. It sounds like you want to configure it manually, so I'd recommend using ovs-ofctl. The OVS man pages are also pretty thorough. --Justin > On Aug 16, 2017, at 11:20 AM, Nusrat Atta wrote: > > Any tutorials or examples using ovs commands? I don't want to use it via open daylight, so that I can understand it better. > Thanks > > Sent from my iPhone > >> On Aug 16, 2017, at 1:08 PM, Justin Pettit wrote: >> >> >>> On Aug 16, 2017, at 10:32 AM, nusrat at attaresources.com wrote: >>> >>> Hi, >>> Is it possible to service chain in openvswitch w/o using opendaylight? For example, I have 4 ports configured to a bridge in ovs. The server on port 4 serves up http web pages, I want to make a call from a host on port 1 but I want that request to flow to port 2 and then port 3 and finally to port 4. >>> Is this possible? >> >> Yes, you should be able to do such a thing with OpenFlow rules through a controller or the ovs-ofctl command. >> >> --Justin >> >> From louis.fourie at huawei.com Wed Aug 16 19:21:27 2017 From: louis.fourie at huawei.com (Henry Fourie) Date: Wed, 16 Aug 2017 19:21:27 +0000 Subject: [ovs-discuss] Service chaining in openvswitch In-Reply-To: <54B64C7B-1FFD-42D7-A31D-6AED4A6CE85E@ovn.org> References: <599481b0.035f620a.64e2c.4dc6@mx.google.com> <888837E9-98BF-407D-98DE-854E7A922386@ovn.org> <54B64C7B-1FFD-42D7-A31D-6AED4A6CE85E@ovn.org> Message-ID: <0F8583BBE82FA449A8B78417CC07559A0B5477AC@SJCEML701-CHM.china.huawei.com> Nurat, SFC is also available in OpenStack: https://docs.openstack.org/networking-sfc/latest/ https://docs.openstack.org/networking-sfc/latest/contributor/ovs_driver_and_agent_workflow.html - Louis -----Original Message----- From: ovs-discuss-bounces at openvswitch.org [mailto:ovs-discuss-bounces at openvswitch.org] On Behalf Of Justin Pettit Sent: Wednesday, August 16, 2017 11:26 AM To: Nusrat Atta Cc: ovs-discuss at openvswitch.org Subject: Re: [ovs-discuss] Service chaining in openvswitch You should be able to find plenty with a web search. It sounds like you want to configure it manually, so I'd recommend using ovs-ofctl. The OVS man pages are also pretty thorough. --Justin > On Aug 16, 2017, at 11:20 AM, Nusrat Atta wrote: > > Any tutorials or examples using ovs commands? I don't want to use it via open daylight, so that I can understand it better. > Thanks > > Sent from my iPhone > >> On Aug 16, 2017, at 1:08 PM, Justin Pettit wrote: >> >> >>> On Aug 16, 2017, at 10:32 AM, nusrat at attaresources.com wrote: >>> >>> Hi, >>> Is it possible to service chain in openvswitch w/o using opendaylight? For example, I have 4 ports configured to a bridge in ovs. The server on port 4 serves up http web pages, I want to make a call from a host on port 1 but I want that request to flow to port 2 and then port 3 and finally to port 4. >>> Is this possible? >> >> Yes, you should be able to do such a thing with OpenFlow rules through a controller or the ovs-ofctl command. >> >> --Justin >> >> _______________________________________________ discuss mailing list discuss at openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss From batmanustc at gmail.com Thu Aug 17 06:30:52 2017 From: batmanustc at gmail.com (Sam) Date: Thu, 17 Aug 2017 14:30:52 +0800 Subject: [ovs-discuss] [ovs-dpdk-tests] where is ovs-dpdk test case? Message-ID: Hi all, I'm working with ovs-dpdk, I want to run ovs-dpdk test case. But I found there is no test case for 'netdev' type bridge and no test case for ovs-dpdk datapath(which is pmd_thread_main). So my question is where could I find these test cases? Also I change some code in dpdk-vhost client mode, how could I find test case for this module? Thank you~ -------------- next part -------------- An HTML attachment was scrubbed... URL: From sara.gittlin at gmail.com Thu Aug 17 06:56:39 2017 From: sara.gittlin at gmail.com (Sara Gittlin) Date: Thu, 17 Aug 2017 09:56:39 +0300 Subject: [ovs-discuss] Hashing to megaflow entry Message-ID: Hi, Suppose we support megaflows, How the hashing is performed in the kernel module ? when packet arrives how do we know 'beforehand' to mask key fields in order to hit the megaflow entry ? Thank in advance Sara From jpettit at ovn.org Thu Aug 17 06:59:38 2017 From: jpettit at ovn.org (Justin Pettit) Date: Wed, 16 Aug 2017 23:59:38 -0700 Subject: [ovs-discuss] Hashing to megaflow entry In-Reply-To: References: Message-ID: > On Aug 16, 2017, at 11:56 PM, Sara Gittlin wrote: > > Hi, > Suppose we support megaflows, How the hashing is performed in the > kernel module ? > when packet arrives how do we know 'beforehand' to mask key fields in > order to hit the megaflow entry ? If you haven't done so already, I'd highly recommend looking at our NSDI paper that answers many of your questions: https://www.usenix.org/system/files/conference/nsdi15/nsdi15-paper-pfaff.pdf I hope you find it helpful. --Justin From mark.b.kavanagh at intel.com Thu Aug 17 12:07:09 2017 From: mark.b.kavanagh at intel.com (Kavanagh, Mark B) Date: Thu, 17 Aug 2017 12:07:09 +0000 Subject: [ovs-discuss] [dpdk-dev] [ovs-dpdk-tests] where is ovs-dpdk test case? In-Reply-To: References: Message-ID: >From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Sam >Sent: Thursday, August 17, 2017 7:31 AM >To: ovs-discuss at openvswitch.org; ovs-dev at openvswitch.org; dev at dpdk.org Hi Sam, Just a heads-up that dev at dpdk.org is strictly for DPDK development threads - I've removed it from this thread. Also, responses to your queries are inline. Thanks! Mark >Subject: [dpdk-dev] [ovs-dpdk-tests] where is ovs-dpdk test case? > >Hi all, > >I'm working with ovs-dpdk, I want to run ovs-dpdk test case. But I found >there is no test case for 'netdev' type bridge and no test case for >ovs-dpdk datapath(which is pmd_thread_main). Do you mean unit tests (as in OvS autotests), or integration tests? If the former, then unfortunately there are none at present within OvS (but feel free to add some!); if you'd like to run integration tests, you could take a look at VSPERF: https://etherpad.opnfv.org/p/vSwitchIntegrationTests. > >So my question is where could I find these test cases? > >Also I change some code in dpdk-vhost client mode, how could I find test >case for this module? > >Thank you~ From Volkan.Atli at argela.com.tr Thu Aug 17 18:57:34 2017 From: Volkan.Atli at argela.com.tr (Ali Volkan Atli) Date: Thu, 17 Aug 2017 18:57:34 +0000 Subject: [ovs-discuss] In-band problem for OvS+DPDK Message-ID: <6109f11ef2424edca13eb7a0b3d4525a@MX2.argela.com.tr> Hi In-band operation does not seem to work correctly with DPDK based Open vSwitch I have two boxes running OvS+DPDK, sw1 (ip: 10.10.10.12, mac: 0c:c4:7a:93:a5:ad) and sw2 (ip: 10.10.10.11). sw1's openflow port is connected to sw2's dataport (dpdk binded) and sw2's openflow port is connected directly to ryu controller laptop (ip: 10.10.10.10). I did not disable in-band for connection-mode: ----- argela2 at vswitch2:~$ sudo ovs-vsctl --columns=other_config list bridge other_config : {} ----- In this case, sw1 cannot connect controller via sw2 because when sw1 is trying to reach controller using arp-request, sw2 encapsulates the sw1's arp-requests into packet-in messages. ----- argela2 at vswitch2:~$ sudo ovs-appctl bridge/dump-flows br0 duration=3822s, n_packets=0, n_bytes=0, priority=180008,tcp,nw_src=10.10.10.10,tp_src=6633,actions=NORMAL duration=3822s, n_packets=0, n_bytes=0, priority=180007,tcp,nw_dst=10.10.10.10,tp_dst=6633,actions=NORMAL duration=3822s, n_packets=0, n_bytes=0, priority=180006,arp,arp_spa=10.10.10.10,arp_op=1,actions=NORMAL duration=3822s, n_packets=0, n_bytes=0, priority=180005,arp,arp_tpa=10.10.10.10,arp_op=2,actions=NORMAL duration=3822s, n_packets=0, n_bytes=0, priority=180002,arp,dl_src=0c:c4:7a:97:e5:2a,arp_op=1,actions=NORMAL duration=3822s, n_packets=0, n_bytes=0, priority=180001,arp,dl_dst=0c:c4:7a:97:e5:2a,arp_op=2,actions=NORMAL duration=3822s, n_packets=0, n_bytes=0, priority=180000,udp,in_port=LOCAL,dl_src=0c:c4:7a:97:e5:2a,tp_src=68,tp_dst=67,actions=NORMAL duration=3822s, n_packets=2055, n_bytes=123484, priority=0,actions=CONTROLLER:65535 table_id=254, duration=3822s, n_packets=0, n_bytes=0, priority=2,recirc_id=0,actions=drop table_id=254, duration=3822s, n_packets=0, n_bytes=0, priority=0,reg0=0x1,actions=controller(reason=) table_id=254, duration=3822s, n_packets=0, n_bytes=0, priority=0,reg0=0x2,actions=drop table_id=254, duration=3822s, n_packets=0, n_bytes=0, priority=0,reg0=0x3,actions=drop ----- argela2 at vswitch2:~$ sudo ovs-appctl dpif/dump-flows br0 recirc_id(0),in_port(5),eth(src=0c:c4:7a:93:a5:ad,dst=ff:ff:ff:ff:ff:ff),eth_type(0x0806),arp(sip=10.10.10.12,tip=10.10.10.10,op=1/0xff), packets:2055, bytes:123300, used:0.536s, actions:userspace(pid=0,slow_path(controller)) ----- argela2 at vswitch2:~$ route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 0.0.0.0 10.10.10.1 0.0.0.0 UG 0 0 0 eno2 10.10.10.0 0.0.0.0 255.255.255.0 U 0 0 0 eno2 169.254.0.0 0.0.0.0 255.255.0.0 U 1000 0 0 eno2 ----- When I check bridge/dump-flows at sw2, I cannot see any hidden flows to build a transparent path between sw1 and controller. I could not find what I was doing wrong or what I think is wrong. dpdk version is dpdk-stable-16.07.2, ----- argela2 at vswitch2:~$ ovs-vsctl --vers ovs-vsctl (Open vSwitch) 2.6.90 DB Schema 7.14.0 ----- argela2 at vswitch2:~$ uname -a Linux vswitch2 4.10.0-28-generic #32~16.04.2-Ubuntu SMP Thu Jul 20 10:19:48 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux ----- Thanks in advance - Volkan From joe at ovn.org Thu Aug 17 21:34:19 2017 From: joe at ovn.org (Joe Stringer) Date: Thu, 17 Aug 2017 14:34:19 -0700 Subject: [ovs-discuss] [ovs-dev] [dpdk-dev] [ovs-dpdk-tests] where is ovs-dpdk test case? In-Reply-To: References: Message-ID: On 17 August 2017 at 05:07, Kavanagh, Mark B wrote: > >>From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Sam >>Sent: Thursday, August 17, 2017 7:31 AM >>To: ovs-discuss at openvswitch.org; ovs-dev at openvswitch.org; dev at dpdk.org > > Hi Sam, > > Just a heads-up that dev at dpdk.org is strictly for DPDK development threads - I've removed it from this thread. > > Also, responses to your queries are inline. > > Thanks! > Mark > > >>Subject: [dpdk-dev] [ovs-dpdk-tests] where is ovs-dpdk test case? >> >>Hi all, >> >>I'm working with ovs-dpdk, I want to run ovs-dpdk test case. But I found >>there is no test case for 'netdev' type bridge and no test case for >>ovs-dpdk datapath(which is pmd_thread_main). > > Do you mean unit tests (as in OvS autotests), or integration tests? > > If the former, then unfortunately there are none at present within OvS (but feel free to add some!); if you'd like to run integration tests, you could take a look at VSPERF: https://etherpad.opnfv.org/p/vSwitchIntegrationTests. "make check" runs unit tests against the userspace datapath, and it should work with a DPDK-enabled build of OVS. I don't know how much it tests the DPDK-specific portions of this, however. For example, it won't use DPDK devices. From batmanustc at gmail.com Fri Aug 18 01:17:27 2017 From: batmanustc at gmail.com (Sam) Date: Fri, 18 Aug 2017 09:17:27 +0800 Subject: [ovs-discuss] How to refresh test cases in tests folder? Message-ID: Hi all, I'm running my test cases, I define a new macro in ofproto-macro.at like this; m4_define([_OVS_VSWITCHD_START], > [OVS_RUNDIR=/usr/local/var/run/openvswitch; export OVS_RUNDIR > OVS_LOGDIR=/usr/local/var/log/openvswitch; export OVS_LOGDIR > OVS_DBDIR=/usr/local/var/run/openvswitch; export OVS_DBDIR > dnl OVS_SYSCONFDIR=; export OVS_SYSCONFDIR > /etc/init.d/openvswitch stop > OVS_WAIT_UNTIL([tail -n 3 $OVS_LOGDIR/ovs-ctl.log | grep > "Killing ovsdb-server"]) > /etc/init.d/openvswitch start > OVS_WAIT_UNTIL([tail -n 3 $OVS_LOGDIR/ovs-ctl.log | \ > grep "Enabling remote OVSDB managers."]) > ]) And this got wrong, so I change it into this: m4_define([_OVS_VSWITCHD_START], > [OVS_RUNDIR=/usr/local/var/run/openvswitch; export OVS_RUNDIR > OVS_LOGDIR=/usr/local/var/log/openvswitch; export OVS_LOGDIR > OVS_DBDIR=/usr/local/var/run/openvswitch; export OVS_DBDIR > dnl OVS_SYSCONFDIR=; export OVS_SYSCONFDIR > /etc/init.d/openvswitch stop > OVS_WAIT_UNTIL([tail -n 3 $OVS_LOGDIR/ovs-ctl.log | \ > grep "Killing ovsdb-server"]) > /etc/init.d/openvswitch start > OVS_WAIT_UNTIL([tail -n 3 $OVS_LOGDIR/ovs-ctl.log | \ > grep "Enabling remote OVSDB managers."]) > ]) But after I reconfigure the ovs, and run `make check`, I got same error as first, which is : /home/gangyewei-3/mvs/mvs/tests/testsuite.dir/at-groups/1/test-source: line > 41: Enabling remote OVSDB managers.: command not found > stdout: > ./netdev-dpdk.at:24: exit code was 1, expected 0 I think this is because the bug of first code, but I have change it into 2nd code, I don't know why still got error, or I have to re-run `boot.sh` in OVS folder to re-construct test cases? -------------- next part -------------- An HTML attachment was scrubbed... URL: From batmanustc at gmail.com Fri Aug 18 03:27:03 2017 From: batmanustc at gmail.com (Sam) Date: Fri, 18 Aug 2017 11:27:03 +0800 Subject: [ovs-discuss] How to refresh test cases in tests folder? In-Reply-To: References: Message-ID: I have to ./boot.sh, then the test case will refresh 2017-08-18 9:17 GMT+08:00 Sam : > Hi all, > > I'm running my test cases, I define a new macro in ofproto-macro.at like > this; > > m4_define([_OVS_VSWITCHD_START], >> [OVS_RUNDIR=/usr/local/var/run/openvswitch; export OVS_RUNDIR >> OVS_LOGDIR=/usr/local/var/log/openvswitch; export OVS_LOGDIR >> OVS_DBDIR=/usr/local/var/run/openvswitch; export OVS_DBDIR >> dnl OVS_SYSCONFDIR=; export OVS_SYSCONFDIR >> /etc/init.d/openvswitch stop >> OVS_WAIT_UNTIL([tail -n 3 $OVS_LOGDIR/ovs-ctl.log | grep >> "Killing ovsdb-server"]) >> /etc/init.d/openvswitch start >> OVS_WAIT_UNTIL([tail -n 3 $OVS_LOGDIR/ovs-ctl.log | \ >> grep "Enabling remote OVSDB managers."]) >> ]) > > > And this got wrong, so I change it into this: > > m4_define([_OVS_VSWITCHD_START], >> [OVS_RUNDIR=/usr/local/var/run/openvswitch; export OVS_RUNDIR >> OVS_LOGDIR=/usr/local/var/log/openvswitch; export OVS_LOGDIR >> OVS_DBDIR=/usr/local/var/run/openvswitch; export OVS_DBDIR >> dnl OVS_SYSCONFDIR=; export OVS_SYSCONFDIR >> /etc/init.d/openvswitch stop >> OVS_WAIT_UNTIL([tail -n 3 $OVS_LOGDIR/ovs-ctl.log | \ >> grep "Killing ovsdb-server"]) >> /etc/init.d/openvswitch start >> OVS_WAIT_UNTIL([tail -n 3 $OVS_LOGDIR/ovs-ctl.log | \ >> grep "Enabling remote OVSDB managers."]) >> ]) > > > But after I reconfigure the ovs, and run `make check`, I got same error as > first, which is : > > /home/gangyewei-3/mvs/mvs/tests/testsuite.dir/at-groups/1/test-source: >> line 41: Enabling remote OVSDB managers.: command not found >> stdout: >> ./netdev-dpdk.at:24: exit code was 1, expected 0 > > > I think this is because the bug of first code, but I have change it into > 2nd code, I don't know why still got error, or I have to re-run `boot.sh` > in OVS folder to re-construct test cases? > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From batmanustc at gmail.com Fri Aug 18 05:07:46 2017 From: batmanustc at gmail.com (Sam) Date: Fri, 18 Aug 2017 13:07:46 +0800 Subject: [ovs-discuss] Why 'OVS_VSWITCHD_STOP' do not run? Message-ID: Hi all, I'm running my ovs test case(my-test.at) like this, but when 'OVS_VSWITCHD_START' or other AT_CHECK failed, 'OVS_VSWITCHD_STOP' will not run, why and how to fix this to let 'OVS_VSWITCHD_STOP' run anyway. Thank you~ -------------- next part -------------- An HTML attachment was scrubbed... URL: From blp at ovn.org Fri Aug 18 14:44:57 2017 From: blp at ovn.org (Ben Pfaff) Date: Fri, 18 Aug 2017 07:44:57 -0700 Subject: [ovs-discuss] [ovs-dev] Why 'OVS_VSWITCHD_STOP' do not run? In-Reply-To: References: Message-ID: <20170818144457.GV6175@ovn.org> Please don't post to both ovs-dev and ovs-discuss. I've moved discuss to BCC. On Fri, Aug 18, 2017 at 01:07:46PM +0800, Sam wrote: > I'm running my ovs test case(my-test.at) like this, but when > 'OVS_VSWITCHD_START' or other AT_CHECK failed, 'OVS_VSWITCHD_STOP' will > not run, why and how to fix this to let 'OVS_VSWITCHD_STOP' run anyway. When AT_CHECK fails, the remainder of the test doesn't run. If you need to add cleanup code, you can use the on_exit shell function. From blp at ovn.org Fri Aug 18 14:51:50 2017 From: blp at ovn.org (Ben Pfaff) Date: Fri, 18 Aug 2017 07:51:50 -0700 Subject: [ovs-discuss] [ovs-dev] How to refresh test cases in tests folder? In-Reply-To: References: Message-ID: <20170818145150.GW6175@ovn.org> Please don't post to both ovs-discuss and ovs-dev. Moving ovs-discuss to BCC. On Fri, Aug 18, 2017 at 09:17:27AM +0800, Sam wrote: > Hi all, > > I'm running my test cases, I define a new macro in ofproto-macro.at like > this; > > m4_define([_OVS_VSWITCHD_START], > > [OVS_RUNDIR=/usr/local/var/run/openvswitch; export OVS_RUNDIR > > OVS_LOGDIR=/usr/local/var/log/openvswitch; export OVS_LOGDIR > > OVS_DBDIR=/usr/local/var/run/openvswitch; export OVS_DBDIR > > dnl OVS_SYSCONFDIR=; export OVS_SYSCONFDIR > > /etc/init.d/openvswitch stop > > OVS_WAIT_UNTIL([tail -n 3 $OVS_LOGDIR/ovs-ctl.log | grep > > "Killing ovsdb-server"]) > > /etc/init.d/openvswitch start > > OVS_WAIT_UNTIL([tail -n 3 $OVS_LOGDIR/ovs-ctl.log | \ > > grep "Enabling remote OVSDB managers."]) > > ]) > > > And this got wrong, so I change it into this: > > m4_define([_OVS_VSWITCHD_START], > > [OVS_RUNDIR=/usr/local/var/run/openvswitch; export OVS_RUNDIR > > OVS_LOGDIR=/usr/local/var/log/openvswitch; export OVS_LOGDIR > > OVS_DBDIR=/usr/local/var/run/openvswitch; export OVS_DBDIR > > dnl OVS_SYSCONFDIR=; export OVS_SYSCONFDIR > > /etc/init.d/openvswitch stop > > OVS_WAIT_UNTIL([tail -n 3 $OVS_LOGDIR/ovs-ctl.log | \ > > grep "Killing ovsdb-server"]) > > /etc/init.d/openvswitch start > > OVS_WAIT_UNTIL([tail -n 3 $OVS_LOGDIR/ovs-ctl.log | \ > > grep "Enabling remote OVSDB managers."]) > > ]) > > > But after I reconfigure the ovs, and run `make check`, I got same error as > first, which is : > > /home/gangyewei-3/mvs/mvs/tests/testsuite.dir/at-groups/1/test-source: line > > 41: Enabling remote OVSDB managers.: command not found > > stdout: > > ./netdev-dpdk.at:24: exit code was 1, expected 0 > > > I think this is because the bug of first code, but I have change it into > 2nd code, I don't know why still got error, or I have to re-run `boot.sh` > in OVS folder to re-construct test cases? "make check" is enough to rebuild the testsuite. If you're unsure about that, you can "rm" the testsuite and re-run. From rahul.kenu at gmail.com Sun Aug 20 17:10:08 2017 From: rahul.kenu at gmail.com (Rahul Sharma) Date: Sun, 20 Aug 2017 22:40:08 +0530 Subject: [ovs-discuss] Adding a new action (port statistics) Message-ID: Hi everyone, I am new here, so in case this has already been answered, or it's not the appropriate place to ask, kindly let me know. I am trying to add a custom action to openflow by making some code changes in the OVS. The action which would send port statistics to the controller on receipt of a particular matching packet. Would the proper procedure to add such an action be documented somewhere, as it would make things quite easier for me. Thanks, -- Regards, *Rahul Sharma* 5th YearMaster of Science (Hons), PhysicsBachelor of Engineering (Hons), Computer Science *????????????????????????????????????????????????????????* *Birla Institute of Technology & Science,* *Pilani* Pilani Campus, Vidhya Vihar, Pilani, Rajasthan - 333 031, INDIA. ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From duraivelanc at gmail.com Sun Aug 20 19:12:32 2017 From: duraivelanc at gmail.com (Durai Velan Chockalingam) Date: Sun, 20 Aug 2017 21:12:32 +0200 Subject: [ovs-discuss] Reg: Ovs-Dpdk Forwarding Plane. Message-ID: Hello All, Am trying to look for very comprehensive information on How Packet are Handled in Dataplane, for the following communication 1) VM-2-VM in Same compute host ( and both of them are vhostdpdkuser ) I understand that vhostdpdkuser, is nothing but a Unix Socket open, by Ovs-Dpdk and VM are Client. However, I could not undertstand how forwarding of packets are happening between the VM via Socket ?? Does OVS Maintains any Forwarding Information bases for DPDK Vhostuser and if so what is tool to interact without those fibs ?? 2) VM (Compute Host Network / or VLAN Say 10.0.0.1)-2-PHY--- L2 DEVICE ----2-VM (Another Compute Host, Same Network / or VLAN Say 10.0.0.2 ) Similary, how does Packet flow in this Scenario, and what kind of configuration should be make in L2 Device Any References, or Documentation explaining this would be also appreciated. Thanks and Regards Durai Velan. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ankaiah.nallamekala at wipro.com Mon Aug 21 09:43:22 2017 From: ankaiah.nallamekala at wipro.com (ankaiah.nallamekala at wipro.com) Date: Mon, 21 Aug 2017 09:43:22 +0000 Subject: [ovs-discuss] Regarding CFM/OAM support in Openvswitch In-Reply-To: <20170808165608.GZ6175@ovn.org> References: <20170808165608.GZ6175@ovn.org> Message-ID: Thanks a lot Ben for clarification. Any future plans for supporting full pledged 802.1ag support, i.e. all 3(CCM,LBM,LTM) protocols, Please let me know. Thanks, Anki -----Original Message----- From: Ben Pfaff [mailto:blp at ovn.org] Sent: Tuesday, August 8, 2017 10:26 PM To: Ankaiah Nallamekala (MFG & Tech) Cc: ovs-dev at openvswitch.org; ovs-discuss at openvswitch.org Subject: Re: [ovs-discuss] Regarding CFM/OAM support in Openvswitch ** This mail has been sent from an external source. Treat hyperlinks and attachments in this email with caution** On Tue, Aug 08, 2017 at 02:07:25PM +0000, ankaiah.nallamekala at wipro.com wrote: > Ethernet CFM/OAM supports Loopback protocol(LBM) and Link Trace > protocol(LTM), Is ovs is supporting these two protocols as well, if so > could you please describe how to use these two protocols. OVS doesn't support those. ______________________________________________________________________ This email has been scanned by the Symantec Email Security.cloud service. For more information please visit http://www.symanteccloud.com ______________________________________________________________________ The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com From sara.gittlin at gmail.com Mon Aug 21 11:21:35 2017 From: sara.gittlin at gmail.com (Sara Gittlin) Date: Mon, 21 Aug 2017 14:21:35 +0300 Subject: [ovs-discuss] Hashing to megaflow entry In-Reply-To: References: Message-ID: Thank you Justin, Indeed this article is very helpful. i understand from the article, that generating megaflows and installing in the kernel cache is already implemented in userspace - ovs. Before reading this article, i thought that megaflows were implemented only for L2 normal mode. Sara On Thu, Aug 17, 2017 at 9:59 AM, Justin Pettit wrote: > >> On Aug 16, 2017, at 11:56 PM, Sara Gittlin wrote: >> >> Hi, >> Suppose we support megaflows, How the hashing is performed in the >> kernel module ? >> when packet arrives how do we know 'beforehand' to mask key fields in >> order to hit the megaflow entry ? > > If you haven't done so already, I'd highly recommend looking at our NSDI paper that answers many of your questions: > > https://www.usenix.org/system/files/conference/nsdi15/nsdi15-paper-pfaff.pdf > > I hope you find it helpful. > > --Justin > > From JaiSingh.Rana at cavium.com Mon Aug 21 11:43:01 2017 From: JaiSingh.Rana at cavium.com (Rana, JaiSingh) Date: Mon, 21 Aug 2017 11:43:01 +0000 Subject: [ovs-discuss] ovn-bridge-mappings configuration issue. Message-ID: Hi, For configuring external gateway, ovn-controller man page says: " external_ids:ovn-bridge-mappings A list of key-value pairs that map a physical network name to a local ovs bridge that provides connectivity to that network. An example value mapping two physical network names to two ovs bridges would be: phys? net1:br-eth0,physnet2:br-eth1. " Created bridge br-ex and attached an interface p1p2 having external connectivity. # ovs-vsctl --may-exist add-br br-ex -- set bridge br-ex protocols=OpenFlow13 # ovs-vsctl set open . external-ids:ovn-bridge-mappings=provider:br-ex # ovs-vsctl --may-exist add-port br-ex p1p2 After configuring Openstack with external networks, ovn-controller on compute actually looks for bridge named "provider" in ovn/controller/patch.c : add_bridge_mappings, which of-course is not created but throws error that "br-ex" not found as can be seen in ovn-controller.log "2017-08-18T11:20:30.477Z|04536|patch|ERR| bridge not found for localnet port 'provnet-031111bf-ad69-4225-b69c-0cd23d7969af' with network name 'br-ex'" When this external-id is defined as ovn-bridge-mappings=br-ex:br-ex, it works fine and no error is thrown. Is this a bug or the field before ":" in this external-id represents bridge name. Thanks, Jai -------------- next part -------------- An HTML attachment was scrubbed... URL: From zjtang at biigroup.cn Mon Aug 21 10:09:57 2017 From: zjtang at biigroup.cn (=?UTF-8?B?5ZSQ5b+X5Yab?=) Date: Mon, 21 Aug 2017 18:09:57 +0800 Subject: [ovs-discuss] Problem when installing OVS with DPDK Message-ID: <599AB175.5080305@biigroup.cn> Hi, My name is Zhijun, I'm from Beijing Internet Institute, China. I am trying to install OVS with DPDK. I have got many helpful instructions from your official doc, http://docs.openvswitch.org/en/latest/intro/install/dpdk/ But I also get problems. I am using OVS-2.72 and DPDK-17.05.1 After I have compiled and installed DPDK, I run make OVS, and I get an ERROR says /'lib/netdev-dpdk.c:34:28: fatal error: rte_virtio_net.h: No such file or directory'. /I check the release note of DPDK-17.05.1 and find that /rte_virtio_net.h /has been renamed as /rte_vhost.h /and some macros have been removed. Must I use a lower version of DPDK to install OVS? Or otherwise, how can I install OVS with DPDK? I don't know how to do now, hope you can give me some help. Best Regards, Zhijun -------------- next part -------------- An HTML attachment was scrubbed... URL: From sherif.fahmy at epfl.ch Mon Aug 21 12:28:35 2017 From: sherif.fahmy at epfl.ch (Fahmy Sherif Alaa Salaheldin) Date: Mon, 21 Aug 2017 12:28:35 +0000 Subject: [ovs-discuss] [Super TIME SENSITIVE] Setting QOS for OVS Swtiches Message-ID: <1503318515374.41738@epfl.ch> Good Afternoon, I am trying to use Mininet together with OVS and a RYU controller to emulate a simple network. I was wondering if some could tell me IF it is possible to set queues/qos through linux tc and then they would show up in the commands: sh ovs-vsctl list Qos sh ovs-vsctl list Queue What I am doing now is for instance, tc qdisc add dev s2-eth5 rot handle 1: drr then add two sub classes (what I want as my queues) tc class add dev s2-eth5 parent 1: classid 1:1 drr quantum 100 tc class add dev s2-eth5 parent 1: classid 1:2 drr quantum 200 then because I know it is necessary I add a filter that basically let's everything pass through it, tc filter add dev eth0 protocol ip parent 1: prio 1 u32 But nothing shows in my queues/qos tables.. I am a beginner and I apologize if this is trivial but any thoughts? My goal is to create one QOS per port that has 2-3 queues that are served in a Deficit Round Robin (DRR) Fashion!! Best, Sherif -------------- next part -------------- An HTML attachment was scrubbed... URL: From sara.gittlin at gmail.com Mon Aug 21 15:19:07 2017 From: sara.gittlin at gmail.com (Sara Gittlin) Date: Mon, 21 Aug 2017 18:19:07 +0300 Subject: [ovs-discuss] Hashing to megaflow entry In-Reply-To: References: Message-ID: One more - I did not see in the article that if a match is found in megaflow cache - then a microflow is generated to be installed in the microflow cache to improve performance for subsequnce packets Sara On Mon, Aug 21, 2017 at 2:21 PM, Sara Gittlin wrote: > Thank you Justin, > Indeed this article is very helpful. > i understand from the article, that generating megaflows and > installing in the kernel cache is already implemented in userspace - > ovs. > Before reading this article, i thought that megaflows were implemented > only for L2 normal mode. > Sara > > > > On Thu, Aug 17, 2017 at 9:59 AM, Justin Pettit wrote: >> >>> On Aug 16, 2017, at 11:56 PM, Sara Gittlin wrote: >>> >>> Hi, >>> Suppose we support megaflows, How the hashing is performed in the >>> kernel module ? >>> when packet arrives how do we know 'beforehand' to mask key fields in >>> order to hit the megaflow entry ? >> >> If you haven't done so already, I'd highly recommend looking at our NSDI paper that answers many of your questions: >> >> https://www.usenix.org/system/files/conference/nsdi15/nsdi15-paper-pfaff.pdf >> >> I hope you find it helpful. >> >> --Justin >> >> From russell at ovn.org Mon Aug 21 15:47:27 2017 From: russell at ovn.org (Russell Bryant) Date: Mon, 21 Aug 2017 11:47:27 -0400 Subject: [ovs-discuss] ovn-bridge-mappings configuration issue. In-Reply-To: References: Message-ID: On Mon, Aug 21, 2017 at 7:43 AM, Rana, JaiSingh wrote: > Hi, > > For configuring external gateway, ovn-controller man page says: > > " > > external_ids:ovn-bridge-mappings > A list of key-value pairs that map a physical network > name to a local ovs bridge that provides connectivity > to that network. An example value mapping two > physical network names to two ovs bridges would be: phys? > net1:br-eth0,physnet2:br-eth1. > " > > > Created bridge br-ex and attached an interface p1p2 having external > connectivity. > > > # ovs-vsctl --may-exist add-br br-ex -- set bridge br-ex > protocols=OpenFlow13 > > # ovs-vsctl set open . external-ids:ovn-bridge-mappings=provider:br-ex > # ovs-vsctl --may-exist add-port br-ex p1p2 > > > After configuring Openstack with external networks, ovn-controller on > compute actually looks for bridge named "provider" in > ovn/controller/patch.c : add_bridge_mappings, which of-course is not created > but throws error that "br-ex" not found as can be seen in ovn-controller.log > > "2017-08-18T11:20:30.477Z|04536|patch|ERR| bridge not found for localnet > port 'provnet-031111bf-ad69-4225-b69c-0cd23d7969af' with network name > 'br-ex'" > > When this external-id is defined as ovn-bridge-mappings=br-ex:br-ex, it > works fine and no error is thrown. > > > Is this a bug or the field before ":" in this external-id represents bridge > name. The error message indicates that a "localnet" was created with a "network_name" of "br-ex". The "network_name" should be set to "provider" in this example. -- Russell Bryant From blp at ovn.org Mon Aug 21 18:11:04 2017 From: blp at ovn.org (Ben Pfaff) Date: Mon, 21 Aug 2017 11:11:04 -0700 Subject: [ovs-discuss] Regarding CFM/OAM support in Openvswitch In-Reply-To: References: <20170808165608.GZ6175@ovn.org> Message-ID: <20170821181104.GI6175@ovn.org> [moving ovs-dev to BCC] I don't know of anyone working on them, but we'd accept implementations if they were well written. On Mon, Aug 21, 2017 at 09:43:22AM +0000, ankaiah.nallamekala at wipro.com wrote: > Thanks a lot Ben for clarification. > > Any future plans for supporting full pledged 802.1ag support, i.e. all 3(CCM,LBM,LTM) protocols, Please let me know. > > > Thanks, > Anki > > -----Original Message----- > From: Ben Pfaff [mailto:blp at ovn.org] > Sent: Tuesday, August 8, 2017 10:26 PM > To: Ankaiah Nallamekala (MFG & Tech) > Cc: ovs-dev at openvswitch.org; ovs-discuss at openvswitch.org > Subject: Re: [ovs-discuss] Regarding CFM/OAM support in Openvswitch > > ** This mail has been sent from an external source. Treat hyperlinks and attachments in this email with caution** > > On Tue, Aug 08, 2017 at 02:07:25PM +0000, ankaiah.nallamekala at wipro.com wrote: > > Ethernet CFM/OAM supports Loopback protocol(LBM) and Link Trace > > protocol(LTM), Is ovs is supporting these two protocols as well, if so > > could you please describe how to use these two protocols. > > OVS doesn't support those. > > ______________________________________________________________________ > This email has been scanned by the Symantec Email Security.cloud service. > For more information please visit http://www.symanteccloud.com ______________________________________________________________________ > The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com From blp at ovn.org Mon Aug 21 18:14:44 2017 From: blp at ovn.org (Ben Pfaff) Date: Mon, 21 Aug 2017 11:14:44 -0700 Subject: [ovs-discuss] Problem when installing OVS with DPDK In-Reply-To: <599AB175.5080305@biigroup.cn> References: <599AB175.5080305@biigroup.cn> Message-ID: <20170821181444.GJ6175@ovn.org> On Mon, Aug 21, 2017 at 06:09:57PM +0800, ??? wrote: > But I also get problems. I am using OVS-2.72 and DPDK-17.05.1 OVS 2.7.2 uses DPDK 16.11. From jpettit at ovn.org Mon Aug 21 22:09:52 2017 From: jpettit at ovn.org (Justin Pettit) Date: Mon, 21 Aug 2017 15:09:52 -0700 Subject: [ovs-discuss] Hashing to megaflow entry In-Reply-To: References: Message-ID: > On Aug 21, 2017, at 8:19 AM, Sara Gittlin wrote: > > One more - I did not see in the article that if a match is found in > megaflow cache - then a microflow is generated to be installed in the > microflow cache to improve performance for subsequnce packets An exact-match cache (microflow cache) is an implementation of the datapath. The userspace and out-of-tree OVS Linux kernel module that ships as part of OVS contain an exact-match cache that's managed by the datapath. The upstream OVS kernel module that ships with the Linux kernel was rejected by the Linux upstream community, so it does not contain one. --Justin From jpettit at ovn.org Mon Aug 21 22:12:37 2017 From: jpettit at ovn.org (Justin Pettit) Date: Mon, 21 Aug 2017 15:12:37 -0700 Subject: [ovs-discuss] Adding a new action (port statistics) In-Reply-To: References: Message-ID: <70ADF912-8167-467E-86EC-C1670098E51D@ovn.org> > On Aug 20, 2017, at 10:10 AM, Rahul Sharma wrote: > > Hi everyone, > > I am new here, so in case this has already been answered, or it's not the appropriate place to ask, kindly let me know. > > I am trying to add a custom action to openflow by making some code changes in the OVS. The action which would send port statistics to the controller on receipt of a particular matching packet. Would the proper procedure to add such an action be documented somewhere, as it would make things quite easier for me. The implementation would vary depending on which datapath you're targeting, but the general answer is that there is not such documentation. What you may want to do is look for when such a feature was introduced in the past and look at the commit to see what changes were made. Good luck! --Justin From jpettit at ovn.org Mon Aug 21 22:20:19 2017 From: jpettit at ovn.org (Justin Pettit) Date: Mon, 21 Aug 2017 15:20:19 -0700 Subject: [ovs-discuss] [Super TIME SENSITIVE] Setting QOS for OVS Swtiches In-Reply-To: <1503318515374.41738@epfl.ch> References: <1503318515374.41738@epfl.ch> Message-ID: <265E919F-BBB2-4A0C-96EB-EF07775DF98A@ovn.org> > On Aug 21, 2017, at 5:28 AM, Fahmy Sherif Alaa Salaheldin wrote: > > Good Afternoon, > > I am trying to use Mininet together with OVS and a RYU controller to emulate a simple network. > > I was wondering if some could tell me IF it is possible to set queues/qos through linux tc and then they would show up in the commands: > > sh ovs-vsctl list Qos > sh ovs-vsctl list Queue > > What I am doing now is for instance, > > tc qdisc add dev s2-eth5 rot handle 1: drr > > then add two sub classes (what I want as my queues) > > tc class add dev s2-eth5 parent 1: classid 1:1 drr quantum 100 > tc class add dev s2-eth5 parent 1: classid 1:2 drr quantum 200 > > then because I know it is necessary I add a filter that basically let's everything pass through it, > > tc filter add dev eth0 protocol ip parent 1: prio 1 u32 > > But nothing shows in my queues/qos tables.. I am a beginner and I apologize if this is trivial but any thoughts? > My goal is to create one QOS per port that has 2-3 queues that are served in a Deficit Round Robin (DRR) Fashion!! OVS uses the tc subsystem in the opposite direction that you're suggesting. Those ovs-vsctl commands modify fields in a database. ovs-vswitchd takes that configuration and makes tc calls to configure qos on Linux. If you call tc directly, OVS will not read your changes back and update the configuration database. If OVS does not provide the configuration knobs you want, you can directly call tc and skip the ovs-vsctl configuration entirely. I would be careful if you do both, though, since you're likely to get a broken configuration if both you and ovs-vswitchd are modifying tc. If you think your configuration is generally useful, you could propose changes to OVS to support what you're suggesting. --Justin From zjtang at biigroup.cn Tue Aug 22 01:23:32 2017 From: zjtang at biigroup.cn (=?utf-8?B?5ZSQ5b+X5Yab?=) Date: Tue, 22 Aug 2017 09:23:32 +0800 Subject: [ovs-discuss] Problem when installing OVS with DPDK In-Reply-To: <20170821181444.GJ6175@ovn.org> References: <599AB175.5080305@biigroup.cn> <20170821181444.GJ6175@ovn.org> Message-ID: Thank you, Ben, I have successfully installed OVS 2.7.2 with DPDK 17.02 ------------------ Original ------------------ From: "Ben Pfaff"; Date: Tue, Aug 22, 2017 02:14 AM To: "???"; Cc: "bugs"; Subject: Re: [ovs-discuss] Problem when installing OVS with DPDK On Mon, Aug 21, 2017 at 06:09:57PM +0800, ??? wrote: > But I also get problems. I am using OVS-2.72 and DPDK-17.05.1 OVS 2.7.2 uses DPDK 16.11. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sara.gittlin at gmail.com Tue Aug 22 07:12:46 2017 From: sara.gittlin at gmail.com (Sara Gittlin) Date: Tue, 22 Aug 2017 10:12:46 +0300 Subject: [ovs-discuss] Hashing to megaflow entry In-Reply-To: References: Message-ID: Thank you Justin, i understand from the article, that generating megaflows and installing in the kernel cache is already implemented in userspace - ovs. Before reading this article, i thought that megaflows were implemented only for L2 normal mode. Sara On Tue, Aug 22, 2017 at 1:09 AM, Justin Pettit wrote: > >> On Aug 21, 2017, at 8:19 AM, Sara Gittlin wrote: >> >> One more - I did not see in the article that if a match is found in >> megaflow cache - then a microflow is generated to be installed in the >> microflow cache to improve performance for subsequnce packets > > An exact-match cache (microflow cache) is an implementation of the datapath. The userspace and out-of-tree OVS Linux kernel module that ships as part of OVS contain an exact-match cache that's managed by the datapath. The upstream OVS kernel module that ships with the Linux kernel was rejected by the Linux upstream community, so it does not contain one. > > --Justin > > From billy.o.mahony at intel.com Tue Aug 22 08:44:05 2017 From: billy.o.mahony at intel.com (O Mahony, Billy) Date: Tue, 22 Aug 2017 08:44:05 +0000 Subject: [ovs-discuss] Error attaching device to DPDK In-Reply-To: <03135AEA779D444E90975C2703F148DC2F8B1FDA@IRSMSX107.ger.corp.intel.com> References: <007D0C6B-512E-4E1A-9AD9-B16E73E56253@vmware.com> <7EE4206A5F421D4FBA0A4623185DE2BD0DECC50A@IRSMSX104.ger.corp.intel.com> <7EE4206A5F421D4FBA0A4623185DE2BD0DECCA64@IRSMSX104.ger.corp.intel.com> <7EE4206A5F421D4FBA0A4623185DE2BD0DECCAE9@IRSMSX104.ger.corp.intel.com> <9E41E690-F80A-4D24-9741-C0A4DF9D6DD6@vmware.com> <03135AEA779D444E90975C2703F148DC2F8ADF46@IRSMSX107.ger.corp.intel.com> <44B8B429-D2E4-4F3B-B5DE-3D54D1062652@vmware.com> <03135AEA779D444E90975C2703F148DC2F8B1542@IRSMSX107.ger.corp.intel.com> <03135AEA779D444E90975C2703F148DC2F8B1FDA@IRSMSX107.ger.corp.intel.com> Message-ID: <03135AEA779D444E90975C2703F148DC58BFF4D5@IRSMSX107.ger.corp.intel.com> Hi All, The issue below is getting to the top of our to-fix list. I?m proposing internally that we set the default behavior. ? If dpdk-sock-mem is not set then for each node with a pmd reserve 512M of hugepages (or 1G if only 1G pages available) o This means if pmd-cpu-mask is not set then hugepages are reservered on all NUMAs. Also: ? Document this behavior. ? Modify the warning text given if a NUMA node does not have available huge pages to adivse ?you need to allocate hugepage memory on each numa node where dpdk ports are bound and or those ports will not work with dpdk? I think that covers everything discussed. Let me know if not. Regards, Billy. From: ovs-discuss-bounces at openvswitch.org [mailto:ovs-discuss-bounces at openvswitch.org] On Behalf Of O Mahony, Billy Sent: Thursday, April 6, 2017 5:57 PM To: Shivaram Mysore Cc: Brad Cowie ; ovs-discuss at openvswitch.org Subject: Re: [ovs-discuss] Error attaching device to DPDK Hi Shivram, Thanks. Billy. From: Shivaram Mysore [mailto:shivaram.mysore at gmail.com] Sent: Thursday, April 6, 2017 4:34 PM To: O Mahony, Billy > Cc: ovs-discuss at openvswitch.org; Darrell Ball >; Brad Cowie > Subject: Re: [ovs-discuss] Error attaching device to DPDK Hi Billy, Apologies for the delay. I was off-site for the last few days. dpdk-devbind --status does not yield version info at all :-( [Maybe this is a bug too - to include dpdk version info] I installed DPDK and OVS packages on Ubuntu 17.04 Beta2 (kernel 4.10.0-14-generic) from http://packages.wand.net.nz/ # dpkg -s openvswitch-switch-dpdk Package: openvswitch-switch-dpdk Status: install ok installed Priority: extra Section: net Installed-Size: 2355 Maintainer: Ubuntu Developers > Architecture: amd64 Source: openvswitch Version: 2.7.0-3 Depends: dpdk, openvswitch-switch (= 2.7.0-3), libc6 (>= 2.14), libcap-ng0, librte-eal3 (>= 16.04), librte-ethdev5 (>= 16.07~rc1), librte-mbuf2 (>= 16.04), librte-mempool2 (>= 16.07~rc1), librte-meter1 (>= 16.04), librte-pdump1 (>= 16.07~rc1), librte-pmd-ring2 (>= 16.04), librte-ring1 (>= 16.04), librte-vhost3 (>= 16.07~rc1), libssl1.0.0 (>= 1.0.0) Enhances: openvswitch-switch Description: DPDK enabled Open vSwitch switch implementation Open vSwitch is a production quality, multilayer, software-based, Ethernet virtual switch. It is designed to enable massive network automation through programmatic extension, while still supporting standard management interfaces and protocols (e.g. NetFlow, IPFIX, sFlow, SPAN, RSPAN, CLI, LACP, 802.1ag). In addition, it is designed to support distribution across multiple physical servers similar to VMware's vNetwork distributed vswitch or Cisco's Nexus 1000V. . openvswitch-switch provides the userspace components and utilities for the Open vSwitch kernel-based switch. . DPDK is a set of libraries for fast packet processing. Applications run in user-space and communicate directly with dedicated network interfaces. . This package provides a DPDK enabled implementation of the ovs-vswitchd binary. Homepage: http://openvswitch.org/ Original-Maintainer: Open vSwitch developers > # cpuid -1 .... .... Logical CPU cores (0x80000008/ecx): number of CPU cores - 1 = 0x0 (0) ApicIdCoreIdSize = 0x0 (0) (multi-processing synth): multi-core (c=18), hyper-threaded (t=2) (multi-processing method): Intel leaf 0xb (APIC widths synth): CORE_width=6 SMT_width=1 (APIC synth): PKG_ID=0 CORE_ID=41 SMT_ID=0 (synth) = Intel Core i7-5000 Extreme Edition (Haswell R2) / Xeon E5-x600 v3 (Haswell-EP C1/M1/R2), 22nm On Tue, Apr 4, 2017 at 9:14 AM, O Mahony, Billy > wrote: Hi Shivram, Apologies if I missed this info in the email thread. For the bug report: * What version of DPDK were you using? * Also what is your hardware - NICs (out from dpdk_devbind.py --status) and processor architecture (last few lines from cpuid -1 ) Thanks, Billy. > -----Original Message----- > From: O Mahony, Billy > Sent: Tuesday, April 4, 2017 12:00 PM > To: 'Darrell Ball' >; Brad Cowie >; > Shivaram Mysore > > Cc: ovs-discuss at openvswitch.org > Subject: RE: [ovs-discuss] Error attaching device to DPDK > > Hi Darrell, > > /Billy > > > -----Original Message----- > > From: Darrell Ball [mailto:dball at vmware.com] > > Sent: Thursday, March 30, 2017 8:51 PM > > To: O Mahony, Billy >; Brad Cowie > > >; Shivaram Mysore > > > Cc: ovs-discuss at openvswitch.org > > Subject: Re: [ovs-discuss] Error attaching device to DPDK > > > > > > > > On 3/29/17, 7:40 AM, "O Mahony, Billy" > > wrote: > > > > Hi All, > > > > > > > > Just to add something to this conversation that has not been > > explicitly mentioned below. > > > > > > > > Brad outlines how to set other_config:dpdk-socket-mem to reserve > > hugepages from both NUMA nodes in order to be sure to avoid pci > > topology issues. > > > > > > > > Strictly this doesn?t have to be done on both nodes ? just on the > > correct node :) ? but sometimes it?s easier to just cover all the bases. > > > > > > > > In addition you will need to ensure that: > > > > * That linux has hugepages available on both (or the right) nodes. > > > > * There is a pmd thread created on each node by setting > > other_config:pmd-cpu-mask correctly ? or again at least on the right node. > > > > > > > > These config items are described in > > > > * ./Documentation/intro/install/dpdk.rst > > > > * ./Documentation/howto/dpdk.rst > > > > > > > > Currently if there is not a pmd thread on the NUMA node belonging > > to the PCI device the device will not be polled (a warning message is > > issued to this effect). > > > > > > [Darrell] > > From Linux POV, the ?default? memory policy is to allocate the > > hugepage pool across numa nodes, if possible; this assumes an > > allocation was done, which we have no reports here otherwise. > > iirc based on the logs in this case, which I cannot view anymore, > > there was no pmd mask configuration specified. > > The advertised behavior should be, in this case, that a pmd thread is > > allocated on each numa node with at least one local dpdk interface bound. > > iirc, the dpdk socket memory was left at default, which only > > pre-allocated from the hugepage pool on node 0 So, does it make sense > > to also try to pre- allocate hugepages on a numa node, where a PMD > thread is allocated ? > > Pls correct me in any respects. > > > [[BO'M]] > > What you're looking for here is something that will work (even if not > optimally). And leave the optimization of exact configurations of > pmds/hugepage-allocations and so on until later? > > So even if pmd-cpu-mask and dpdk-socket-mem other_config items are > omitted OVS will 'do the right thing' ? ie. place a pmd on each numa node and > take some hugepages on each NUMA node. > > It's hard to argue with that and I can put that on our internal backlog of tasks. > > How about these rules? > * If pmd-cpu-mask is not set OVS creates one pmd thread for each NUMA > node. (current case) > * if dpdk-socket-mem is not set then for each NUMA node dpdk will reserve: > ** one quarter of the available hugepage memory > ** 512MB of 2MB hugepages > If hugepage granularity requires more memory may be reserved. > > > > > > > > > > > > > > There is currently a patch under consideration so that if a > > NUMA-local pmd is not available for a device then device will be > > assigned to some other pmd thread. While this is not as efficient due > > to the need for the data to travel between NUMA nodes it is less > frustrating to configure. > > > > > > > > https://urldefense.proofpoint.com/v2/url?u=https- > > 3A__mail.openvswitch.org_pipermail_ovs-2Ddev_2017- > > > 2DFebruary_329175.html&d=DwIGaQ&c=uilaK90D4TOVoH58JNXRgQ&r=BVh > > FA09CGX7JQ5Ih- > > > uZnsw&m=IKHiqOFj5oogxEfx6OMgK9IHxp2aktbssMBTZUoA2P0&s=QmpnH > > wqCC8ZBxRGZgfCZuF-9SielPs89Yd-k7crooC8&e= > > > > > > > > If you install the hwloc package you can use ?hwloc-calc > > pci=0000:01:02.0 -- intersect Socket? to show the NUMA node that is local > to a pci device. > > However I have seen some systems which report that pci device is local > > to both nodes. The lstopo command can also be used for this. > > > > > > > > Hope some of that helps, > > > > > > > > Billy. > > > > > > > > > > > > From: ovs-discuss-bounces at openvswitch.org [mailto:ovs-discuss- > > bounces at openvswitch.org] On Behalf Of Darrell Ball > > > > Sent: Wednesday, March 29, 2017 2:36 AM > > > > To: Brad Cowie >; Shivaram Mysore > > > > > > > Cc: ovs-discuss at openvswitch.org > > > > Subject: Re: [ovs-discuss] Error attaching device to DPDK > > > > > > > > > > > > > > > > From: > on behalf of Brad > > Cowie > > > > > Date: Tuesday, March 28, 2017 at 5:35 PM > > > > To: Shivaram Mysore > > > > > Cc: "ovs-discuss at openvswitch.org" > > > > > Subject: Re: [ovs-discuss] Error attaching device to DPDK > > > > > > > > Hi folks, > > > > I have been helping Shivaram off-list with this problem and just > > wanted to update this thread with the solution. > > > > Basically the issue was with how hugepages were being preallocated > > by OVS for use with DPDK. I believe by default OVS sets > > other_config:dpdk- socket-mem to "1024,0". Which will give one 1GB > > hugepage to CPU0 and none to CPU1. > > > > The ports Shivaram was trying to assign to DPDK were connected > > physically via a PCI-E bus to CPU1 and since there are no hugepages > > preallocated there for DPDK then we can't add it. > > > > The fix is simple, to assign a hugepage to CPU1: > > > > > > > > $ sudo ovs-vsctl --no-wait set Open_vSwitch . > > other_config:dpdk-socket- mem="1024,1024" > > > > In OVS 2.7.0 unfortunately due to an issue (that is now fixed by > > commit > > ef6cca6fdc67f3cee21c6bb1c13c4ca7f8241314) you get a segfault rather > > than an error message telling you the problem. > > > > In OVS 2.7.90 however the issue becomes quite clear as there is a > > nice log message like such: > > > > > > > > 2017-03-29T00:19:57Z|00067|netdev_dpdk|ERR|Insufficient memory to > > create memory pool for netdev dpdk-p0, with MTU 1500 on socket 1 > > > > There is documentation regarding these fields, but for case, the > > documentation could simply state something like > > > > ?you need to allocate hugepage memory on each numa node where > dpdk > > ports are bound and or those ports > > > > will not work with dpdk? > > > > The error log could also be a little more succinct like ?no memory > > pool allocated for netdev dpdk-p0,.., usage on socket 1? > > > > > > > > Possibly, going even further, when a PMD thread gets > > auto-allocated to run on a given numa node, > > > > memory allocation is defaulted there as well. If it cannot be > > allocated, an error log is generated. > > > > > > > > Unfortunately to those unfamiliar with DPDK and NUMA architectures > > this won't be very obvious. Potentially we could add some additional > > help to the DPDK documentation pages for OVS that explains the > > other_config options you may need to reconfigure on multi-CPU NUMA > machines? > > > > Brad > > > > > > > > On 29 March 2017 at 10:02, Shivaram Mysore > > > wrote: > > > > Ok thanks. Will remember the same. Right now, I will not specify > > anything as I have to get this to work first! > > > > > > > > On Tue, Mar 28, 2017 at 2:00 PM, Bodireddy, Bhanuprakash > > > wrote: > > > > >Question: > > > > > > > > > >I don't have any specific cpu cores associated with DPDK. Will > > this make any > > > > >difference? I also did not see this requirement as a MUST have > > in the > > > > >documentation. > > > > > > > > I assume your question is on PMD threads. If you don?t specify any > > thing explicitly > > > > PMD pmd thread shall be created and pinned to core 0. You can > > explicitly select the no. of pmd threads > > > > and the cores by explicitly setting the affinity mask using > > 'other_config:pmd-cpu-mask'. > > > > > > > > Based on the affinity mask, the PMD threads shall be spawned and > > the rx queues will be uniformly > > > > distributed among the PMD threads. > > > > > > > > Refer https://urldefense.proofpoint.com/v2/url?u=http- > > > 3A__docs.openvswitch.org_en_latest_howto_dpdk_&d=DwIGaQ&c=uilaK9 > > 0D4TOVoH58JNXRgQ&r=BVhFA09CGX7JQ5Ih- > > > uZnsw&m=IKHiqOFj5oogxEfx6OMgK9IHxp2aktbssMBTZUoA2P0&s=JNQjCdB > > cYJG8H1n4bT6k_zFhtkk6wcRE27AhEuQoqjg&e= . > > > > > > > > Also note that 'dpdk-lcore-mask' should be used to set the dpdk > > lcore threads and vswitchd. > > > > > > > > - Bhanuprakash. > > > > > > > > > > > > > ># cat /proc/cmdline > > > > >BOOT_IMAGE=/boot/vmlinuz-4.10.0-14-generic > > root=/dev/mapper/intelsdn- > > > > >-vg-root ro quiet intel_iommu=on iommu=pt default_hugepagesz=1G > > > > >hugepagesz=1G hugepages=4 > > > > > > > > > > > > > > >Thanks > > > > > > > > > >/Shivaram > > > > > > > > > >On Tue, Mar 28, 2017 at 1:32 PM, Shivaram Mysore > > > > >> wrote: > > > > >I was advised on this mailing list that VFIO drivers are better > > than IGB_UIO > > + > > > > >more forgiving [1]. Hence switched to the same. > > > > > > > > > >[1] https://urldefense.proofpoint.com/v2/url?u=http-3A__dpdk- > > 2Dguide.gitlab.io_dpdk- > > > 2Dguide_setup_binding.html&d=DwIGaQ&c=uilaK90D4TOVoH58JNXRgQ&r= > > BVhFA09CGX7JQ5Ih- > > > uZnsw&m=IKHiqOFj5oogxEfx6OMgK9IHxp2aktbssMBTZUoA2P0&s=KgBSWU > > sNwqMWB_Pm2CHmGAVAO5enRJxRlvbS9MR-7Ww&e= > > > > > > > > > >/Shivaram > > > > > > > > > >On Tue, Mar 28, 2017 at 1:12 PM, Bodireddy, Bhanuprakash > > > > >> wrote: > > > > > > > > > >>any hints for me based on the info provided? > > > > > > > > > >Your BIOS options and bootcmd line options are appropriate and no > > issues > > > > >there. I wanted to check if you tried igb_uio drivers > > > > >but saw your post here > > https://urldefense.proofpoint.com/v2/url?u=https- > > 3A__mail.openvswitch.org_pipermail_ovs- > > 2D&d=DwIGaQ&c=uilaK90D4TOVoH58JNXRgQ&r=BVhFA09CGX7JQ5Ih- > > > uZnsw&m=IKHiqOFj5oogxEfx6OMgK9IHxp2aktbssMBTZUoA2P0&s=qoh0Qu6 > > HkVOjRIO_oNqdzBGTGjRdo5tppjkG2R3KpEw&e= > > > > >discuss/2017-March/043993.html, reporting a crash with UIO drivers. > > > > > > > > > >Is that the reason why you moved to VFIO? I cross checked your > > logs but > > > > >found nothing suspicious there. > > > > > > > > > >-Bhanuprakash. > > > > > > > > > >> > > > > >>Thanks > > > > >> > > > > >>On Tue, Mar 28, 2017 at 8:41 AM, Shivaram Mysore > > > > >>> wrote: > > > > >>Hi, > > > > >> > > > > >># dmesg | grep -e DMAR -e IOMMU > > > > >>[ 0.000000] ACPI: DMAR 0x00000000798AF340 000158 (v01 SUPERM > > SMCI-- > > > > >>MB 00000001 INTL 20091013) > > > > >>[ 0.000000] DMAR: IOMMU enabled > > > > >>[ 0.109987] DMAR: Host address width 46 > > > > >>[ 0.109988] DMAR: DRHD base: 0x000000fbffc000 flags: 0x0 > > > > >>[ 0.109997] DMAR: dmar0: reg_base_addr fbffc000 ver 1:0 cap > > > > >>d2078c106f0466 ecap f020de > > > > >>[ 0.109998] DMAR: DRHD base: 0x000000c7ffc000 flags: 0x1 > > > > >>[ 0.110002] DMAR: dmar1: reg_base_addr c7ffc000 ver 1:0 cap > > > > >>d2078c106f0466 ecap f020de > > > > >>[ 0.110003] DMAR: RMRR base: 0x0000007ba75000 end: > > 0x0000007ba84fff > > > > >>[ 0.110004] DMAR: ATSR flags: 0x0 > > > > >>[ 0.110005] DMAR: RHSA base: 0x000000c7ffc000 proximity domain: > 0x0 > > > > >>[ 0.110006] DMAR: RHSA base: 0x000000fbffc000 proximity domain: > 0x1 > > > > >>[ 0.110008] DMAR-IR: IOAPIC id 3 under DRHD base 0xfbffc000 > IOMMU > > 0 > > > > >>[ 0.110008] DMAR-IR: IOAPIC id 1 under DRHD base 0xc7ffc000 > IOMMU > > 1 > > > > >>[ 0.110009] DMAR-IR: IOAPIC id 2 under DRHD base 0xc7ffc000 > IOMMU > > 1 > > > > >>[ 0.110010] DMAR-IR: HPET id 0 under DRHD base 0xc7ffc000 > > > > >>[ 0.110011] DMAR-IR: x2apic is disabled because BIOS sets x2apic opt > > out > > > > >bit. > > > > >>[ 0.110012] DMAR-IR: Use 'intremap=no_x2apic_optout' to override > > the > > > > >>BIOS setting. > > > > >>[ 0.110902] DMAR-IR: Enabled IRQ remapping in xapic mode > > > > >>[ 1.687595] DMAR: dmar0: Using Queued invalidation > > > > >>[ 1.687608] DMAR: dmar1: Using Queued invalidation > > > > >>[ 1.688473] DMAR: Hardware identity mapping for device 0000:ff:08.0 > > > > >>[ 1.688475] DMAR: Hardware identity mapping for device 0000:ff:08.2 > > > > >>[ 1.688477] DMAR: Hardware identity mapping for device 0000:ff:08.3 > > > > >>[ 1.688478] DMAR: Hardware identity mapping for device 0000:ff:09.0 > > > > >>[ 1.688480] DMAR: Hardware identity mapping for device 0000:ff:09.2 > > > > >>[ 1.688482] DMAR: Hardware identity mapping for device 0000:ff:09.3 > > > > >>[ 1.688483] DMAR: Hardware identity mapping for device 0000:ff:0b.0 > > > > >>[ 1.688485] DMAR: Hardware identity mapping for device 0000:ff:0b.1 > > > > >>[ 1.688487] DMAR: Hardware identity mapping for device 0000:ff:0b.2 > > > > >>[ 1.688488] DMAR: Hardware identity mapping for device 0000:ff:0c.0 > > > > >>[ 1.688490] DMAR: Hardware identity mapping for device 0000:ff:0c.1 > > > > >>[ 1.688491] DMAR: Hardware identity mapping for device 0000:ff:0c.2 > > > > >>[ 1.688493] DMAR: Hardware identity mapping for device 0000:ff:0c.3 > > > > >>[ 1.688494] DMAR: Hardware identity mapping for device 0000:ff:0c.4 > > > > >>[ 1.688496] DMAR: Hardware identity mapping for device 0000:ff:0c.5 > > > > >>[ 1.688498] DMAR: Hardware identity mapping for device 0000:ff:0c.6 > > > > >>[ 1.688499] DMAR: Hardware identity mapping for device 0000:ff:0c.7 > > > > >>[ 1.688500] DMAR: Hardware identity mapping for device 0000:ff:0d.0 > > > > >>[ 1.688502] DMAR: Hardware identity mapping for device 0000:ff:0d.1 > > > > >>[ 1.688504] DMAR: Hardware identity mapping for device 0000:ff:0d.2 > > > > >>[ 1.688505] DMAR: Hardware identity mapping for device 0000:ff:0d.3 > > > > >>[ 1.688506] DMAR: Hardware identity mapping for device 0000:ff:0d.4 > > > > >>[ 1.688508] DMAR: Hardware identity mapping for device 0000:ff:0d.5 > > > > >>[ 1.688509] DMAR: Hardware identity mapping for device 0000:ff:0d.6 > > > > >>[ 1.688510] DMAR: Hardware identity mapping for device 0000:ff:0d.7 > > > > >>[ 1.688511] DMAR: Hardware identity mapping for device 0000:ff:0e.0 > > > > >>[ 1.688513] DMAR: Hardware identity mapping for device 0000:ff:0e.1 > > > > >>[ 1.688514] DMAR: Hardware identity mapping for device 0000:ff:0f.0 > > > > >>[ 1.688516] DMAR: Hardware identity mapping for device 0000:ff:0f.1 > > > > >>[ 1.688517] DMAR: Hardware identity mapping for device 0000:ff:0f.2 > > > > >>[ 1.688518] DMAR: Hardware identity mapping for device 0000:ff:0f.3 > > > > >>[ 1.688520] DMAR: Hardware identity mapping for device 0000:ff:0f.4 > > > > >>[ 1.688521] DMAR: Hardware identity mapping for device 0000:ff:0f.5 > > > > >>[ 1.688523] DMAR: Hardware identity mapping for device 0000:ff:0f.6 > > > > >>[ 1.688524] DMAR: Hardware identity mapping for device 0000:ff:10.0 > > > > >>[ 1.688526] DMAR: Hardware identity mapping for device 0000:ff:10.1 > > > > >>[ 1.688527] DMAR: Hardware identity mapping for device 0000:ff:10.5 > > > > >>[ 1.688529] DMAR: Hardware identity mapping for device 0000:ff:10.6 > > > > >>[ 1.688530] DMAR: Hardware identity mapping for device 0000:ff:10.7 > > > > >>[ 1.688532] DMAR: Hardware identity mapping for device 0000:ff:12.0 > > > > >>[ 1.688533] DMAR: Hardware identity mapping for device 0000:ff:12.1 > > > > >>[ 1.688534] DMAR: Hardware identity mapping for device 0000:ff:12.4 > > > > >>[ 1.688536] DMAR: Hardware identity mapping for device 0000:ff:12.5 > > > > >>[ 1.688537] DMAR: Hardware identity mapping for device 0000:ff:13.0 > > > > >>[ 1.688539] DMAR: Hardware identity mapping for device 0000:ff:13.1 > > > > >>[ 1.688541] DMAR: Hardware identity mapping for device 0000:ff:13.2 > > > > >>[ 1.688542] DMAR: Hardware identity mapping for device 0000:ff:13.3 > > > > >>[ 1.688543] DMAR: Hardware identity mapping for device 0000:ff:13.6 > > > > >>[ 1.688545] DMAR: Hardware identity mapping for device 0000:ff:13.7 > > > > >>[ 1.688546] DMAR: Hardware identity mapping for device 0000:ff:14.0 > > > > >>[ 1.688547] DMAR: Hardware identity mapping for device 0000:ff:14.1 > > > > >>[ 1.688549] DMAR: Hardware identity mapping for device 0000:ff:14.2 > > > > >>[ 1.688550] DMAR: Hardware identity mapping for device 0000:ff:14.3 > > > > >>[ 1.688552] DMAR: Hardware identity mapping for device 0000:ff:14.4 > > > > >>[ 1.688553] DMAR: Hardware identity mapping for device 0000:ff:14.5 > > > > >>[ 1.688559] DMAR: Hardware identity mapping for device 0000:ff:14.6 > > > > >>[ 1.688561] DMAR: Hardware identity mapping for device 0000:ff:14.7 > > > > >>[ 1.688562] DMAR: Hardware identity mapping for device 0000:ff:16.0 > > > > >>[ 1.688564] DMAR: Hardware identity mapping for device 0000:ff:16.1 > > > > >>[ 1.688565] DMAR: Hardware identity mapping for device 0000:ff:16.2 > > > > >>[ 1.688566] DMAR: Hardware identity mapping for device 0000:ff:16.3 > > > > >>[ 1.688568] DMAR: Hardware identity mapping for device 0000:ff:16.6 > > > > >>[ 1.688569] DMAR: Hardware identity mapping for device 0000:ff:16.7 > > > > >>[ 1.688571] DMAR: Hardware identity mapping for device 0000:ff:17.0 > > > > >>[ 1.688573] DMAR: Hardware identity mapping for device 0000:ff:17.1 > > > > >>[ 1.688574] DMAR: Hardware identity mapping for device 0000:ff:17.2 > > > > >>[ 1.688576] DMAR: Hardware identity mapping for device 0000:ff:17.3 > > > > >>[ 1.688577] DMAR: Hardware identity mapping for device 0000:ff:17.4 > > > > >>[ 1.688579] DMAR: Hardware identity mapping for device 0000:ff:17.5 > > > > >>[ 1.688581] DMAR: Hardware identity mapping for device 0000:ff:17.6 > > > > >>[ 1.688582] DMAR: Hardware identity mapping for device 0000:ff:17.7 > > > > >>[ 1.688584] DMAR: Hardware identity mapping for device 0000:ff:1e.0 > > > > >>[ 1.688586] DMAR: Hardware identity mapping for device 0000:ff:1e.1 > > > > >>[ 1.688588] DMAR: Hardware identity mapping for device 0000:ff:1e.2 > > > > >>[ 1.688590] DMAR: Hardware identity mapping for device 0000:ff:1e.3 > > > > >>[ 1.688592] DMAR: Hardware identity mapping for device 0000:ff:1e.4 > > > > >>[ 1.688594] DMAR: Hardware identity mapping for device 0000:ff:1f.0 > > > > >>[ 1.688596] DMAR: Hardware identity mapping for device 0000:ff:1f.2 > > > > >>[ 1.688610] DMAR: Hardware identity mapping for device 0000:7f:08.0 > > > > >>[ 1.688612] DMAR: Hardware identity mapping for device 0000:7f:08.2 > > > > >>[ 1.688614] DMAR: Hardware identity mapping for device 0000:7f:08.3 > > > > >>[ 1.688616] DMAR: Hardware identity mapping for device 0000:7f:09.0 > > > > >>[ 1.688617] DMAR: Hardware identity mapping for device 0000:7f:09.2 > > > > >>[ 1.688619] DMAR: Hardware identity mapping for device 0000:7f:09.3 > > > > >>[ 1.688621] DMAR: Hardware identity mapping for device 0000:7f:0b.0 > > > > >>[ 1.688623] DMAR: Hardware identity mapping for device 0000:7f:0b.1 > > > > >>[ 1.688625] DMAR: Hardware identity mapping for device 0000:7f:0b.2 > > > > >>[ 1.688627] DMAR: Hardware identity mapping for device 0000:7f:0c.0 > > > > >>[ 1.688629] DMAR: Hardware identity mapping for device 0000:7f:0c.1 > > > > >>[ 1.688631] DMAR: Hardware identity mapping for device 0000:7f:0c.2 > > > > >>[ 1.688632] DMAR: Hardware identity mapping for device 0000:7f:0c.3 > > > > >>[ 1.688634] DMAR: Hardware identity mapping for device 0000:7f:0c.4 > > > > >>[ 1.688636] DMAR: Hardware identity mapping for device 0000:7f:0c.5 > > > > >>[ 1.688637] DMAR: Hardware identity mapping for device 0000:7f:0c.6 > > > > >>[ 1.688639] DMAR: Hardware identity mapping for device 0000:7f:0c.7 > > > > >>[ 1.688641] DMAR: Hardware identity mapping for device 0000:7f:0d.0 > > > > >>[ 1.688642] DMAR: Hardware identity mapping for device 0000:7f:0d.1 > > > > >>[ 1.688644] DMAR: Hardware identity mapping for device 0000:7f:0d.2 > > > > >>[ 1.688646] DMAR: Hardware identity mapping for device 0000:7f:0d.3 > > > > >>[ 1.688647] DMAR: Hardware identity mapping for device 0000:7f:0d.4 > > > > >>[ 1.688649] DMAR: Hardware identity mapping for device 0000:7f:0d.5 > > > > >>[ 1.688650] DMAR: Hardware identity mapping for device 0000:7f:0d.6 > > > > >>[ 1.688652] DMAR: Hardware identity mapping for device 0000:7f:0d.7 > > > > >>[ 1.688653] DMAR: Hardware identity mapping for device 0000:7f:0e.0 > > > > >>[ 1.688655] DMAR: Hardware identity mapping for device 0000:7f:0e.1 > > > > >>[ 1.688657] DMAR: Hardware identity mapping for device 0000:7f:0f.0 > > > > >>[ 1.688658] DMAR: Hardware identity mapping for device 0000:7f:0f.1 > > > > >>[ 1.688660] DMAR: Hardware identity mapping for device 0000:7f:0f.2 > > > > >>[ 1.688661] DMAR: Hardware identity mapping for device 0000:7f:0f.3 > > > > >>[ 1.688663] DMAR: Hardware identity mapping for device 0000:7f:0f.4 > > > > >>[ 1.688664] DMAR: Hardware identity mapping for device 0000:7f:0f.5 > > > > >>[ 1.688666] DMAR: Hardware identity mapping for device 0000:7f:0f.6 > > > > >>[ 1.688668] DMAR: Hardware identity mapping for device 0000:7f:10.0 > > > > >>[ 1.688669] DMAR: Hardware identity mapping for device 0000:7f:10.1 > > > > >>[ 1.688671] DMAR: Hardware identity mapping for device 0000:7f:10.5 > > > > >>[ 1.688673] DMAR: Hardware identity mapping for device 0000:7f:10.6 > > > > >>[ 1.688674] DMAR: Hardware identity mapping for device 0000:7f:10.7 > > > > >>[ 1.688676] DMAR: Hardware identity mapping for device 0000:7f:12.0 > > > > >>[ 1.688678] DMAR: Hardware identity mapping for device 0000:7f:12.1 > > > > >>[ 1.688684] DMAR: Hardware identity mapping for device 0000:7f:12.4 > > > > >>[ 1.688686] DMAR: Hardware identity mapping for device 0000:7f:12.5 > > > > >>[ 1.688688] DMAR: Hardware identity mapping for device 0000:7f:13.0 > > > > >>[ 1.688689] DMAR: Hardware identity mapping for device 0000:7f:13.1 > > > > >>[ 1.688691] DMAR: Hardware identity mapping for device 0000:7f:13.2 > > > > >>[ 1.688692] DMAR: Hardware identity mapping for device 0000:7f:13.3 > > > > >>[ 1.688694] DMAR: Hardware identity mapping for device 0000:7f:13.6 > > > > >>[ 1.688696] DMAR: Hardware identity mapping for device 0000:7f:13.7 > > > > >>[ 1.688697] DMAR: Hardware identity mapping for device 0000:7f:14.0 > > > > >>[ 1.688699] DMAR: Hardware identity mapping for device 0000:7f:14.1 > > > > >>[ 1.688701] DMAR: Hardware identity mapping for device 0000:7f:14.2 > > > > >>[ 1.688703] DMAR: Hardware identity mapping for device 0000:7f:14.3 > > > > >>[ 1.688704] DMAR: Hardware identity mapping for device 0000:7f:14.4 > > > > >>[ 1.688706] DMAR: Hardware identity mapping for device 0000:7f:14.5 > > > > >>[ 1.688708] DMAR: Hardware identity mapping for device 0000:7f:14.6 > > > > >>[ 1.688710] DMAR: Hardware identity mapping for device 0000:7f:14.7 > > > > >>[ 1.688712] DMAR: Hardware identity mapping for device 0000:7f:16.0 > > > > >>[ 1.688714] DMAR: Hardware identity mapping for device 0000:7f:16.1 > > > > >>[ 1.688716] DMAR: Hardware identity mapping for device 0000:7f:16.2 > > > > >>[ 1.688718] DMAR: Hardware identity mapping for device 0000:7f:16.3 > > > > >>[ 1.688720] DMAR: Hardware identity mapping for device 0000:7f:16.6 > > > > >>[ 1.688722] DMAR: Hardware identity mapping for device 0000:7f:16.7 > > > > >>[ 1.688724] DMAR: Hardware identity mapping for device 0000:7f:17.0 > > > > >>[ 1.688726] DMAR: Hardware identity mapping for device 0000:7f:17.1 > > > > >>[ 1.688729] DMAR: Hardware identity mapping for device 0000:7f:17.2 > > > > >>[ 1.688731] DMAR: Hardware identity mapping for device 0000:7f:17.3 > > > > >>[ 1.688733] DMAR: Hardware identity mapping for device 0000:7f:17.4 > > > > >>[ 1.688735] DMAR: Hardware identity mapping for device 0000:7f:17.5 > > > > >>[ 1.688737] DMAR: Hardware identity mapping for device 0000:7f:17.6 > > > > >>[ 1.688739] DMAR: Hardware identity mapping for device 0000:7f:17.7 > > > > >>[ 1.688741] DMAR: Hardware identity mapping for device 0000:7f:1e.0 > > > > >>[ 1.688742] DMAR: Hardware identity mapping for device 0000:7f:1e.1 > > > > >>[ 1.688744] DMAR: Hardware identity mapping for device 0000:7f:1e.2 > > > > >>[ 1.688746] DMAR: Hardware identity mapping for device 0000:7f:1e.3 > > > > >>[ 1.688748] DMAR: Hardware identity mapping for device 0000:7f:1e.4 > > > > >>[ 1.688750] DMAR: Hardware identity mapping for device 0000:7f:1f.0 > > > > >>[ 1.688752] DMAR: Hardware identity mapping for device 0000:7f:1f.2 > > > > >>[ 1.688769] DMAR: Hardware identity mapping for device > 0000:00:00.0 > > > > >>[ 1.688774] DMAR: Hardware identity mapping for device > 0000:00:01.0 > > > > >>[ 1.688778] DMAR: Hardware identity mapping for device > 0000:00:01.1 > > > > >>[ 1.688783] DMAR: Hardware identity mapping for device > 0000:00:03.0 > > > > >>[ 1.688785] DMAR: Hardware identity mapping for device > 0000:00:04.0 > > > > >>[ 1.688787] DMAR: Hardware identity mapping for device > 0000:00:04.1 > > > > >>[ 1.688790] DMAR: Hardware identity mapping for device > 0000:00:04.2 > > > > >>[ 1.688792] DMAR: Hardware identity mapping for device > 0000:00:04.3 > > > > >>[ 1.688794] DMAR: Hardware identity mapping for device > 0000:00:04.4 > > > > >>[ 1.688797] DMAR: Hardware identity mapping for device > 0000:00:04.5 > > > > >>[ 1.688799] DMAR: Hardware identity mapping for device > 0000:00:04.6 > > > > >>[ 1.688801] DMAR: Hardware identity mapping for device > 0000:00:04.7 > > > > >>[ 1.688803] DMAR: Hardware identity mapping for device > 0000:00:05.0 > > > > >>[ 1.688807] DMAR: Hardware identity mapping for device > 0000:00:05.1 > > > > >>[ 1.688809] DMAR: Hardware identity mapping for device > 0000:00:05.2 > > > > >>[ 1.688811] DMAR: Hardware identity mapping for device > 0000:00:05.4 > > > > >>[ 1.688814] DMAR: Hardware identity mapping for device > 0000:00:11.0 > > > > >>[ 1.688816] DMAR: Hardware identity mapping for device > 0000:00:11.4 > > > > >>[ 1.688818] DMAR: Hardware identity mapping for device > 0000:00:14.0 > > > > >>[ 1.688821] DMAR: Hardware identity mapping for device > 0000:00:16.0 > > > > >>[ 1.688823] DMAR: Hardware identity mapping for device > 0000:00:16.1 > > > > >>[ 1.688825] DMAR: Hardware identity mapping for device > 0000:00:1a.0 > > > > >>[ 1.688828] DMAR: Hardware identity mapping for device 0000:00:1c.0 > > > > >>[ 1.688831] DMAR: Hardware identity mapping for device 0000:00:1c.2 > > > > >>[ 1.688833] DMAR: Hardware identity mapping for device > 0000:00:1d.0 > > > > >>[ 1.688835] DMAR: Hardware identity mapping for device 0000:00:1f.0 > > > > >>[ 1.688837] DMAR: Hardware identity mapping for device 0000:00:1f.2 > > > > >>[ 1.688844] DMAR: Hardware identity mapping for device 0000:00:1f.3 > > > > >>[ 1.688846] DMAR: Hardware identity mapping for device 0000:00:1f.6 > > > > >>[ 1.688864] DMAR: Hardware identity mapping for device > 0000:01:00.0 > > > > >>[ 1.688870] DMAR: Hardware identity mapping for device > 0000:01:00.1 > > > > >>[ 1.688876] DMAR: Hardware identity mapping for device > 0000:01:00.2 > > > > >>[ 1.688883] DMAR: Hardware identity mapping for device > 0000:01:00.3 > > > > >>[ 1.688895] DMAR: Hardware identity mapping for device > 0000:80:01.0 > > > > >>[ 1.688899] DMAR: Hardware identity mapping for device > 0000:80:02.0 > > > > >>[ 1.688903] DMAR: Hardware identity mapping for device > 0000:80:03.0 > > > > >>[ 1.688906] DMAR: Hardware identity mapping for device > 0000:80:04.0 > > > > >>[ 1.688908] DMAR: Hardware identity mapping for device > 0000:80:04.1 > > > > >>[ 1.688911] DMAR: Hardware identity mapping for device > 0000:80:04.2 > > > > >>[ 1.688913] DMAR: Hardware identity mapping for device > 0000:80:04.3 > > > > >>[ 1.688915] DMAR: Hardware identity mapping for device > 0000:80:04.4 > > > > >>[ 1.688918] DMAR: Hardware identity mapping for device > 0000:80:04.5 > > > > >>[ 1.688920] DMAR: Hardware identity mapping for device > 0000:80:04.6 > > > > >>[ 1.688923] DMAR: Hardware identity mapping for device > 0000:80:04.7 > > > > >>[ 1.688936] DMAR: Hardware identity mapping for device > 0000:80:05.0 > > > > >>[ 1.688940] DMAR: Hardware identity mapping for device > 0000:80:05.1 > > > > >>[ 1.688943] DMAR: Hardware identity mapping for device > 0000:80:05.2 > > > > >>[ 1.688945] DMAR: Hardware identity mapping for device > 0000:80:05.4 > > > > >>[ 1.688956] DMAR: Hardware identity mapping for device > 0000:81:00.0 > > > > >>[ 1.688961] DMAR: Hardware identity mapping for device > 0000:81:00.1 > > > > >>[ 1.688974] DMAR: Hardware identity mapping for device > 0000:82:00.0 > > > > >>[ 1.688980] DMAR: Hardware identity mapping for device > 0000:82:00.1 > > > > >>[ 1.688986] DMAR: Hardware identity mapping for device > 0000:82:00.2 > > > > >>[ 1.688992] DMAR: Hardware identity mapping for device > 0000:82:00.3 > > > > >>[ 1.689006] DMAR: Hardware identity mapping for device > 0000:83:00.0 > > > > >>[ 1.689012] DMAR: Hardware identity mapping for device > 0000:83:00.1 > > > > >>[ 1.689018] DMAR: Hardware identity mapping for device > 0000:83:00.2 > > > > >>[ 1.689024] DMAR: Hardware identity mapping for device > 0000:83:00.3 > > > > >>[ 1.689025] DMAR: Setting RMRR: > > > > >>[ 1.689026] DMAR: Ignoring identity map for HW passthrough device > > > > >>0000:00:14.0 [0x7ba75000 - 0x7ba84fff] > > > > >>[ 1.689027] DMAR: Ignoring identity map for HW passthrough device > > > > >>0000:00:1a.0 [0x7ba75000 - 0x7ba84fff] > > > > >>[ 1.689028] DMAR: Ignoring identity map for HW passthrough device > > > > >>0000:00:1d.0 [0x7ba75000 - 0x7ba84fff] > > > > >>[ 1.689036] DMAR: Prepare 0-16MiB unity mapping for LPC > > > > >>[ 1.689036] DMAR: Ignoring identity map for HW passthrough device > > > > >>0000:00:1f.0 [0x0 - 0xffffff] > > > > >>[ 1.689040] DMAR: Intel(R) Virtualization Technology for Directed I/O > > > > >>[ 2.299766] DMAR: 32bit 0000:00:11.4 uses non-identity mapping > > > > >>[ 2.301941] DMAR: 32bit 0000:00:1a.0 uses non-identity mapping > > > > >>[ 2.302679] DMAR: Setting identity map for device 0000:00:1a.0 > > [0x7ba75000 > > > > >- > > > > >>0x7ba84fff] > > > > >>[ 2.320910] DMAR: 32bit 0000:00:1d.0 uses non-identity mapping > > > > >>[ 2.321685] DMAR: Setting identity map for device 0000:00:1d.0 > > > > >[0x7ba75000 > > > > >>- 0x7ba84fff] > > > > >># > > > > >> > > > > >> > > > > >>On Tue, Mar 28, 2017 at 1:46 AM, Bodireddy, Bhanuprakash > > > > >>> wrote: > > > > >>Hello shivaram, > > > > >> > > > > >>Darrell has already asked if VT-d is enabled? > > > > >>Your cmdline options are appropriate as you have iommu > > > > >>enabled(intel_iommu=on iommu=pt). > > > > >>can you also check the output of below mentioned command to see > > if VT-d > > > > >is > > > > >>enabled in BIOS? > > > > >> > > > > >>$ dmesg | grep -e DMAR -e IOMMU > > > > >> > > > > >>Regards, > > > > >>Bhanuprakash. > > > > >> > > > > >>From: ovs-discuss-bounces at openvswitch.org [mailto:ovs-discuss- > > > > >>bounces at openvswitch.org] On Behalf Of Shivaram Mysore > > > > >>Sent: Tuesday, March 28, 2017 6:25 AM > > > > >>To: Darrell Ball > > > > > >>Cc: ovs-discuss at openvswitch.org > > > > >>Subject: Re: [ovs-discuss] Error attaching device to DPDK > > > > >> > > > > >># uname -r > > > > >>4.10.0-14-generic > > > > >> > > > > >># cat /proc/cmdline > > > > >>BOOT_IMAGE=/boot/vmlinuz-4.10.0-14-generic > > > > >root=/dev/mapper/intelsdn- > > > > >>-vg-root ro quiet intel_iommu=on iommu=pt default_hugepagesz=1G > > > > >>hugepagesz=1G hugepages=4 > > > > >> > > > > >># uname -a > > > > >>Linux intelsdn 4.10.0-14-generic #16-Ubuntu SMP Fri Mar 17 > > 15:19:26 UTC > > > > >2017 > > > > >>x86_64 x86_64 x86_64 GNU/Linux > > > > >> > > > > >># cat /etc/*release > > > > >>DISTRIB_ID=Ubuntu > > > > >>DISTRIB_RELEASE=17.04 > > > > >>DISTRIB_CODENAME=zesty > > > > >>DISTRIB_DESCRIPTION="Ubuntu Zesty Zapus (development branch)" > > > > >>NAME="Ubuntu" > > > > >>VERSION="17.04 (Zesty Zapus)" > > > > >>ID=ubuntu > > > > >>ID_LIKE=debian > > > > >>PRETTY_NAME="Ubuntu Zesty Zapus (development branch)" > > > > >>VERSION_ID="17.04" > > > > >> > > > > >> > > > > >>Nothing in the syslog related > > > > >> > > > > >>On Mon, Mar 27, 2017 at 10:02 PM, Darrell Ball > > > > > wrote: > > > > >>I see the pastebins now. > > > > >> > > > > >>What kernel version are you using ? > > > > >>VT-d enabled ? > > > > >>Anything related in syslog ? > > > > >> > > > > >>From: Shivaram Mysore > > > > > >>Date: Monday, March 27, 2017 at 9:34 PM > > > > >>To: Darrell Ball > > > > > >>Cc: "ovs-discuss at openvswitch.org" > > > > > >>Subject: Re: [ovs-discuss] Error attaching device to DPDK > > > > >> > > > > >>One more datapoint, please check the paste bin log in URL sent > > > > >earlier. Dpdk- > > > > >>devbind works and you can see results in the paste bin log > > > > >> > > > > >>/Shivaram > > > > >>::Sent from my mobile device:: > > > > >> > > > > >>On Mar 27, 2017, at 8:34 PM, Darrell Ball > wrote: > > > > >>see inline below > > > > >> > > > > >>But a few questions: > > > > >>1) Are you using the recommended version of dpdk with OVS 2.7 ? > > 16.11 ? > > > > >>2) Are you getting a crash still or is this post crash ? > > > > >>3) Was the previous crash still happening with 16.11 or only 17.02 ? > > > > >> > > > > >>Thanks > > > > >>Darrell > > > > >> > > > > >>From: > on behalf of > > Shivaram > > > > >>Mysore > > > > > >>Date: Monday, March 27, 2017 at 7:45 PM > > > > >>To: "ovs-discuss at openvswitch.org" > > > > > >>Subject: [ovs-discuss] Error attaching device to DPDK > > > > >> > > > > >>Hello, > > > > >> > > > > >>I have installed OVS 2.7 running. When I do: > > > > >>1. # ovs-vsctl add-port ovs-ip64-br0 dpdk-p0 -- set Interface dpdk-p0 > > > > >>type=dpdk options:dpdk-devargs=0000:82:00.0 > > > > >>2. ovs-vsctl: Error detected while setting up 'dpdk-p0': Error > attaching > > > > >>device '0000:82:00.0' to DPDK. See ovs-vswitchd log for details. > > > > >> > > > > >>Possibly, the port is not bound. > > > > >>Check using > > > > >>$DPDK_DIR/tools/dpdk-devbind.py ?status > > > > >>and see the documentation for more detail > > > > >> > > > > >>and the log file shows: > > > > >>1. 2017-03-28T02:04:40.004Z|00064|netdev_dpdk|WARN|Error > > attaching > > > > >>device '0000:82:00.0' to DPDK > > > > >>2. 2017-03-28T02:04:40.004Z|00065|netdev|WARN|dpdk-p0: could > > > > >>not set configuration (Invalid argument) > > > > >> > > > > >>What would cause such a situation? > > > > >> > > > > >>Commands run: https://urldefense.proofpoint.com/v2/url?u=https- > > > 3A__pastebin.com_0P754x0t&d=DwIGaQ&c=uilaK90D4TOVoH58JNXRgQ&r= > > BVhFA09CGX7JQ5Ih- > > > uZnsw&m=IKHiqOFj5oogxEfx6OMgK9IHxp2aktbssMBTZUoA2P0&s=XEhP0isS > > M6FAfGw-HXbOfMLfomYnhSo1G2UxvC1qjp8&e= > > > > >>Detailed OVS Log: > > https://urldefense.proofpoint.com/v2/url?u=https- > > > 3A__pastebin.com_ctBhLuRG&d=DwIGaQ&c=uilaK90D4TOVoH58JNXRgQ&r= > > BVhFA09CGX7JQ5Ih- > > > uZnsw&m=IKHiqOFj5oogxEfx6OMgK9IHxp2aktbssMBTZUoA2P0&s=90tudSR > > NE_HlxrCclX83wTmqlUL5xMPrRha7_-fMAKs&e= > > > > >> > > > > >> > > > > > > > > > > > > > > > > > _______________________________________________ > > > > discuss mailing list > > > > discuss at openvswitch.org > > > > https://urldefense.proofpoint.com/v2/url?u=https- > > 3A__mail.openvswitch.org_mailman_listinfo_ovs- > > > 2Ddiscuss&d=DwIGaQ&c=uilaK90D4TOVoH58JNXRgQ&r=BVhFA09CGX7JQ5Ih > > -uZnsw&m=IKHiqOFj5oogxEfx6OMgK9IHxp2aktbssMBTZUoA2P0&s=9- > > oI5HFUKs-b_kDAFcnn2vFwTcuE2xw2SFvd-zE6vWY&e= > > > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From JaiSingh.Rana at cavium.com Tue Aug 22 10:14:55 2017 From: JaiSingh.Rana at cavium.com (Rana, JaiSingh) Date: Tue, 22 Aug 2017 10:14:55 +0000 Subject: [ovs-discuss] ovn-bridge-mappings configuration issue. In-Reply-To: References: , Message-ID: Hi Russel, Thanks for quick reply. Yes i created external network on controller node with neutron net-create NET-EXT --provider:network_type flat --provider:physical_network br-ex --router:external=true --shared Once i corrected option '--provider' option with '--provider:physical_network provider', its working fine on compute node. -Jai ________________________________ From: Russell Bryant Sent: 21 August 2017 21:17 To: Rana, JaiSingh Cc: ovs-discuss at openvswitch.org Subject: Re: [ovs-discuss] ovn-bridge-mappings configuration issue. On Mon, Aug 21, 2017 at 7:43 AM, Rana, JaiSingh wrote: > Hi, > > For configuring external gateway, ovn-controller man page says: > > " > > external_ids:ovn-bridge-mappings > A list of key-value pairs that map a physical network > name to a local ovs bridge that provides connectivity > to that network. An example value mapping two > physical network names to two ovs bridges would be: phys? > net1:br-eth0,physnet2:br-eth1. > " > > > Created bridge br-ex and attached an interface p1p2 having external > connectivity. > > > # ovs-vsctl --may-exist add-br br-ex -- set bridge br-ex > protocols=OpenFlow13 > > # ovs-vsctl set open . external-ids:ovn-bridge-mappings=provider:br-ex > # ovs-vsctl --may-exist add-port br-ex p1p2 > > > After configuring Openstack with external networks, ovn-controller on > compute actually looks for bridge named "provider" in > ovn/controller/patch.c : add_bridge_mappings, which of-course is not created > but throws error that "br-ex" not found as can be seen in ovn-controller.log > > "2017-08-18T11:20:30.477Z|04536|patch|ERR| bridge not found for localnet > port 'provnet-031111bf-ad69-4225-b69c-0cd23d7969af' with network name > 'br-ex'" > > When this external-id is defined as ovn-bridge-mappings=br-ex:br-ex, it > works fine and no error is thrown. > > > Is this a bug or the field before ":" in this external-id represents bridge > name. The error message indicates that a "localnet" was created with a "network_name" of "br-ex". The "network_name" should be set to "provider" in this example. -- Russell Bryant -------------- next part -------------- An HTML attachment was scrubbed... URL: From russell at ovn.org Tue Aug 22 12:12:20 2017 From: russell at ovn.org (Russell Bryant) Date: Tue, 22 Aug 2017 08:12:20 -0400 Subject: [ovs-discuss] ovn-bridge-mappings configuration issue. In-Reply-To: References: Message-ID: Great! Thanks for following up to confirm that it works for you. On Tue, Aug 22, 2017 at 6:14 AM, Rana, JaiSingh wrote: > Hi Russel, > > > Thanks for quick reply. Yes i created external network on controller node > with > > > neutron net-create NET-EXT --provider:network_type flat > --provider:physical_network br-ex --router:external=true --shared > > Once i corrected option '--provider' option with > '--provider:physical_network provider', its working fine on compute node. > > -Jai > > > ________________________________ > From: Russell Bryant > Sent: 21 August 2017 21:17 > To: Rana, JaiSingh > Cc: ovs-discuss at openvswitch.org > Subject: Re: [ovs-discuss] ovn-bridge-mappings configuration issue. > > On Mon, Aug 21, 2017 at 7:43 AM, Rana, JaiSingh > wrote: >> Hi, >> >> For configuring external gateway, ovn-controller man page says: >> >> " >> >> external_ids:ovn-bridge-mappings >> A list of key-value pairs that map a physical network >> name to a local ovs bridge that provides connectivity >> to that network. An example value mapping two >> physical network names to two ovs bridges would be: phys? >> net1:br-eth0,physnet2:br-eth1. >> " >> >> >> Created bridge br-ex and attached an interface p1p2 having external >> connectivity. >> >> >> # ovs-vsctl --may-exist add-br br-ex -- set bridge br-ex >> protocols=OpenFlow13 >> >> # ovs-vsctl set open . external-ids:ovn-bridge-mappings=provider:br-ex >> # ovs-vsctl --may-exist add-port br-ex p1p2 >> >> >> After configuring Openstack with external networks, ovn-controller on >> compute actually looks for bridge named "provider" in >> ovn/controller/patch.c : add_bridge_mappings, which of-course is not >> created >> but throws error that "br-ex" not found as can be seen in >> ovn-controller.log >> >> "2017-08-18T11:20:30.477Z|04536|patch|ERR| bridge not found for localnet >> port 'provnet-031111bf-ad69-4225-b69c-0cd23d7969af' with network name >> 'br-ex'" >> >> When this external-id is defined as ovn-bridge-mappings=br-ex:br-ex, it >> works fine and no error is thrown. >> >> >> Is this a bug or the field before ":" in this external-id represents >> bridge >> name. > > The error message indicates that a "localnet" was created with a > "network_name" of "br-ex". The "network_name" should be set to > "provider" in this example. > > -- > Russell Bryant -- Russell Bryant From dball at vmware.com Wed Aug 23 01:55:20 2017 From: dball at vmware.com (Darrell Ball) Date: Wed, 23 Aug 2017 01:55:20 +0000 Subject: [ovs-discuss] Reg: Ovs-Dpdk Forwarding Plane. In-Reply-To: References: Message-ID: <5588ABC6-BF3A-41E3-9BB9-7C973B161BC8@vmware.com> From: on behalf of Durai Velan Chockalingam Date: Sunday, August 20, 2017 at 12:12 PM To: "ovs-discuss at openvswitch.org" Subject: [ovs-discuss] Reg: Ovs-Dpdk Forwarding Plane. Hello All, Am trying to look for very comprehensive information on How Packet are Handled in Dataplane, for the following communication 1) VM-2-VM in Same compute host ( and both of them are vhostdpdkuser ) I understand that vhostdpdkuser, is nothing but a Unix Socket open, by Ovs-Dpdk and VM are Client. However, I could not undertstand how forwarding of packets are happening between the VM via Socket ?? Does OVS Maintains any Forwarding Information bases for DPDK Vhostuser and if so what is tool to interact without those fibs ?? >>>>>> At the forwarding layer, it a logical dp port (and at openflow layer, it is a of port), similar to other ports. When the packets are received from a port and sent to a port, there is a difference, which is embodied in the netdev layer (in this case, netdev-dpdk), which has vhost specific support, in addition to dpdk managed physical device support. See the below links as well. http://docs.openvswitch.org/en/latest/howto/dpdk/ http://docs.openvswitch.org/en/latest/topics/dpdk/vhost-user/ <<<<<<< 2) VM (Compute Host Network / or VLAN Say 10.0.0.1)-2-PHY--- L2 DEVICE ----2-VM (Another Compute Host, Same Network / or VLAN Say 10.0.0.2 ) Similary, how does Packet flow in this Scenario, and what kind of configuration should be make in L2 Device >>>>>>>>> check the above links as well. <<<<<<<<< Any References, or Documentation explaining this would be also appreciated. Thanks and Regards Durai Velan. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rohith.basavaraja at ericsson.com Wed Aug 23 10:03:20 2017 From: rohith.basavaraja at ericsson.com (Rohith Basavaraja) Date: Wed, 23 Aug 2017 10:03:20 +0000 Subject: [ovs-discuss] Conntrack issue in OVS (2.6)+DPDK Message-ID: Hi, I see that if I have following rules, i.e not allow any new connections and allow only established and related flows, cookie=0x6900001, duration=2819.230s, table=244, n_packets=2, n_bytes=196, priority=50, ct_state=+new+trk,metadata=0x1a530000000000/0x1fffff0000000000 actions=drop cookie=0x6900000, duration=15546.577s, table=244, n_packets=0, n_bytes=0, priority=62020,ct_state=-new-est+rel-inv+trk actions=resubmit(,220) cookie=0x6900000, duration=15546.552s, table=244, n_packets=3819, n_bytes=431050, priority=62020,ct_state=-new+est-rel-inv+trk actions=resubmit(,220) We are still seeing that new connections are getting allowed, we see this behavior/issue only OVS + DPDK and not in OVS kernel mode. Wanted to check if this issue is already reported elsewhere or it?s new issue. Thanks Rohith -------------- next part -------------- An HTML attachment was scrubbed... URL: From cwillman at ixiacom.com Wed Aug 23 16:23:21 2017 From: cwillman at ixiacom.com (Chad Willman) Date: Wed, 23 Aug 2017 16:23:21 +0000 Subject: [ovs-discuss] problem with openvswitch 2.5.2 after upgrade to Ubuntu 16.04 Message-ID: Is there a forum specific to discing issues encountered ? My ovs-vswitchd daemon is consuming 400% CPU and flooding ovs-vswitchd.log with the same message repeatedly - 2017-08-23T16:18:28.049Z|641473|bridge|INFO|bridge ovsbr0: added interface ovsbr0 on port 65534 Looking for help or ideas for debugging the issue. Thanks, CW -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at skyportsystems.com Wed Aug 23 16:43:29 2017 From: ben at skyportsystems.com (Ben Warren) Date: Wed, 23 Aug 2017 09:43:29 -0700 Subject: [ovs-discuss] problem with openvswitch 2.5.2 after upgrade to Ubuntu 16.04 In-Reply-To: References: Message-ID: Hi Chad, I?ve seen this if regular Linux bridging is enabled. The command ?brctl show? will display non-OVS bridges. regards, Ben > On Aug 23, 2017, at 9:23 AM, Chad Willman wrote: > > > Is there a forum specific to discing issues encountered ? > > My ovs-vswitchd daemon is consuming 400% CPU and flooding ovs-vswitchd.log with the same message repeatedly - 2017-08-23T16:18:28.049Z|641473|bridge|INFO|bridge ovsbr0: added interface ovsbr0 on port 65534 > > Looking for help or ideas for debugging the issue. > > Thanks, > > CW > _______________________________________________ > discuss mailing list > discuss at openvswitch.org > https://mail.openvswitch.org/mailman/listinfo/ovs-discuss -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3866 bytes Desc: not available URL: From ben at skyportsystems.com Wed Aug 23 17:24:49 2017 From: ben at skyportsystems.com (Ben Warren) Date: Wed, 23 Aug 2017 10:24:49 -0700 Subject: [ovs-discuss] problem with openvswitch 2.5.2 after upgrade to Ubuntu 16.04 In-Reply-To: References: Message-ID: <0797E5DB-F0E8-4005-AA06-4D140ADDCECA@skyportsystems.com> Hi, I don?t think you should see the OVS bridge there. You should have created the OVS bridge using ?ovs-vsctl add-br?, not using bridge utilities. In my case, ?brctl show? has nothing, while ?ovs-vsctl show? displays my bridge topology. ?Ben > On Aug 23, 2017, at 10:19 AM, Chad Willman wrote: > > Hi, > > I eliminated the lxcbr0, but still have the same problem with ovs-vswitchd eating CPU. > > cwillman at harley:~$ sudo brctl show > bridge name > bridge id STP enabled > interfaces > ovsbr0 > 8000.c6074be69e43 no em1 > vnet0 > vnet1 > vnet2 > > kern.log is also flooding with this message - Aug 23 07:36:03 harley NetworkManager[2481]: [1503491763.8976] device (ovsbr0): enslaved to non-master-type device ovs-system; ignoring > Aug 23 07:36:03 harley kernel: [58455.254778] device ovsbr0 entered promiscuous mode > Aug 23 07:36:03 harley kernel: [58455.257975] device ovsbr0 left promiscuous mode > > Would appreciate any other suggestions. > > Regards, > > Chad > > From: Chad W > > Date: Wednesday, August 23, 2017 at 11:55 AM > To: Ben Warren > > Cc: "ovs-discuss at openvswitch.org " > > Subject: Re: [ovs-discuss] problem with openvswitch 2.5.2 after upgrade to Ubuntu 16.04 > > Hi Ben and thanks for the response. > > brctl shows me this - > bridge namebridge id > STP enabledinterfaces > lxcbr08000.00163e000000 > no > ovsbr08000.c6074be69e43 > no em1 > vnet0 > vnet1 > vnet2 > > The ovsbr0 bridge looks right, but the lxcbr0 should not be there. > Not sure how it got there (we have multiple admins on this system), but I?ll try nuking it. > > Regards, > > Chad > > From: Ben Warren > > Date: Wednesday, August 23, 2017 at 11:43 AM > To: Chad W > > Cc: "ovs-discuss at openvswitch.org " > > Subject: Re: [ovs-discuss] problem with openvswitch 2.5.2 after upgrade to Ubuntu 16.04 > > Hi Chad, > > I?ve seen this if regular Linux bridging is enabled. The command ?brctl show? will display non-OVS bridges. > > regards, > Ben > >> On Aug 23, 2017, at 9:23 AM, Chad Willman > wrote: >> >> >> Is there a forum specific to discing issues encountered ? >> >> My ovs-vswitchd daemon is consuming 400% CPU and flooding ovs-vswitchd.log with the same message repeatedly - 2017-08-23T16:18:28.049Z|641473|bridge|INFO|bridge ovsbr0: added interface ovsbr0 on port 65534 >> >> Looking for help or ideas for debugging the issue. >> >> Thanks, >> >> CW >> _______________________________________________ >> discuss mailing list >> discuss at openvswitch.org >> https://mail.openvswitch.org/mailman/listinfo/ovs-discuss > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3866 bytes Desc: not available URL: From cwillman at ixiacom.com Wed Aug 23 16:55:04 2017 From: cwillman at ixiacom.com (Chad Willman) Date: Wed, 23 Aug 2017 16:55:04 +0000 Subject: [ovs-discuss] problem with openvswitch 2.5.2 after upgrade to Ubuntu 16.04 In-Reply-To: References: Message-ID: Hi Ben and thanks for the response. brctl shows me this - bridge name bridge id STP enabled interfaces lxcbr0 8000.00163e000000 no ovsbr0 8000.c6074be69e43 no em1 vnet0 vnet1 vnet2 The ovsbr0 bridge looks right, but the lxcbr0 should not be there. Not sure how it got there (we have multiple admins on this system), but I?ll try nuking it. Regards, Chad From: Ben Warren > Date: Wednesday, August 23, 2017 at 11:43 AM To: Chad W > Cc: "ovs-discuss at openvswitch.org" > Subject: Re: [ovs-discuss] problem with openvswitch 2.5.2 after upgrade to Ubuntu 16.04 Hi Chad, I?ve seen this if regular Linux bridging is enabled. The command ?brctl show? will display non-OVS bridges. regards, Ben On Aug 23, 2017, at 9:23 AM, Chad Willman > wrote: Is there a forum specific to discing issues encountered ? My ovs-vswitchd daemon is consuming 400% CPU and flooding ovs-vswitchd.log with the same message repeatedly - 2017-08-23T16:18:28.049Z|641473|bridge|INFO|bridge ovsbr0: added interface ovsbr0 on port 65534 Looking for help or ideas for debugging the issue. Thanks, CW _______________________________________________ discuss mailing list discuss at openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss -------------- next part -------------- An HTML attachment was scrubbed... URL: From cwillman at ixiacom.com Wed Aug 23 17:19:52 2017 From: cwillman at ixiacom.com (Chad Willman) Date: Wed, 23 Aug 2017 17:19:52 +0000 Subject: [ovs-discuss] problem with openvswitch 2.5.2 after upgrade to Ubuntu 16.04 In-Reply-To: References: Message-ID: Hi, I eliminated the lxcbr0, but still have the same problem with ovs-vswitchd eating CPU. cwillman at harley:~$ sudo brctl show bridge name bridge id STP enabled interfaces ovsbr0 8000.c6074be69e43 no em1 vnet0 vnet1 vnet2 kern.log is also flooding with this message - Aug 23 07:36:03 harley NetworkManager[2481]: [1503491763.8976] device (ovsbr0): enslaved to non-master-type device ovs-system; ignoring Aug 23 07:36:03 harley kernel: [58455.254778] device ovsbr0 entered promiscuous mode Aug 23 07:36:03 harley kernel: [58455.257975] device ovsbr0 left promiscuous mode Would appreciate any other suggestions. Regards, Chad From: Chad W > Date: Wednesday, August 23, 2017 at 11:55 AM To: Ben Warren > Cc: "ovs-discuss at openvswitch.org" > Subject: Re: [ovs-discuss] problem with openvswitch 2.5.2 after upgrade to Ubuntu 16.04 Hi Ben and thanks for the response. brctl shows me this - bridge namebridge id STP enabledinterfaces lxcbr08000.00163e000000 no ovsbr08000.c6074be69e43 no em1 vnet0 vnet1 vnet2 The ovsbr0 bridge looks right, but the lxcbr0 should not be there. Not sure how it got there (we have multiple admins on this system), but I?ll try nuking it. Regards, Chad From: Ben Warren > Date: Wednesday, August 23, 2017 at 11:43 AM To: Chad W > Cc: "ovs-discuss at openvswitch.org" > Subject: Re: [ovs-discuss] problem with openvswitch 2.5.2 after upgrade to Ubuntu 16.04 Hi Chad, I?ve seen this if regular Linux bridging is enabled. The command ?brctl show? will display non-OVS bridges. regards, Ben On Aug 23, 2017, at 9:23 AM, Chad Willman > wrote: Is there a forum specific to discing issues encountered ? My ovs-vswitchd daemon is consuming 400% CPU and flooding ovs-vswitchd.log with the same message repeatedly - 2017-08-23T16:18:28.049Z|641473|bridge|INFO|bridge ovsbr0: added interface ovsbr0 on port 65534 Looking for help or ideas for debugging the issue. Thanks, CW _______________________________________________ discuss mailing list discuss at openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss -------------- next part -------------- An HTML attachment was scrubbed... URL: From joe at ovn.org Wed Aug 23 17:36:02 2017 From: joe at ovn.org (Joe Stringer) Date: Wed, 23 Aug 2017 10:36:02 -0700 Subject: [ovs-discuss] Conntrack issue in OVS (2.6)+DPDK In-Reply-To: References: Message-ID: On 23 August 2017 at 03:03, Rohith Basavaraja wrote: > Hi, > > > > I see that if I have following rules, i.e not allow any new connections and > allow only established and related flows, > > > > cookie=0x6900001, duration=2819.230s, table=244, n_packets=2, n_bytes=196, > priority=50, ct_state=+new+trk,metadata=0x1a530000000000/0x1fffff0000000000 > actions=drop > > cookie=0x6900000, duration=15546.577s, table=244, n_packets=0, n_bytes=0, > priority=62020,ct_state=-new-est+rel-inv+trk actions=resubmit(,220) > > cookie=0x6900000, duration=15546.552s, table=244, n_packets=3819, > n_bytes=431050, priority=62020,ct_state=-new+est-rel-inv+trk > actions=resubmit(,220) > > > > We are still seeing that new connections are getting allowed, we see this > behavior/issue only OVS + DPDK and not in OVS kernel mode. > > > > Wanted to check if this issue is already reported elsewhere or it?s new > issue. I haven't heard any reports like this before; could you come up with a minimal test case that exhibits this behaviour? It's hard to get a good sense of what's going on without the full set of rules being hit. From dball at vmware.com Wed Aug 23 18:50:58 2017 From: dball at vmware.com (Darrell Ball) Date: Wed, 23 Aug 2017 18:50:58 +0000 Subject: [ovs-discuss] Conntrack issue in OVS (2.6)+DPDK Message-ID: <48A78FED-73A2-4CA0-8D8F-F968403DC38D@vmware.com> Hi Rohith I might have missed the alias earlier. From the below o/p, I see the rule cookie=0x6900000, duration=15546.577s, table=244, n_packets=0, n_bytes=0, priority=62020,ct_state=-new-est+rel-inv+trk actions=resubmit(,220) not being hit. I also see the rule cookie=0x6900001, duration=2819.230s, table=244, n_packets=2, n_bytes=196, priority=50, ct_state=+new+trk,metadata=0x1a530000000000/0x1fffff0000000000 actions=drop having a drop action. What is the expectation of the test ? Is table 244 intended to drop non-related and non-established packets ? Thanks Darrell From: on behalf of Rohith Basavaraja Date: Wednesday, August 23, 2017 at 3:03 AM To: "ovs-discuss at openvswitch.org" Subject: [ovs-discuss] Conntrack issue in OVS (2.6)+DPDK Hi, I see that if I have following rules, i.e not allow any new connections and allow only established and related flows, cookie=0x6900001, duration=2819.230s, table=244, n_packets=2, n_bytes=196, priority=50, ct_state=+new+trk,metadata=0x1a530000000000/0x1fffff0000000000 actions=drop cookie=0x6900000, duration=15546.577s, table=244, n_packets=0, n_bytes=0, priority=62020,ct_state=-new-est+rel-inv+trk actions=resubmit(,220) cookie=0x6900000, duration=15546.552s, table=244, n_packets=3819, n_bytes=431050, priority=62020,ct_state=-new+est-rel-inv+trk actions=resubmit(,220) We are still seeing that new connections are getting allowed, we see this behavior/issue only OVS + DPDK and not in OVS kernel mode. Wanted to check if this issue is already reported elsewhere or it?s new issue. Thanks Rohith -------------- next part -------------- An HTML attachment was scrubbed... URL: From rohith.basavaraja at ericsson.com Wed Aug 23 19:13:06 2017 From: rohith.basavaraja at ericsson.com (Rohith Basavaraja) Date: Wed, 23 Aug 2017 19:13:06 +0000 Subject: [ovs-discuss] Conntrack issue in OVS (2.6)+DPDK In-Reply-To: <48A78FED-73A2-4CA0-8D8F-F968403DC38D@vmware.com> References: <48A78FED-73A2-4CA0-8D8F-F968403DC38D@vmware.com> Message-ID: <92FBE580-8234-4A84-80CC-9EC03329A228@ericsson.com> Hi Darrell, Yes the expected outcome is to drop new or non related connection, and allow only related or established connections. Just for the clarity adding the details of the topology and pipeline rules. Description about the topology ========================= VM1 and VM4 VMs are on same compute node but with different SGs. For VM4, security rules configured are as below: Egress/Ingress Allow all For VM1, Egress Allow all Ingress Allow only from VMs which are in same security group. For above combination, all conntrack flows required (in tables 213, 214 on VM egress side and 243, 244) are properly programmed in the OVS. For traffic sent from VM4 to VM1 , conntrack is allowing traffic which should have been dropped as the ingress for later is to be allowed only from the VMs of the same SG. For VM1 , conntrack is directly sending traffic to "ct_state==-new+est-rel-inv+trk " flow by-passing "ct_state=+new+trk" flow in the ingress direction. Following is the pipe line rules details ============================== VM4 is on 112/15: (dpdkvhostuser: configured_rx_queues=1, configured_tx_queues=1, mtu=2140, requested_rx_queues=1, requested_tx_queues=1) VM1 is on 108/11: (dpdkvhostuser: configured_rx_queues=1, configured_tx_queues=1, mtu=2140, requested_rx_queues=1, requested_tx_queues=1) VM4 IP: 172.20.1.113 MAC: fa:16:3e:55:9e:33 VM1 IP: 172.20.1.117 MAC : fa:16:3e:f7:72:d3 I am doing Ping from VM4 (172.20.1.113 ) to VM1 (172.20.1.117). cookie=0x8000000, duration=2809.367s, table=0, n_packets=74, n_bytes=10426, priority=4,in_port=112,vlan_tci=0x0000/0x1fff actions=write_metadata:0x19f40000000000/0xffffff0000000001,goto_table:17 cookie=0x6900000, duration=2809.343s, table=17, n_packets=74, n_bytes=10426, priority=10,metadata=0x19f40000000000/0xffffff0000000000 actions=write_metadata:0x4019f40000000000/0xfffffffffffffffe,goto_table:211 cookie=0x6900000, duration=2809.313s, table=211, n_packets=54, n_bytes=8674, priority=61010,ip,metadata=0x19f40000000000/0x1fffff0000000000,dl_src=fa:16:3e:55:9e:33,nw_src=172.20.1.113 actions=goto_table:212 cookie=0x6900000, duration=15546.529s, table=212, n_packets=3669, n_bytes=361562, priority=61010,icmp actions=goto_table:213 cookie=0x6900000, duration=2809.308s, table=213, n_packets=54, n_bytes=8674, priority=61010,ip,metadata=0x19f40000000000/0x1fffff0000000000 actions=ct(table=214,zone=5021) cookie=0x6900000, duration=15546.544s, table=214, n_packets=3660, n_bytes=367508, priority=62020,ct_state=-new+est-rel-inv+trk actions=resubmit(,17) cookie=0x6900001, duration=2809.304s, table=214, n_packets=2, n_bytes=180, priority=62015,ct_state=+inv+trk,metadata=0x19f40000000000/0x1fffff0000000000 actions=drop cookie=0x6900000, duration=2809.295s, table=214, n_packets=10, n_bytes=908, priority=1000,ct_state=+new+trk,ip,metadata=0x19f40000000000/0x1fffff0000000000 actions=ct(commit,zone=5021),resubmit(,17) cookie=0x6800001, duration=2807.340s, table=17, n_packets=72, n_bytes=10246, priority=10,metadata=0x4019f40000000000/0xffffff0000000000 actions=write_metadata:0xc019f40000000000/0xfffffffffffffffe,goto_table:60 cookie=0x6800000, duration=15546.596s, table=60, n_packets=262265, n_bytes=19604926, priority=0 actions=resubmit(,17) cookie=0x8040000, duration=2807.338s, table=17, n_packets=70, n_bytes=9562, priority=10,metadata=0xc019f40000000000/0xffffff0000000000 actions=write_metadata:0xe019f4139d000000/0xfffffffffffffffe,goto_table:48 cookie=0x8500000, duration=15546.528s, table=48, n_packets=302458, n_bytes=34190652, priority=0 actions=resubmit(,49),resubmit(,50) cookie=0x805139d, duration=2808.378s, table=50, n_packets=70, n_bytes=9562, priority=20,metadata=0x19f4139d000000/0x1fffffffff000000,dl_src=fa:16:3e:55:9e:33 actions=goto_table:51 cookie=0x803139d, duration=2818.232s, table=51, n_packets=34, n_bytes=4613, priority=20,metadata=0x139d000000/0xffff000000,dl_dst=fa:16:3e:f7:72:d3 actions=load:0x1a5300->NXM_NX_REG6[],resubmit(,220) cookie=0x6900000, duration=2819.193s, table=220, n_packets=3455, n_bytes=207541, priority=6,reg6=0x1a5300 actions=load:0xe01a5300->NXM_NX_REG6[],write_metadata:0xe01a530000000000/0xfffffffffffffffe,goto_table:241 cookie=0x6900000, duration=2819.237s, table=241, n_packets=32, n_bytes=4851, priority=61010,ip,metadata=0x1a530000000000/0x1fffff0000000000,dl_dst=fa:16:3e:f7:72:d3,nw_dst=172.20.1.117 actions=goto_table:242 cookie=0x6900000, duration=15546.579s, table=242, n_packets=3738, n_bytes=368372, priority=61010,icmp actions=goto_table:243 cookie=0x6900000, duration=2819.235s, table=243, n_packets=32, n_bytes=4851, priority=61010,ip,metadata=0x1a530000000000/0x1fffff0000000000 actions=ct(table=244,zone=5021) cookie=0x6900001, duration=2819.230s, table=244, n_packets=2, n_bytes=196, priority=50,ct_state=+new+trk,metadata=0x1a530000000000/0x1fffff0000000000 actions=drop cookie=0x6900000, duration=15546.577s, table=244, n_packets=0, n_bytes=0, priority=62020,ct_state=-new-est+rel-inv+trk actions=resubmit(,220) cookie=0x6900000, duration=15546.552s, table=244, n_packets=3819, n_bytes=431050, priority=62020,ct_state=-new+est-rel-inv+trk actions=resubmit(,220) cookie=0x8000007, duration=2819.193s, table=220, n_packets=107, n_bytes=9431, priority=7,reg6=0xe01a5300 actions=output:108 Thanks Rohith From: Darrell Ball Date: Thursday, 24 August 2017 at 12:20 AM To: Rohith Basavaraja , "ovs-discuss at openvswitch.org" Subject: Re: [ovs-discuss] Conntrack issue in OVS (2.6)+DPDK Hi Rohith I might have missed the alias earlier. From the below o/p, I see the rule cookie=0x6900000, duration=15546.577s, table=244, n_packets=0, n_bytes=0, priority=62020,ct_state=-new-est+rel-inv+trk actions=resubmit(,220) not being hit. I also see the rule cookie=0x6900001, duration=2819.230s, table=244, n_packets=2, n_bytes=196, priority=50, ct_state=+new+trk,metadata=0x1a530000000000/0x1fffff0000000000 actions=drop having a drop action. What is the expectation of the test ? Is table 244 intended to drop non-related and non-established packets ? Thanks Darrell From: on behalf of Rohith Basavaraja Date: Wednesday, August 23, 2017 at 3:03 AM To: "ovs-discuss at openvswitch.org" Subject: [ovs-discuss] Conntrack issue in OVS (2.6)+DPDK Hi, I see that if I have following rules, i.e not allow any new connections and allow only established and related flows, cookie=0x6900001, duration=2819.230s, table=244, n_packets=2, n_bytes=196, priority=50, ct_state=+new+trk,metadata=0x1a530000000000/0x1fffff0000000000 actions=drop cookie=0x6900000, duration=15546.577s, table=244, n_packets=0, n_bytes=0, priority=62020,ct_state=-new-est+rel-inv+trk actions=resubmit(,220) cookie=0x6900000, duration=15546.552s, table=244, n_packets=3819, n_bytes=431050, priority=62020,ct_state=-new+est-rel-inv+trk actions=resubmit(,220) We are still seeing that new connections are getting allowed, we see this behavior/issue only OVS + DPDK and not in OVS kernel mode. Wanted to check if this issue is already reported elsewhere or it?s new issue. Thanks Rohith -------------- next part -------------- An HTML attachment was scrubbed... URL: From pradeepks.hpt at gmail.com Wed Aug 23 19:01:10 2017 From: pradeepks.hpt at gmail.com (Pradeep K.S) Date: Wed, 23 Aug 2017 12:01:10 -0700 Subject: [ovs-discuss] Matching fields with GRE+NSH Message-ID: Hi, I have packet structure with following format eth | OuterIP |GRE | NSH | Inner IP packet *Few Questions:* 1) Does Open Flow matching supports raw data[Eth+OuterIP+GRE+NSH+InnerIP] packet match. atleast from my reading ovs-ofctl, ovs-fields documentation I did not find such a thing. 2) Currently I can match till GRE[Outer +Inner Packet], But for NSH matching the diff is not upstreamed yet. I see some threads of having discussions about upstreaming this change. https://github.com/yyang13/ovs_nsh_patches/issues/new Does upstream version will support VXLAN+NSH or have plans for other transport headers for NSH like GRE+NSH Regards, Pradeep.K.S. -------------- next part -------------- An HTML attachment was scrubbed... URL: From wangzhike at jd.com Thu Aug 24 03:41:05 2017 From: wangzhike at jd.com (=?utf-8?B?546L5b+X5YWL?=) Date: Thu, 24 Aug 2017 03:41:05 +0000 Subject: [ovs-discuss] OVS+DPDK QoS rate limit issue Message-ID: <6DAF063A35010343823807B082E5681F1A72EB30@mbx05.360buyAD.local> Hi All, I am using OVS2.7.0 and DPDK 16.11, and testing rate limit function. I found that if the policing_rate is set very large, say 5Gbps, the rate is limited dramatically to very low value, like 800Mbps. The command is as below: ovs-vsctl set interface port-7zel2so9sg ingress_policing_rate=5000000 ingress_policing_burst=500000 If we set the rate lower than 4Gbps, the rate is limited correctly. Test setup: Sender (DPDK pktGen) sends out about 10Gbps udp packet, with size about 1420 IP size. The rate limit is set on VM vhost-user-client port. Any idea about this issue? Is that known issue? Br, Wang Zhike -------------- next part -------------- An HTML attachment was scrubbed... URL: From darragh.oreilly at hpe.com Thu Aug 24 07:54:34 2017 From: darragh.oreilly at hpe.com (O'Reilly, Darragh) Date: Thu, 24 Aug 2017 07:54:34 +0000 Subject: [ovs-discuss] problem with openvswitch 2.5.2 after upgrade to Ubuntu 16.04 In-Reply-To: References: Message-ID: Maybe a NetworkManager problem. I would disable it completely on a server, but maybe you could change it to ignore OVS interfaces. From: ovs-discuss-bounces at openvswitch.org [mailto:ovs-discuss-bounces at openvswitch.org] On Behalf Of Chad Willman Sent: 23 August 2017 18:20 To: Ben Warren Cc: ovs-discuss at openvswitch.org Subject: Re: [ovs-discuss] problem with openvswitch 2.5.2 after upgrade to Ubuntu 16.04 Hi, I eliminated the lxcbr0, but still have the same problem with ovs-vswitchd eating CPU. cwillman at harley:~$ sudo brctl show bridge name bridge id STP enabled interfaces ovsbr0 8000.c6074be69e43 no em1 vnet0 vnet1 vnet2 kern.log is also flooding with this message - Aug 23 07:36:03 harley NetworkManager[2481]: [1503491763.8976] device (ovsbr0): enslaved to non-master-type device ovs-system; ignoring Aug 23 07:36:03 harley kernel: [58455.254778] device ovsbr0 entered promiscuous mode Aug 23 07:36:03 harley kernel: [58455.257975] device ovsbr0 left promiscuous mode Would appreciate any other suggestions. Regards, Chad From: Chad W > Date: Wednesday, August 23, 2017 at 11:55 AM To: Ben Warren > Cc: "ovs-discuss at openvswitch.org" > Subject: Re: [ovs-discuss] problem with openvswitch 2.5.2 after upgrade to Ubuntu 16.04 Hi Ben and thanks for the response. brctl shows me this - bridge namebridge id STP enabledinterfaces lxcbr08000.00163e000000 no ovsbr08000.c6074be69e43 no em1 vnet0 vnet1 vnet2 The ovsbr0 bridge looks right, but the lxcbr0 should not be there. Not sure how it got there (we have multiple admins on this system), but I'll try nuking it. Regards, Chad From: Ben Warren > Date: Wednesday, August 23, 2017 at 11:43 AM To: Chad W > Cc: "ovs-discuss at openvswitch.org" > Subject: Re: [ovs-discuss] problem with openvswitch 2.5.2 after upgrade to Ubuntu 16.04 Hi Chad, I've seen this if regular Linux bridging is enabled. The command 'brctl show' will display non-OVS bridges. regards, Ben On Aug 23, 2017, at 9:23 AM, Chad Willman > wrote: Is there a forum specific to discing issues encountered ? My ovs-vswitchd daemon is consuming 400% CPU and flooding ovs-vswitchd.log with the same message repeatedly - 2017-08-23T16:18:28.049Z|641473|bridge|INFO|bridge ovsbr0: added interface ovsbr0 on port 65534 Looking for help or ideas for debugging the issue. Thanks, CW _______________________________________________ discuss mailing list discuss at openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss -------------- next part -------------- An HTML attachment was scrubbed... URL: From lrichard at redhat.com Thu Aug 24 12:10:15 2017 From: lrichard at redhat.com (Lance Richardson) Date: Thu, 24 Aug 2017 08:10:15 -0400 (EDT) Subject: [ovs-discuss] OVS+DPDK QoS rate limit issue In-Reply-To: <6DAF063A35010343823807B082E5681F1A72EB30@mbx05.360buyAD.local> References: <6DAF063A35010343823807B082E5681F1A72EB30@mbx05.360buyAD.local> Message-ID: <490755984.1332121.1503576615786.JavaMail.zimbra@redhat.com> > From: "???" > To: ovs-dev at openvswitch.org, ovs-discuss at openvswitch.org > Sent: Wednesday, August 23, 2017 11:41:05 PM > Subject: [ovs-discuss] OVS+DPDK QoS rate limit issue > > > > Hi All, > > > > I am using OVS2.7.0 and DPDK 16.11, and testing rate limit function. > > > > I found that if the policing_rate is set very large, say 5Gbps, the rate is > limited dramatically to very low value, like 800Mbps. > > The command is as below: > > ovs-vsctl set interface port-7zel2so9sg ingress_policing_rate=5000000 > ingress_policing_burst=500000 > > > > If we set the rate lower than 4Gbps, the rate is limited correctly. > > > > Test setup: > > Sender (DPDK pktGen) sends out about 10Gbps udp packet, with size about 1420 > IP size. > > The rate limit is set on VM vhost-user-client port. > > > > Any idea about this issue? Is that known issue? > > It seems 32-bit arithmetic is being used when converting the rate from kilobits per second to bytes per second. Could you give this patch a try? diff --git a/lib/netdev-dpdk.c b/lib/netdev-dpdk.c index 1aaf6f7e2..d6ed2c7b0 100644 --- a/lib/netdev-dpdk.c +++ b/lib/netdev-dpdk.c @@ -2229,8 +2229,8 @@ netdev_dpdk_policer_construct(uint32_t rate, uint32_t burst) ?? ? rte_spinlock_init(&policer->policer_lock); ? ?? ? /* rte_meter requires bytes so convert kbits rate and burst to bytes. */ - ? ?rate_bytes = rate * 1000/8; - ? ?burst_bytes = burst * 1000/8; + ? ?rate_bytes = rate * 1000ULL/8; + ? ?burst_bytes = burst * 1000ULL/8; ? ?? ? policer->app_srtcm_params.cir = rate_bytes; ?? ? policer->app_srtcm_params.cbs = burst_bytes; Regards, Lance Richardson > > Br, > > Wang Zhike > > _______________________________________________ > discuss mailing list > discuss at openvswitch.org > https://mail.openvswitch.org/mailman/listinfo/ovs-discuss > From cwillman at ixiacom.com Thu Aug 24 12:20:48 2017 From: cwillman at ixiacom.com (Chad Willman) Date: Thu, 24 Aug 2017 12:20:48 +0000 Subject: [ovs-discuss] problem with openvswitch 2.5.2 after upgrade to Ubuntu 16.04 In-Reply-To: References: Message-ID: <7F6AD0CA-AA6E-4C66-9F5C-9D830A19B8F1@ixiacom.com> Couple of notes. I disabled NetworkManager service. It got rid of the NetworkManager kern.log, but the ?device ovsbr0 entered/left promiscuous mode? is still there. Regarding creating the bridge using ovs-vsctl vs brctl, I completely removed the ovsbr0 bridge, removed the openvswitch 2.5.2 packages, and verified that ?brctl show? displayed nothing. Then I reinstalled the openvswitch 2.5.2 packages and recreated the ovsbr0 bridge using ovs-vsctl. The ?brctl show? command still displays the ovsbr0 bridge, even though it was created with the ovs-vsctl command (re: Ben?s comment earlier in the thread). Still getting ?2017-08-24T12:11:39.089Z|385668|bridge|INFO|bridge ovsbr0: added interface ovsbr0 on port 65534? in the ovs-vswitchd log as well. But disabling the NetworkManager service was a clue. The Ubuntu system I?m trying to fix is a hybrid of sorts. It was installed with Ubuntu Server 14.04, but was later modified to enable graphical access through VNC (hence, NetworkManager being active). It?s possible there are other elements at work, that are related to that hybrid configuration. The interesting part is that the system has been operating fine with 14.04 for 3 years. It wasn?t until the upgrade to Ubuntu 16.04 that the issue began. That upgrade took openvswitch from 2.0.2 to 2.5.2 (Ubuntu?s package versions). Thanks for the responses. CW From: "O'Reilly, Darragh" Date: Thursday, August 24, 2017 at 2:54 AM To: Chad Willman , Ben Warren Cc: "ovs-discuss at openvswitch.org" Subject: RE: [ovs-discuss] problem with openvswitch 2.5.2 after upgrade to Ubuntu 16.04 Maybe a NetworkManager problem. I would disable it completely on a server, but maybe you could change it to ignore OVS interfaces. From: ovs-discuss-bounces at openvswitch.org [mailto:ovs-discuss-bounces at openvswitch.org] On Behalf Of Chad Willman Sent: 23 August 2017 18:20 To: Ben Warren Cc: ovs-discuss at openvswitch.org Subject: Re: [ovs-discuss] problem with openvswitch 2.5.2 after upgrade to Ubuntu 16.04 Hi, I eliminated the lxcbr0, but still have the same problem with ovs-vswitchd eating CPU. cwillman at harley:~$ sudo brctl show bridge name bridge id STP enabled interfaces ovsbr0 8000.c6074be69e43 no em1 vnet0 vnet1 vnet2 kern.log is also flooding with this message - Aug 23 07:36:03 harley NetworkManager[2481]: [1503491763.8976] device (ovsbr0): enslaved to non-master-type device ovs-system; ignoring Aug 23 07:36:03 harley kernel: [58455.254778] device ovsbr0 entered promiscuous mode Aug 23 07:36:03 harley kernel: [58455.257975] device ovsbr0 left promiscuous mode Would appreciate any other suggestions. Regards, Chad From: Chad W > Date: Wednesday, August 23, 2017 at 11:55 AM To: Ben Warren > Cc: "ovs-discuss at openvswitch.org" > Subject: Re: [ovs-discuss] problem with openvswitch 2.5.2 after upgrade to Ubuntu 16.04 Hi Ben and thanks for the response. brctl shows me this - bridge namebridge id STP enabledinterfaces lxcbr08000.00163e000000 no ovsbr08000.c6074be69e43 no em1 vnet0 vnet1 vnet2 The ovsbr0 bridge looks right, but the lxcbr0 should not be there. Not sure how it got there (we have multiple admins on this system), but I?ll try nuking it. Regards, Chad From: Ben Warren > Date: Wednesday, August 23, 2017 at 11:43 AM To: Chad W > Cc: "ovs-discuss at openvswitch.org" > Subject: Re: [ovs-discuss] problem with openvswitch 2.5.2 after upgrade to Ubuntu 16.04 Hi Chad, I?ve seen this if regular Linux bridging is enabled. The command ?brctl show? will display non-OVS bridges. regards, Ben On Aug 23, 2017, at 9:23 AM, Chad Willman > wrote: Is there a forum specific to discing issues encountered ? My ovs-vswitchd daemon is consuming 400% CPU and flooding ovs-vswitchd.log with the same message repeatedly - 2017-08-23T16:18:28.049Z|641473|bridge|INFO|bridge ovsbr0: added interface ovsbr0 on port 65534 Looking for help or ideas for debugging the issue. Thanks, CW _______________________________________________ discuss mailing list discuss at openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss -------------- next part -------------- An HTML attachment was scrubbed... URL: From cwillman at ixiacom.com Thu Aug 24 14:47:29 2017 From: cwillman at ixiacom.com (Chad Willman) Date: Thu, 24 Aug 2017 14:47:29 +0000 Subject: [ovs-discuss] problem with openvswitch 2.5.2 after upgrade to Ubuntu 16.04 In-Reply-To: <7F6AD0CA-AA6E-4C66-9F5C-9D830A19B8F1@ixiacom.com> References: <7F6AD0CA-AA6E-4C66-9F5C-9D830A19B8F1@ixiacom.com> Message-ID: Thanks very much for your replies to my issue, folks. I?ve decide to remove OVS from the system and return to Linux bridging. OVS is the only thing that didn?t survive the upgrade to Ubuntu 16.04 and it may take some time to debug the problem, especially with no support from Ubuntu. I don?t have that time to spare. Again, I?m much obliged for your responses. Regards, Chad Willman From: Chad Willman Date: Thursday, August 24, 2017 at 7:20 AM To: "O'Reilly, Darragh" , Ben Warren Cc: "ovs-discuss at openvswitch.org" Subject: Re: [ovs-discuss] problem with openvswitch 2.5.2 after upgrade to Ubuntu 16.04 Couple of notes. I disabled NetworkManager service. It got rid of the NetworkManager kern.log, but the ?device ovsbr0 entered/left promiscuous mode? is still there. Regarding creating the bridge using ovs-vsctl vs brctl, I completely removed the ovsbr0 bridge, removed the openvswitch 2.5.2 packages, and verified that ?brctl show? displayed nothing. Then I reinstalled the openvswitch 2.5.2 packages and recreated the ovsbr0 bridge using ovs-vsctl. The ?brctl show? command still displays the ovsbr0 bridge, even though it was created with the ovs-vsctl command (re: Ben?s comment earlier in the thread). Still getting ?2017-08-24T12:11:39.089Z|385668|bridge|INFO|bridge ovsbr0: added interface ovsbr0 on port 65534? in the ovs-vswitchd log as well. But disabling the NetworkManager service was a clue. The Ubuntu system I?m trying to fix is a hybrid of sorts. It was installed with Ubuntu Server 14.04, but was later modified to enable graphical access through VNC (hence, NetworkManager being active). It?s possible there are other elements at work, that are related to that hybrid configuration. The interesting part is that the system has been operating fine with 14.04 for 3 years. It wasn?t until the upgrade to Ubuntu 16.04 that the issue began. That upgrade took openvswitch from 2.0.2 to 2.5.2 (Ubuntu?s package versions). Thanks for the responses. CW From: "O'Reilly, Darragh" Date: Thursday, August 24, 2017 at 2:54 AM To: Chad Willman , Ben Warren Cc: "ovs-discuss at openvswitch.org" Subject: RE: [ovs-discuss] problem with openvswitch 2.5.2 after upgrade to Ubuntu 16.04 Maybe a NetworkManager problem. I would disable it completely on a server, but maybe you could change it to ignore OVS interfaces. From: ovs-discuss-bounces at openvswitch.org [mailto:ovs-discuss-bounces at openvswitch.org] On Behalf Of Chad Willman Sent: 23 August 2017 18:20 To: Ben Warren Cc: ovs-discuss at openvswitch.org Subject: Re: [ovs-discuss] problem with openvswitch 2.5.2 after upgrade to Ubuntu 16.04 Hi, I eliminated the lxcbr0, but still have the same problem with ovs-vswitchd eating CPU. cwillman at harley:~$ sudo brctl show bridge name bridge id STP enabled interfaces ovsbr0 8000.c6074be69e43 no em1 vnet0 vnet1 vnet2 kern.log is also flooding with this message - Aug 23 07:36:03 harley NetworkManager[2481]: [1503491763.8976] device (ovsbr0): enslaved to non-master-type device ovs-system; ignoring Aug 23 07:36:03 harley kernel: [58455.254778] device ovsbr0 entered promiscuous mode Aug 23 07:36:03 harley kernel: [58455.257975] device ovsbr0 left promiscuous mode Would appreciate any other suggestions. Regards, Chad From: Chad W > Date: Wednesday, August 23, 2017 at 11:55 AM To: Ben Warren > Cc: "ovs-discuss at openvswitch.org" > Subject: Re: [ovs-discuss] problem with openvswitch 2.5.2 after upgrade to Ubuntu 16.04 Hi Ben and thanks for the response. brctl shows me this - bridge namebridge id STP enabledinterfaces lxcbr08000.00163e000000 no ovsbr08000.c6074be69e43 no em1 vnet0 vnet1 vnet2 The ovsbr0 bridge looks right, but the lxcbr0 should not be there. Not sure how it got there (we have multiple admins on this system), but I?ll try nuking it. Regards, Chad From: Ben Warren > Date: Wednesday, August 23, 2017 at 11:43 AM To: Chad W > Cc: "ovs-discuss at openvswitch.org" > Subject: Re: [ovs-discuss] problem with openvswitch 2.5.2 after upgrade to Ubuntu 16.04 Hi Chad, I?ve seen this if regular Linux bridging is enabled. The command ?brctl show? will display non-OVS bridges. regards, Ben On Aug 23, 2017, at 9:23 AM, Chad Willman > wrote: Is there a forum specific to discing issues encountered ? My ovs-vswitchd daemon is consuming 400% CPU and flooding ovs-vswitchd.log with the same message repeatedly - 2017-08-23T16:18:28.049Z|641473|bridge|INFO|bridge ovsbr0: added interface ovsbr0 on port 65534 Looking for help or ideas for debugging the issue. Thanks, CW _______________________________________________ discuss mailing list discuss at openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss -------------- next part -------------- An HTML attachment was scrubbed... URL: From wangzhike at jd.com Fri Aug 25 02:16:27 2017 From: wangzhike at jd.com (=?utf-8?B?546L5b+X5YWL?=) Date: Fri, 25 Aug 2017 02:16:27 +0000 Subject: [ovs-discuss] OVS+DPDK QoS rate limit issue In-Reply-To: <490755984.1332121.1503576615786.JavaMail.zimbra@redhat.com> References: <6DAF063A35010343823807B082E5681F1A72EB30@mbx05.360buyAD.local> <490755984.1332121.1503576615786.JavaMail.zimbra@redhat.com> Message-ID: <6DAF063A35010343823807B082E5681F1A72ECED@mbx05.360buyAD.local> Hi Lance, Your patch works. Thanks. BR, Wang Zhike -----Original Message----- From: Lance Richardson [mailto:lrichard at redhat.com] Sent: Thursday, August 24, 2017 8:10 PM To: ??? Cc: ovs-dev at openvswitch.org; ovs-discuss at openvswitch.org Subject: Re: [ovs-discuss] OVS+DPDK QoS rate limit issue > From: "???" > To: ovs-dev at openvswitch.org, ovs-discuss at openvswitch.org > Sent: Wednesday, August 23, 2017 11:41:05 PM > Subject: [ovs-discuss] OVS+DPDK QoS rate limit issue > > > > Hi All, > > > > I am using OVS2.7.0 and DPDK 16.11, and testing rate limit function. > > > > I found that if the policing_rate is set very large, say 5Gbps, the rate is > limited dramatically to very low value, like 800Mbps. > > The command is as below: > > ovs-vsctl set interface port-7zel2so9sg ingress_policing_rate=5000000 > ingress_policing_burst=500000 > > > > If we set the rate lower than 4Gbps, the rate is limited correctly. > > > > Test setup: > > Sender (DPDK pktGen) sends out about 10Gbps udp packet, with size about 1420 > IP size. > > The rate limit is set on VM vhost-user-client port. > > > > Any idea about this issue? Is that known issue? > > It seems 32-bit arithmetic is being used when converting the rate from kilobits per second to bytes per second. Could you give this patch a try? diff --git a/lib/netdev-dpdk.c b/lib/netdev-dpdk.c index 1aaf6f7e2..d6ed2c7b0 100644 --- a/lib/netdev-dpdk.c +++ b/lib/netdev-dpdk.c @@ -2229,8 +2229,8 @@ netdev_dpdk_policer_construct(uint32_t rate, uint32_t burst) ?? ? rte_spinlock_init(&policer->policer_lock); ? ?? ? /* rte_meter requires bytes so convert kbits rate and burst to bytes. */ - ? ?rate_bytes = rate * 1000/8; - ? ?burst_bytes = burst * 1000/8; + ? ?rate_bytes = rate * 1000ULL/8; + ? ?burst_bytes = burst * 1000ULL/8; ? ?? ? policer->app_srtcm_params.cir = rate_bytes; ?? ? policer->app_srtcm_params.cbs = burst_bytes; Regards, Lance Richardson > > Br, > > Wang Zhike > > _______________________________________________ > discuss mailing list > discuss at openvswitch.org > https://mail.openvswitch.org/mailman/listinfo/ovs-discuss > From dball at vmware.com Fri Aug 25 02:24:43 2017 From: dball at vmware.com (Darrell Ball) Date: Fri, 25 Aug 2017 02:24:43 +0000 Subject: [ovs-discuss] [ovs-dev] OVS+DPDK QoS rate limit issue Message-ID: Hi Ian Did you have any suggestions for this fix or is it ok as is ? Thanks Darrell On 8/24/17, 7:16 PM, "ovs-dev-bounces at openvswitch.org on behalf of ???" wrote: Hi Lance, Your patch works. Thanks. BR, Wang Zhike -----Original Message----- From: Lance Richardson [mailto:lrichard at redhat.com] Sent: Thursday, August 24, 2017 8:10 PM To: ??? Cc: ovs-dev at openvswitch.org; ovs-discuss at openvswitch.org Subject: Re: [ovs-discuss] OVS+DPDK QoS rate limit issue > From: "???" > To: ovs-dev at openvswitch.org, ovs-discuss at openvswitch.org > Sent: Wednesday, August 23, 2017 11:41:05 PM > Subject: [ovs-discuss] OVS+DPDK QoS rate limit issue > > > > Hi All, > > > > I am using OVS2.7.0 and DPDK 16.11, and testing rate limit function. > > > > I found that if the policing_rate is set very large, say 5Gbps, the rate is > limited dramatically to very low value, like 800Mbps. > > The command is as below: > > ovs-vsctl set interface port-7zel2so9sg ingress_policing_rate=5000000 > ingress_policing_burst=500000 > > > > If we set the rate lower than 4Gbps, the rate is limited correctly. > > > > Test setup: > > Sender (DPDK pktGen) sends out about 10Gbps udp packet, with size about 1420 > IP size. > > The rate limit is set on VM vhost-user-client port. > > > > Any idea about this issue? Is that known issue? > > It seems 32-bit arithmetic is being used when converting the rate from kilobits per second to bytes per second. Could you give this patch a try? diff --git a/lib/netdev-dpdk.c b/lib/netdev-dpdk.c index 1aaf6f7e2..d6ed2c7b0 100644 --- a/lib/netdev-dpdk.c +++ b/lib/netdev-dpdk.c @@ -2229,8 +2229,8 @@ netdev_dpdk_policer_construct(uint32_t rate, uint32_t burst) rte_spinlock_init(&policer->policer_lock); /* rte_meter requires bytes so convert kbits rate and burst to bytes. */ - rate_bytes = rate * 1000/8; - burst_bytes = burst * 1000/8; + rate_bytes = rate * 1000ULL/8; + burst_bytes = burst * 1000ULL/8; policer->app_srtcm_params.cir = rate_bytes; policer->app_srtcm_params.cbs = burst_bytes; Regards, Lance Richardson > > Br, > > Wang Zhike > > _______________________________________________ > discuss mailing list > discuss at openvswitch.org > https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.openvswitch.org_mailman_listinfo_ovs-2Ddiscuss&d=DwIGaQ&c=uilaK90D4TOVoH58JNXRgQ&r=BVhFA09CGX7JQ5Ih-uZnsw&m=uh9yIsPRl-Wg_mzYEUSGJQ8MIc8bQSMveIRvPzVhs3o&s=wFA4X4_UKYadj8wqKID9C9HTVu7B_oGv6QnzzZOjLRs&e= > _______________________________________________ dev mailing list dev at openvswitch.org https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.openvswitch.org_mailman_listinfo_ovs-2Ddev&d=DwIGaQ&c=uilaK90D4TOVoH58JNXRgQ&r=BVhFA09CGX7JQ5Ih-uZnsw&m=uh9yIsPRl-Wg_mzYEUSGJQ8MIc8bQSMveIRvPzVhs3o&s=SR-iNl6jVSY3oDZ9W-JMageFfsPuE9WBvXeCFV8filc&e= From WBAHACER at 126.com Fri Aug 25 08:30:31 2017 From: WBAHACER at 126.com (Furong) Date: Fri, 25 Aug 2017 16:30:31 +0800 Subject: [ovs-discuss] How to tune configurations for measuring zero packet-loss performance of OVS-DPDK with vhost-user? Message-ID: <184c3d50-66d1-8aa1-a5bc-59c6ee98e041@126.com> Hi! I've built a testbed to measure the zero packet-loss performance of OVS-DPDK with vhost-user. Here are the configurations of my testbed: 1. Host machine (ubuntu14.04.5, Linux-3.19.0-25): ??? a/? hardware: quad socket with Intel Xeon E5-4603v2 at 2.20GHz (4 cores/socket), 32GB DDR3 memory, dual-port Intel 82599ES NIC (10Gbps/port, in socket0); ??? b/? BIOS settings: disable power management options including C-state, P-state, Step Speedup and set cpu in performance mode; ??? c/? host OS booting parameters: isolcpus=0-7, nohz_full=0-7, rcu_nocbs=0-7, intel_iommu=on, iommu=pt and 16 x 1G hugepages ??? d/? OVS-DPDK: ??? ???? 1)? version: OVS-2.6.1, DPDK-16.07.2 (using x86_64-ivshmem-linuxapp-gcc target) ???????? 2)? configurations: 2 physical port (dpdk0 and dpdk1, vfio-pci dirver) and 2 vhost-user port (vhost0, vhost1) were added to ovs bridge (br0), and 1 PMD core (pinned to core 0, in socket0) was used for forwarding. The fowarding rules were "in_port=dpdk0,action=output:vhost0" and "in_port=vhost1,action=output:dpdk0". ???? e/ irq affinity: kill irqbalance and set smp_affinity of all irqs to 0xff00 (core 8-15). ???? f/? RT priority: change RT priority of ksoftirqd (chrt -fp 2 $tid), rcuos (chrt -fp 3 $tid) and rcuob (chrt -fp 2 $tid). 2. VM setting ???? a/ hypervisor: QEMU-2.8.0 and KVM ???? b/ QEMU command: qemu-system-x86_64 -enable-kvm -drive file=$IMAGE,if=virtio -cpu host -smp 3 -m 4G -boot c \ ???????????? -name $NAME -vnc :$VNC_INDEX? -net none \ ???????????? -object memory-backend-file,id=mem,size=4G,mem-path=/dev/hugepages,share=on \ ???????????? -mem-prealloc -numa node,memdev=mem \ ???????????? -chardev socket,id=char1,path=$VHOSTDIR/vhost0 \ ???????????? -netdev type=vhost-user,id=net1,chardev=char1,vhostforce \ ???????????? -device virtio-net-pci,netdev=net1,mac=52:54:00:00:00:14,csum=off,gso=off,guest_tso4=off,guest_tso6=off,guest_ecn=off,mrg_rxbuf=off,rx_queue_size=1024,indirect_desc=on \ ???????????? -chardev socket,id=char2,path=$VHOSTDIR/vhost1 \ ???????????? -netdev type=vhost-user,id=net2,chardev=char2,vhostforce \ ???????????? -device virtio-net-pci,netdev=net2,mac=52:54:00:00:00:15,csum=off,gso=off,guest_tso4=off,guest_tso6=off,guest_ecn=off,mrg_rxbuf=off,rx_queue_size=1024,indirect_desc=on ??? c/ Guest OS: ubuntu14.04 ??? d/ Guest OS booting parameters: isolcpus=0-1, nohz_full=0-1, rcu_nocbs=0-1, and 1 x 1G hugepages ??? e/ irq affinity and RT priority: remove irqs and change RT priority of isolated vcpus (vcpu0, vcpu1) ??? f/ Guest forwarding application: example/l2fwd build on dpdk-16.07.2 (using ivshmem target). The function of l2fwd is to forward packets from one port to another port, and each port has its' own polling thread to receive packets. ??? g/ App configurations: two virtio ports (vhost0, vhost1, using uio_pci_generic driver) were used by l2fwd, and l2fwd had 2 polling threads that ran on vcpu0 and vcpu1 (pinned to physical core1 and core2, in socket0). 3. Traffic generator ???? a/ Spirent TestCenter with 2 x 10G ports was used to generate traffic. ???? b/ 1 flow with 64B packet size was generated from one port and sent to dpdk0, and then receive and count packets at another port. Here are my results: 1. Max throughput (non zero packet-loss case): 2.03Gbps 2. Max throughput (zero packet-loss case): 100 ~ 200Mbps And I got some information about packet loss from packet statistics in OVS and l2fwd: When input traffic large than 200Mbps, there may were 3 packet loss point -- OVS rx from physical NIC (RX queue was full), OVS tx to vhost port (vhost rx queue was full) and l2fwd tx to vhost port (vhost tx queue was full). I don't know why the difference between above 2 cases is so large. I doubt that I've misconfigure my testbed. Could someone share experience with me ? Thanks a lot! -------------- next part -------------- An HTML attachment was scrubbed... URL: From WBAHACER at 126.com Fri Aug 25 08:30:31 2017 From: WBAHACER at 126.com (Furong) Date: Fri, 25 Aug 2017 16:30:31 +0800 Subject: [ovs-discuss] How to tune configurations for measuring zero packet-loss performance of OVS-DPDK with vhost-user? Message-ID: <184c3d50-66d1-8aa1-a5bc-59c6ee98e041@126.com> Hi! I've built a testbed to measure the zero packet-loss performance of OVS-DPDK with vhost-user. Here are the configurations of my testbed: 1. Host machine (ubuntu14.04.5, Linux-3.19.0-25): ??? a/? hardware: quad socket with Intel Xeon E5-4603v2 at 2.20GHz (4 cores/socket), 32GB DDR3 memory, dual-port Intel 82599ES NIC (10Gbps/port, in socket0); ??? b/? BIOS settings: disable power management options including C-state, P-state, Step Speedup and set cpu in performance mode; ??? c/? host OS booting parameters: isolcpus=0-7, nohz_full=0-7, rcu_nocbs=0-7, intel_iommu=on, iommu=pt and 16 x 1G hugepages ??? d/? OVS-DPDK: ??? ???? 1)? version: OVS-2.6.1, DPDK-16.07.2 (using x86_64-ivshmem-linuxapp-gcc target) ???????? 2)? configurations: 2 physical port (dpdk0 and dpdk1, vfio-pci dirver) and 2 vhost-user port (vhost0, vhost1) were added to ovs bridge (br0), and 1 PMD core (pinned to core 0, in socket0) was used for forwarding. The fowarding rules were "in_port=dpdk0,action=output:vhost0" and "in_port=vhost1,action=output:dpdk0". ???? e/ irq affinity: kill irqbalance and set smp_affinity of all irqs to 0xff00 (core 8-15). ???? f/? RT priority: change RT priority of ksoftirqd (chrt -fp 2 $tid), rcuos (chrt -fp 3 $tid) and rcuob (chrt -fp 2 $tid). 2. VM setting ???? a/ hypervisor: QEMU-2.8.0 and KVM ???? b/ QEMU command: qemu-system-x86_64 -enable-kvm -drive file=$IMAGE,if=virtio -cpu host -smp 3 -m 4G -boot c \ ???????????? -name $NAME -vnc :$VNC_INDEX? -net none \ ???????????? -object memory-backend-file,id=mem,size=4G,mem-path=/dev/hugepages,share=on \ ???????????? -mem-prealloc -numa node,memdev=mem \ ???????????? -chardev socket,id=char1,path=$VHOSTDIR/vhost0 \ ???????????? -netdev type=vhost-user,id=net1,chardev=char1,vhostforce \ ???????????? -device virtio-net-pci,netdev=net1,mac=52:54:00:00:00:14,csum=off,gso=off,guest_tso4=off,guest_tso6=off,guest_ecn=off,mrg_rxbuf=off,rx_queue_size=1024,indirect_desc=on \ ???????????? -chardev socket,id=char2,path=$VHOSTDIR/vhost1 \ ???????????? -netdev type=vhost-user,id=net2,chardev=char2,vhostforce \ ???????????? -device virtio-net-pci,netdev=net2,mac=52:54:00:00:00:15,csum=off,gso=off,guest_tso4=off,guest_tso6=off,guest_ecn=off,mrg_rxbuf=off,rx_queue_size=1024,indirect_desc=on ??? c/ Guest OS: ubuntu14.04 ??? d/ Guest OS booting parameters: isolcpus=0-1, nohz_full=0-1, rcu_nocbs=0-1, and 1 x 1G hugepages ??? e/ irq affinity and RT priority: remove irqs and change RT priority of isolated vcpus (vcpu0, vcpu1) ??? f/ Guest forwarding application: example/l2fwd build on dpdk-16.07.2 (using ivshmem target). The function of l2fwd is to forward packets from one port to another port, and each port has its' own polling thread to receive packets. ??? g/ App configurations: two virtio ports (vhost0, vhost1, using uio_pci_generic driver) were used by l2fwd, and l2fwd had 2 polling threads that ran on vcpu0 and vcpu1 (pinned to physical core1 and core2, in socket0). 3. Traffic generator ???? a/ Spirent TestCenter with 2 x 10G ports was used to generate traffic. ???? b/ 1 flow with 64B packet size was generated from one port and sent to dpdk0, and then receive and count packets at another port. Here are my results: 1. Max throughput (non zero packet-loss case): 2.03Gbps 2. Max throughput (zero packet-loss case): 100 ~ 200Mbps And I got some information about packet loss from packet statistics in OVS and l2fwd: When input traffic large than 200Mbps, there may were 3 packet loss point -- OVS rx from physical NIC (RX queue was full), OVS tx to vhost port (vhost rx queue was full) and l2fwd tx to vhost port (vhost tx queue was full). I don't know why the difference between above 2 cases is so large. I doubt that I've misconfigure my testbed. Could someone share experience with me ? Thanks a lot! -------------- next part -------------- An HTML attachment was scrubbed... URL: From ciara.loftus at intel.com Fri Aug 25 11:22:54 2017 From: ciara.loftus at intel.com (Loftus, Ciara) Date: Fri, 25 Aug 2017 11:22:54 +0000 Subject: [ovs-discuss] How to enable zero-copy feature of vhost-user ?? In-Reply-To: <0594a73a-0d8f-21f9-2623-fb8329207acb@lab.ntt.co.jp> References: <827d030b-0f04-e0bf-53a4-192ae177857e@lab.ntt.co.jp> <74F120C019F4A64C9B78E802F6AD4CC278DCE61B@IRSMSX106.ger.corp.intel.com> <74F120C019F4A64C9B78E802F6AD4CC278DCE716@IRSMSX106.ger.corp.intel.com> <0594a73a-0d8f-21f9-2623-fb8329207acb@lab.ntt.co.jp> Message-ID: <74F120C019F4A64C9B78E802F6AD4CC278DFB7D6@IRSMSX106.ger.corp.intel.com> > Hi Ciara, > > Now it's all clear. > It would be great if the patch is applied. Hi Tetsuro, I submitted a patch that enables the zero copy feature during runtime, if you are interested: https://patchwork.ozlabs.org/patch/805844/ https://patchwork.ozlabs.org/patch/805845/ If you try it out, let me know how you get on. Thanks, Ciara > > Thank you, > > Tetsuro > > On 2017/08/02 18:12, Loftus, Ciara wrote: > >> > >> Hi Ciara, > >> > >> Thank you for the infomation. > >> IIUC, you should compile ovs again to use zero copy feature so far, right ? > > > > Hi Tetsuro, > > > > That's right. I might look into creating a patch to enable it during runtime. > But for now, you need to apply the patch below & recompile. > > > > Thanks, > > Ciara > > > >> > >> On 2017/08/02 17:04, Loftus, Ciara wrote: > >>>> > >>>> Hi, > >>>> > >>>> I heard that, about vhost-user interface, > >>>> 0 copy rx is under development, > >>>> but 0 copy tx from a vm is already supported with both vhost-user and > >>>> ovs-dpdk. > >>>> > >>>> However, I couldn't find out how to enable that zero copy feature from > >>>> the ovs document (/ovs/Documentation/topics/dpdk/vhost-user.rst) > >>>> > >>>> Could you inform me how to enable it or where I should refer about > the > >>>> feature ? > >>> > >>> Try this: > >>> > >>> diff --git a/lib/netdev-dpdk.c b/lib/netdev-dpdk.c > >>> index ea17b97..9fdae46 100644 > >>> --- a/lib/netdev-dpdk.c > >>> +++ b/lib/netdev-dpdk.c > >>> @@ -944,6 +944,7 @@ netdev_dpdk_vhost_construct(struct netdev > >> *netdev) > >>> dpdk_get_vhost_sock_dir(), name); > >>> > >>> dev->vhost_driver_flags &= ~RTE_VHOST_USER_CLIENT; > >>> + dev->vhost_driver_flags |= > RTE_VHOST_USER_DEQUEUE_ZERO_COPY; > >>> err = rte_vhost_driver_register(dev->vhost_id, dev- > >>> vhost_driver_flags); > >>> if (err) { > >>> VLOG_ERR("vhost-user socket device setup failure for socket > %s\n", > >>> > >>> Thanks, > >>> Ciara > >>> > >>>> > >>>> Thanks > >>>> > >>>> -- > >>>> Tetsuro Nakamura > >>>> > >>>> _______________________________________________ > >>>> discuss mailing list > >>>> discuss at openvswitch.org > >>>> https://mail.openvswitch.org/mailman/listinfo/ovs-discuss > >>> > >>> > >> > >> -- > >> Tetsuro Nakamura > >> NTT Network Service Systems Laboratories > >> TEL:0422 59 6914(National)/+81 422 59 6914(International) > >> 3-9-11, Midori-Cho Musashino-Shi, Tokyo 180-8585 Japan > >> > > > > -- > Tetsuro Nakamura > NTT Network Service Systems Laboratories > TEL:0422 59 6914(National)/+81 422 59 6914(International) > 3-9-11, Midori-Cho Musashino-Shi, Tokyo 180-8585 Japan > From rahul.kenu at gmail.com Sat Aug 26 10:08:00 2017 From: rahul.kenu at gmail.com (Rahul Sharma) Date: Sat, 26 Aug 2017 15:38:00 +0530 Subject: [ovs-discuss] Deadlock while adding a new action Message-ID: Hello, I have been trying to add two new actions which when matched send port_statistics and flow statistics to the controller when a matching packet is received. The port statistics action is working but the flow_statistics action is causing a deadlock which I am trying to figure out how to avoid. The deadlock occurs when the controller sends a matching packet in the packet out message. The functions handle_flow_stats_request() and handle_packet_out() in ofproto/ofproti.c both acquire a lock on the mutex ofproto_mutex. Can someone suggest how I could proceed? -- Regards, *Rahul Sharma* 5th YearMaster of Science (Hons), PhysicsBachelor of Engineering (Hons), Computer Science *????????????????????????????????????????????????????????* *Birla Institute of Technology & Science,* *Pilani* Pilani Campus, Vidhya Vihar, Pilani, Rajasthan - 333 031, INDIA. ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From twinwings1111 at gmail.com Sun Aug 27 12:03:27 2017 From: twinwings1111 at gmail.com (young-bo Sim) Date: Sun, 27 Aug 2017 21:03:27 +0900 Subject: [ovs-discuss] Adding new column in ovsschema causes errors in auto test. Message-ID: Hello. I tried to add new column "mfr_desc", so I edited "vswitchd/vswitch.ovsschema" file like this: {"name": "Open_vSwitch", > "version": "7.15.2", > "cksum": "4239863904 23657", > "tables": { > "Bridge": { > "columns": { > "mfr_desc": { > "type": "string"}, And I tried test, using $ make check TESTSUITEFLAGS='-k ovs-vsctl', I got error messages. Acctually, I relsoved these 2 TCs, by eddting TCs. ovs-vsctl unit tests -- database commands > > 2188: database commands -- positive checks FAILED ( > ovs-vsctl.at:657) > 2195: created row UUID is wrong in same execution FAILED ( > ovs-vsctl.at:1161) > But these errors, I couldn't. ovs-vsctl unit tests -- fake bridges (VLAN 9) > > 2174: simple fake bridge (VLAN 9) FAILED ( > ovs-vsctl.at:570) > 2175: list bridges -- real and fake (VLAN 9) FAILED ( > ovs-vsctl.at:570) > 2176: simple fake bridge + del-br fake bridge (VLAN 9) FAILED ( > ovs-vsctl.at:570) > 2177: simple fake bridge + del-br real bridge (VLAN 9) FAILED ( > ovs-vsctl.at:570) > 2178: simple fake bridge + external IDs (VLAN 9) FAILED ( > ovs-vsctl.at:570) > > ovs-vsctl unit tests -- fake bridges (VLAN 0) > > 2179: simple fake bridge (VLAN 0) FAILED ( > ovs-vsctl.at:571) > 2180: list bridges -- real and fake (VLAN 0) FAILED ( > ovs-vsctl.at:571) > 2181: simple fake bridge + del-br fake bridge (VLAN 0) FAILED ( > ovs-vsctl.at:571) > 2182: simple fake bridge + del-br real bridge (VLAN 0) FAILED ( > ovs-vsctl.at:571) > 2183: simple fake bridge + external IDs (VLAN 0) FAILED ( > ovs-vsctl.at:571) > 2184: fake bridge on bond FAILED ( > ovs-vsctl.at:587) > 2185: fake bridge on bond + del-br fake bridge FAILED ( > ovs-vsctl.at:599) > 2186: fake bridge on bond + del-br real bridge FAILED ( > ovs-vsctl.at:611) > How can I resolve this error messages? If there is anyone who knows how to resolve, please let me know. Thank you. -- Sim Young-Bo -------------- next part -------------- An HTML attachment was scrubbed... URL: From jesus.llorente at gmail.com Sun Aug 27 19:29:39 2017 From: jesus.llorente at gmail.com (Jesus Llorente) Date: Sun, 27 Aug 2017 22:29:39 +0300 Subject: [ovs-discuss] Tunnel port not processing incoming packets when skb->mark value is set Message-ID: Hi, I have found a problem related to OpenvSwitch 2.5.x versions. However, the issue does not appear in the 2.7.x series. When using VXLAN and/or GRE tunneling ports at the bridge, the incoming packets are not processed by the switch if they skb has been previously marked with a value != 0. The mark can be set with iptables in any of the traversed chains. I have created a topology to reproduce the issue, it uses network namespaces and 2 bridges connected with VXLAN tunneling via the loopback interface. If the MARKing rule is removed from the iptables, the communication resumes successfully. Steps to reproduce: ``` ## Create supporting virtual network setup sudo ip netns add ns0 sudo ip netns add ns1 sudo ip link add test0 type veth peer name test0s sudo ip link add test1 type veth peer name test1s sudo ip link set dev test0 netns ns0 sudo ip link set dev test1 netns ns1 sudo ip netns exec ns0 ip link set dev lo up sudo ip netns exec ns0 ip link set dev test0 up sudo ip netns exec ns0 ip address add dev test0 1.1.1.1/24 sudo ip netns exec ns1 ip link set dev lo up sudo ip netns exec ns1 ip link set dev test1 up sudo ip netns exec ns1 ip address add dev test1 1.1.1.2/24 ## Create OVS bridges sudo ovs-vsctl add-br br0 sudo ovs-vsctl add-br br1 sudo ovs-vsctl add-port br0 test0s sudo ovs-vsctl add-port br1 test1s sudo ip link set dev test0s up sudo ip link set dev test1s up ## Create 2 OVS tunnel ports, and assign OpenFlow port 100 sudo ovs-vsctl del-port br0 tun0 sudo ovs-vsctl del-port br1 tun1 sudo ovs-vsctl add-port br0 tun0 -- set interface tun0 ofport_request=100 -- set interface tun0 type=vxlan options:key=flow options:remote_ip=127.0.0.2 options:local_ip=127.0.0.1 sudo ovs-vsctl add-port br1 tun1 -- set interface tun1 ofport_request=100 -- set interface tun1 type=vxlan options:key=flow options:remote_ip=127.0.0.1 options:local_ip=127.0.0.2 ## Add marking rule to iptables sudo iptables -t mangle -A OUTPUT -p udp --dport 4789 -d 127.0.0.2 -j MARK --set-mark 0xabcdef ### When this rule matches it indicates the skb is not scrubbed when forwarding via loopback sudo iptables -t mangle -A PREROUTING -p udp --dport 4789 -d 127.0.0.2 -m mark --mark 0xabcdef # Ping from ns0 to ns1 - This fails unless the MARKing rule is removed sudo ip netns exec ns0 ping 1.1.1.2 ``` Please let me know if you need further information! Best, Jesus -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.burton at speakeasy.net Mon Aug 28 06:52:51 2017 From: chris.burton at speakeasy.net (Chris Burton) Date: Sun, 27 Aug 2017 23:52:51 -0700 Subject: [ovs-discuss] OVS Router Port Status Message-ID: <27142831-e602-6ca4-8bbc-470e28f80108@speakeasy.net> What is the process or dependencies by which OVN determines a logical routers interface(s) to be in a "ACTIVE" or "DOWN" state and notify Neutron of that status upstream? I read https://docs.openstack.org/networking-ovn/ocata/design/ovn_worker.html document, but it seems to refer to virtual machines that are created/destroyed and I am unsure if the same applies to logical routers. I have seen now on several occasions where OVN will report a network port as down for no reason then up then back down similar to a traditional network link flap, but ultimately the port remains in a down state (example below) and can find now way to bring the port online. In troubleshooting this issue I can find/see no obvious errors in the logs for OVS, OVN, or Neutron, and this does not occur with instance ports, all of the patch ports on the compute node appear to be in place, and the integration bridge (br-int) is up and running (two instances on the same subnet are able to communicate). This is on Ocata release, CentOS 7, OVS/OVN 2.6.1 from package not source. cat /var/log/neutron/server.log | grep "networking_ovn.ml2.mech_driver" | awk '{ print $1=$2=""; print $0}' 5393 INFO networking_ovn.ml2.mech_driver [req-d4aa53c5-b78e-4360-9c9e-194f76cdb15c - - - - -] Starting OVNMechanismDriver 5416 INFO networking_ovn.ml2.mech_driver [-] OVN reports status up for port: 90b16a19-11d9-4844-8fbe-2340367f18d5 5416 INFO networking_ovn.ml2.mech_driver [req-347dbab3-4326-4a0d-b77c-eccc5532bee1 - - - - -] OVN reports status down for port: 90b16a19-11d9-4844-8fbe-2340367f18d5 5416 INFO networking_ovn.ml2.mech_driver [req-347dbab3-4326-4a0d-b77c-eccc5532bee1 - - - - -] OVN reports status up for port: 90b16a19-11d9-4844-8fbe-2340367f18d5 5416 INFO networking_ovn.ml2.mech_driver [req-347dbab3-4326-4a0d-b77c-eccc5532bee1 - - - - -] OVN reports status down for port: 90b16a19-11d9-4844-8fbe-2340367f18d55 openstack port list +--------------------------------------+------+-------------------+----------------------------------------------------------------------------+--------+ | ID | Name | MAC Address | Fixed IP Addresses | Status | +--------------------------------------+------+-------------------+----------------------------------------------------------------------------+--------+ | 90b16a19-11d9-4844-8fbe-2340367f18d5 | | fa:16:3e:b6:bd:29 | ip_address='172.18.0.1', subnet_id='8bfc9808-ba56-49ce-b308-ed6d7f1c6701' | DOWN | +--------------------------------------+------+-------------------+----------------------------------------------------------------------------+--------+ openstack router list +--------------------------------------+-------------------+--------+-------+-------------+-------+----------------------------------+ | ID | Name | Status | State | Distributed | HA | Project | +--------------------------------------+-------------------+--------+-------+-------------+-------+----------------------------------+ | e2b7766b-2121-4874-babe-080f6ef8ad84 | router-internal-1 | ACTIVE | UP | False | False | 6cde3f9359c84acdb6ae916d438045bf | +--------------------------------------+-------------------+--------+-------+-------------+-------+----------------------------------+ Cheers, -C From nusiddiq at redhat.com Mon Aug 28 09:20:41 2017 From: nusiddiq at redhat.com (Numan Siddique) Date: Mon, 28 Aug 2017 14:50:41 +0530 Subject: [ovs-discuss] OVS Router Port Status In-Reply-To: <27142831-e602-6ca4-8bbc-470e28f80108@speakeasy.net> References: <27142831-e602-6ca4-8bbc-470e28f80108@speakeasy.net> Message-ID: On Mon, Aug 28, 2017 at 12:22 PM, Chris Burton wrote: > What is the process or dependencies by which OVN determines a logical > routers interface(s) to be in a "ACTIVE" or "DOWN" state and notify Neutron > of that status upstream? I read https://docs.openstack.org/net > working-ovn/ocata/design/ovn_worker.html document, but it seems to refer > to virtual machines that are created/destroyed and I am unsure if the same > applies to logical routers. I have seen now on several occasions where OVN > will report a network port as down for no reason then up then back down > similar to a traditional network link flap, but ultimately the port remains > in a down state (example below) and can find now way to bring the port > online. > I don't think ovn-northd presently sets the status to active for logical router interfaces (i.e logical switch ports of type router). Do you think it should set to active ? If its a major issue, I think it can be addressed. Thanks Numan > In troubleshooting this issue I can find/see no obvious errors in the logs > for OVS, OVN, or Neutron, and this does not occur with instance ports, all > of the patch ports on the compute node appear to be in place, and the > integration bridge (br-int) is up and running (two instances on the same > subnet are able to communicate). This is on Ocata release, CentOS 7, > OVS/OVN 2.6.1 from package not source. > > cat /var/log/neutron/server.log | grep "networking_ovn.ml2.mech_driver" | > awk '{ print $1=$2=""; print $0}' > 5393 INFO networking_ovn.ml2.mech_driver [req-d4aa53c5-b78e-4360-9c9e-194f76cdb15c > - - - - -] Starting OVNMechanismDriver > 5416 INFO networking_ovn.ml2.mech_driver [-] OVN reports status up for > port: 90b16a19-11d9-4844-8fbe-2340367f18d5 > 5416 INFO networking_ovn.ml2.mech_driver [req-347dbab3-4326-4a0d-b77c-eccc5532bee1 > - - - - -] OVN reports status down for port: 90b16a19-11d9-4844-8fbe-234036 > 7f18d5 > 5416 INFO networking_ovn.ml2.mech_driver [req-347dbab3-4326-4a0d-b77c-eccc5532bee1 > - - - - -] OVN reports status up for port: 90b16a19-11d9-4844-8fbe-234036 > 7f18d5 > 5416 INFO networking_ovn.ml2.mech_driver [req-347dbab3-4326-4a0d-b77c-eccc5532bee1 > - - - - -] OVN reports status down for port: 90b16a19-11d9-4844-8fbe-234036 > 7f18d55 > > openstack port list > +--------------------------------------+------+------------- > ------+----------------------------------------------------- > -----------------------+--------+ > | ID | Name | MAC Address | Fixed > IP Addresses | > Status | > +--------------------------------------+------+------------- > ------+----------------------------------------------------- > -----------------------+--------+ > | 90b16a19-11d9-4844-8fbe-2340367f18d5 | | fa:16:3e:b6:bd:29 | > ip_address='172.18.0.1', subnet_id='8bfc9808-ba56-49ce-b308-ed6d7f1c6701' > | DOWN | > +--------------------------------------+------+------------- > ------+----------------------------------------------------- > -----------------------+--------+ > > openstack router list > +--------------------------------------+-------------------+ > --------+-------+-------------+-------+----------------------------------+ > | ID | Name | Status | > State | Distributed | HA | Project | > +--------------------------------------+-------------------+ > --------+-------+-------------+-------+----------------------------------+ > | e2b7766b-2121-4874-babe-080f6ef8ad84 | router-internal-1 | ACTIVE | UP > | False | False | 6cde3f9359c84acdb6ae916d438045bf | > +--------------------------------------+-------------------+ > --------+-------+-------------+-------+----------------------------------+ > > Cheers, > > -C > _______________________________________________ > discuss mailing list > discuss at openvswitch.org > https://mail.openvswitch.org/mailman/listinfo/ovs-discuss > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nusrat at attaresources.com Mon Aug 28 14:12:08 2017 From: nusrat at attaresources.com (Nusrat Atta) Date: Mon, 28 Aug 2017 09:12:08 -0500 Subject: [ovs-discuss] ovs infrastructure deployment question Message-ID: <59a424b7.05bdca0a.f8b80.2011@mx.google.com> Hi, I am getting confused on how OVS is supposed to be deployed. I am using VMware ESXi to provision VMs. I have a portgroup OVS_10.0.0.x that has no uplinks (i.e. not connected physically to any ports) and all of my VMs are on this network. So I created a couple of VMs (e.g. ovsvm1, ovsvm2, ovswebserver, vswitch). I installed the OVS 2.7.2 on my vswitch machine and created a bridge and attached the single eth0 port to the bridge. So I also gave my vswitch VM, the ip of 10.0.0.1, gateway=10.0.0.1, dns=10.0.0.1 and created static ips on all the other VMs (e.g. ovsvm1 ip = 10.0.0.10, gateway=10.0.0.1, dns=10.0.0.1), I did similar for all the other machines with everyone pointing their gateway and dns to the vswitch machine. Because it is in a mac learning mode, I can now ping every machine with out any problems. Is this the way it is supposed to be deployed? Because I only have one physical port on the vswitch VM I cant seem to do add-flows of simple actions like: ovs-ofctl add-flow mybridge priority=500,in_port=1,actions=output:2 ovs-ofctl add-flow mybridge priority=500,in_port=2,actions=output:1 How do you I accomplish ports? The vswitch VM is supposed to act like a physical switch with many ports. Do I need to install ovs on each VM? Even then I don?t know how that will help. Any guidance, tutorials, urls, etc. would be appreciated. I have been reading up a ton on this, but a nudge in the right direction will help. Thanks in advance Nuz Sent from Mail for Windows 10 -------------- next part -------------- An HTML attachment was scrubbed... URL: From nusrat at attaresources.com Mon Aug 28 14:13:11 2017 From: nusrat at attaresources.com (Nusrat Atta) Date: Mon, 28 Aug 2017 09:13:11 -0500 Subject: [ovs-discuss] OVN + OVS question Message-ID: <59a424f5.8335ca0a.b061f.1f27@mx.google.com> Hi, I successfully deployed OVS by compiling it and it works fine. All commands like ovs- work but the ovn- commands don?t work. Any help? Thanks Nuz Sent from Mail for Windows 10 -------------- next part -------------- An HTML attachment was scrubbed... URL: From scott.lowe at scottlowe.org Mon Aug 28 14:34:16 2017 From: scott.lowe at scottlowe.org (Scott Lowe) Date: Mon, 28 Aug 2017 07:34:16 -0700 Subject: [ovs-discuss] ovs infrastructure deployment question In-Reply-To: <59a424b7.05bdca0a.f8b80.2011@mx.google.com> References: <59a424b7.05bdca0a.f8b80.2011@mx.google.com> Message-ID: <9625F6FE-95A9-450F-B9DD-C5D1FFF1189D@scottlowe.org> When you're running this sort of configuration (OVS in a VM on top of another hypervisor), your best bet (IMHO) is to run each "guest" VM on a different VLAN, then trunk all those VLANs into the OVS VM and write your rules accordingly. -- Scott Sent from my mobile device > On Aug 28, 2017, at 7:12 AM, Nusrat Atta wrote: > > Hi, > I am getting confused on how OVS is supposed to be deployed. I am using VMware ESXi to provision VMs. I have a portgroup OVS_10.0.0.x that has no uplinks (i.e. not connected physically to any ports) and all of my VMs are on this network. > So I created a couple of VMs (e.g. ovsvm1, ovsvm2, ovswebserver, vswitch). I installed the OVS 2.7.2 on my vswitch machine and created a bridge and attached the single eth0 port to the bridge. So I also gave my vswitch VM, the ip of 10.0.0.1, gateway=10.0.0.1, dns=10.0.0.1 and created static ips on all the other VMs (e.g. ovsvm1 ip = 10.0.0.10, gateway=10.0.0.1, dns=10.0.0.1), I did similar for all the other machines with everyone pointing their gateway and dns to the vswitch machine. Because it is in a mac learning mode, I can now ping every machine with out any problems. > > Is this the way it is supposed to be deployed? Because I only have one physical port on the vswitch VM I cant seem to do add-flows of simple actions like: > > ovs-ofctl add-flow mybridge priority=500,in_port=1,actions=output:2 > ovs-ofctl add-flow mybridge priority=500,in_port=2,actions=output:1 > > How do you I accomplish ports? The vswitch VM is supposed to act like a physical switch with many ports. > > Do I need to install ovs on each VM? Even then I don?t know how that will help. > > Any guidance, tutorials, urls, etc. would be appreciated. I have been reading up a ton on this, but a nudge in the right direction will help. > > Thanks in advance > Nuz > > Sent from Mail for Windows 10 > > _______________________________________________ > discuss mailing list > discuss at openvswitch.org > https://mail.openvswitch.org/mailman/listinfo/ovs-discuss -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.burton at speakeasy.net Mon Aug 28 19:30:07 2017 From: chris.burton at speakeasy.net (Chris Burton) Date: Mon, 28 Aug 2017 12:30:07 -0700 Subject: [ovs-discuss] OVS Router Port Status In-Reply-To: References: <27142831-e602-6ca4-8bbc-470e28f80108@speakeasy.net> Message-ID: Numan, If I am following your comment correctly and this is just a lack of status messaging that does not prevent the gateway from becoming active (i.e. it still works) then my issues are elsewhere as currently it does not work and I will need to investigate further. That being said I believe the ovn-northd should communicate properly communicate status up the chain otherwise it could cause confusion in normal operations as that is the place most people are likely to check first in a Openstack CMS deployment, though that may not be the case for other CMS deployments. I would not necessarily classify it as a major issue though as long as it is called out in documentation unless it is corrected. I will be happy to open a bug on this for tracking once I figure out my actual issue if that would help. Cheers, -C On 08/28/2017 02:20 AM, Numan Siddique wrote: > > > On Mon, Aug 28, 2017 at 12:22 PM, Chris Burton > > wrote: > > What is the process or dependencies by which OVN determines a > logical routers interface(s) to be in a "ACTIVE" or "DOWN" state > and notify Neutron of that status upstream? I read > https://docs.openstack.org/networking-ovn/ocata/design/ovn_worker.html > > document, but it seems to refer to virtual machines that are > created/destroyed and I am unsure if the same applies to logical > routers. I have seen now on several occasions where OVN will > report a network port as down for no reason then up then back down > similar to a traditional network link flap, but ultimately the > port remains in a down state (example below) and can find now way > to bring the port online. > > > I don't think ovn-northd presently sets the status to active for > logical router interfaces (i.e logical switch ports of type router). > > Do you think it should set to active ? If its a major issue, I think > it can be addressed. > > Thanks > Numan > > > > In troubleshooting this issue I can find/see no obvious errors in > the logs for OVS, OVN, or Neutron, and this does not occur with > instance ports, all of the patch ports on the compute node appear > to be in place, and the integration bridge (br-int) is up and > running (two instances on the same subnet are able to > communicate). This is on Ocata release, CentOS 7, OVS/OVN 2.6.1 > from package not source. > > cat /var/log/neutron/server.log | grep > "networking_ovn.ml2.mech_driver" | awk '{ print $1=$2=""; print $0}' > 5393 INFO networking_ovn.ml2.mech_driver > [req-d4aa53c5-b78e-4360-9c9e-194f76cdb15c - - - - -] Starting > OVNMechanismDriver > 5416 INFO networking_ovn.ml2.mech_driver [-] OVN reports status up > for port: 90b16a19-11d9-4844-8fbe-2340367f18d5 > 5416 INFO networking_ovn.ml2.mech_driver > [req-347dbab3-4326-4a0d-b77c-eccc5532bee1 - - - - -] OVN reports > status down for port: 90b16a19-11d9-4844-8fbe-2340367f18d5 > 5416 INFO networking_ovn.ml2.mech_driver > [req-347dbab3-4326-4a0d-b77c-eccc5532bee1 - - - - -] OVN reports > status up for port: 90b16a19-11d9-4844-8fbe-2340367f18d5 > 5416 INFO networking_ovn.ml2.mech_driver > [req-347dbab3-4326-4a0d-b77c-eccc5532bee1 - - - - -] OVN reports > status down for port: 90b16a19-11d9-4844-8fbe-2340367f18d55 > > openstack port list > +--------------------------------------+------+-------------------+----------------------------------------------------------------------------+--------+ > | ID | Name | MAC Address > | Fixed IP Addresses | Status | > +--------------------------------------+------+-------------------+----------------------------------------------------------------------------+--------+ > | 90b16a19-11d9-4844-8fbe-2340367f18d5 | | fa:16:3e:b6:bd:29 > | ip_address='172.18.0.1', > subnet_id='8bfc9808-ba56-49ce-b308-ed6d7f1c6701' | DOWN | > +--------------------------------------+------+-------------------+----------------------------------------------------------------------------+--------+ > > openstack router list > +--------------------------------------+-------------------+--------+-------+-------------+-------+----------------------------------+ > | ID | Name | Status | State | > Distributed | HA | Project | > +--------------------------------------+-------------------+--------+-------+-------------+-------+----------------------------------+ > | e2b7766b-2121-4874-babe-080f6ef8ad84 | router-internal-1 | > ACTIVE | UP | False | False | > 6cde3f9359c84acdb6ae916d438045bf | > +--------------------------------------+-------------------+--------+-------+-------------+-------+----------------------------------+ > > Cheers, > > -C > _______________________________________________ > discuss mailing list > discuss at openvswitch.org > https://mail.openvswitch.org/mailman/listinfo/ovs-discuss > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nusiddiq at redhat.com Tue Aug 29 07:46:57 2017 From: nusiddiq at redhat.com (Numan Siddique) Date: Tue, 29 Aug 2017 13:16:57 +0530 Subject: [ovs-discuss] OVS Router Port Status In-Reply-To: References: <27142831-e602-6ca4-8bbc-470e28f80108@speakeasy.net> Message-ID: On Tue, Aug 29, 2017 at 1:00 AM, Chris Burton wrote: > Numan, > > If I am following your comment correctly and this is just a lack of status > messaging that does not prevent the gateway from becoming active (i.e. it > still works) then my issues are elsewhere as currently it does not work and > I will need to investigate further. > > That being said I believe the ovn-northd should communicate properly > communicate status up the chain otherwise it could cause confusion in > normal operations as that is the place most people are likely to check > first in a Openstack CMS deployment, though that may not be the case for > other CMS deployments. I would not necessarily classify it as a major > issue though as long as it is called out in documentation unless it is > corrected. I will be happy to open a bug on this for tracking once I > figure out my actual issue if that would help. > > I will look into supporting this in OVN. For ovs/ovn, there is no bug reporting tool. This email is good enough I suppose to track. You can open a bug in networking-ovn to track it if you want. I think, networking-ovn should be able to set the port to ACTIVE when it sees Logical_Switch_Port.status to "up" for the router port. Thanks Numan > Cheers, > > -C > > > On 08/28/2017 02:20 AM, Numan Siddique wrote: > > > > On Mon, Aug 28, 2017 at 12:22 PM, Chris Burton > wrote: > >> What is the process or dependencies by which OVN determines a logical >> routers interface(s) to be in a "ACTIVE" or "DOWN" state and notify Neutron >> of that status upstream? I read https://docs.openstack.org/net >> working-ovn/ocata/design/ovn_worker.html document, but it seems to refer >> to virtual machines that are created/destroyed and I am unsure if the same >> applies to logical routers. I have seen now on several occasions where OVN >> will report a network port as down for no reason then up then back down >> similar to a traditional network link flap, but ultimately the port remains >> in a down state (example below) and can find now way to bring the port >> online. >> > > I don't think ovn-northd presently sets the status to active for logical > router interfaces (i.e logical switch ports of type router). > > Do you think it should set to active ? If its a major issue, I think it > can be addressed. > > Thanks > Numan > > > >> In troubleshooting this issue I can find/see no obvious errors in the >> logs for OVS, OVN, or Neutron, and this does not occur with instance ports, >> all of the patch ports on the compute node appear to be in place, and the >> integration bridge (br-int) is up and running (two instances on the same >> subnet are able to communicate). This is on Ocata release, CentOS 7, >> OVS/OVN 2.6.1 from package not source. >> >> cat /var/log/neutron/server.log | grep "networking_ovn.ml2.mech_driver" >> | awk '{ print $1=$2=""; print $0}' >> 5393 INFO networking_ovn.ml2.mech_driver [req-d4aa53c5-b78e-4360-9c9e-194f76cdb15c >> - - - - -] Starting OVNMechanismDriver >> 5416 INFO networking_ovn.ml2.mech_driver [-] OVN reports status up for >> port: 90b16a19-11d9-4844-8fbe-2340367f18d5 >> 5416 INFO networking_ovn.ml2.mech_driver [req-347dbab3-4326-4a0d-b77c-eccc5532bee1 >> - - - - -] OVN reports status down for port: 90b16a19-11d9-4844-8fbe-234036 >> 7f18d5 >> 5416 INFO networking_ovn.ml2.mech_driver [req-347dbab3-4326-4a0d-b77c-eccc5532bee1 >> - - - - -] OVN reports status up for port: 90b16a19-11d9-4844-8fbe-234036 >> 7f18d5 >> 5416 INFO networking_ovn.ml2.mech_driver [req-347dbab3-4326-4a0d-b77c-eccc5532bee1 >> - - - - -] OVN reports status down for port: 90b16a19-11d9-4844-8fbe-234036 >> 7f18d55 >> >> openstack port list >> +--------------------------------------+------+------------- >> ------+----------------------------------------------------- >> -----------------------+--------+ >> | ID | Name | MAC Address | Fixed >> IP Addresses | >> Status | >> +--------------------------------------+------+------------- >> ------+----------------------------------------------------- >> -----------------------+--------+ >> | 90b16a19-11d9-4844-8fbe-2340367f18d5 | | fa:16:3e:b6:bd:29 | >> ip_address='172.18.0.1', subnet_id='8bfc9808-ba56-49ce-b308-ed6d7f1c6701' >> | DOWN | >> +--------------------------------------+------+------------- >> ------+----------------------------------------------------- >> -----------------------+--------+ >> >> openstack router list >> +--------------------------------------+-------------------+ >> --------+-------+-------------+-------+--------------------- >> -------------+ >> | ID | Name | Status | >> State | Distributed | HA | Project | >> +--------------------------------------+-------------------+ >> --------+-------+-------------+-------+--------------------- >> -------------+ >> | e2b7766b-2121-4874-babe-080f6ef8ad84 | router-internal-1 | ACTIVE | >> UP | False | False | 6cde3f9359c84acdb6ae916d438045bf | >> +--------------------------------------+-------------------+ >> --------+-------+-------------+-------+--------------------- >> -------------+ >> >> Cheers, >> >> -C >> _______________________________________________ >> discuss mailing list >> discuss at openvswitch.org >> https://mail.openvswitch.org/mailman/listinfo/ovs-discuss >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nakamura.tetsuro at lab.ntt.co.jp Tue Aug 29 09:40:32 2017 From: nakamura.tetsuro at lab.ntt.co.jp (TETSURO NAKAMURA) Date: Tue, 29 Aug 2017 18:40:32 +0900 Subject: [ovs-discuss] How to enable zero-copy feature of vhost-user ?? In-Reply-To: <74F120C019F4A64C9B78E802F6AD4CC278DFB7D6@IRSMSX106.ger.corp.intel.com> References: <827d030b-0f04-e0bf-53a4-192ae177857e@lab.ntt.co.jp> <74F120C019F4A64C9B78E802F6AD4CC278DCE61B@IRSMSX106.ger.corp.intel.com> <74F120C019F4A64C9B78E802F6AD4CC278DCE716@IRSMSX106.ger.corp.intel.com> <0594a73a-0d8f-21f9-2623-fb8329207acb@lab.ntt.co.jp> <74F120C019F4A64C9B78E802F6AD4CC278DFB7D6@IRSMSX106.ger.corp.intel.com> Message-ID: <6ab27159-3fb6-40ad-f575-b7f0b1f857e2@lab.ntt.co.jp> On 2017/08/25 20:22, Loftus, Ciara wrote: >> Hi Ciara, >> >> Now it's all clear. >> It would be great if the patch is applied. > > Hi Tetsuro, > > I submitted a patch that enables the zero copy feature during runtime, if you are interested: > https://patchwork.ozlabs.org/patch/805844/ > https://patchwork.ozlabs.org/patch/805845/ > > If you try it out, let me know how you get on. > > Thanks, > Ciara Hi Ciara, Thank you for informing me. I will try it out later. Thanks, Tetsuro. > >> >> Thank you, >> >> Tetsuro >> >> On 2017/08/02 18:12, Loftus, Ciara wrote: >>>> >>>> Hi Ciara, >>>> >>>> Thank you for the infomation. >>>> IIUC, you should compile ovs again to use zero copy feature so far, right ? >>> >>> Hi Tetsuro, >>> >>> That's right. I might look into creating a patch to enable it during runtime. >> But for now, you need to apply the patch below & recompile. >>> >>> Thanks, >>> Ciara >>> >>>> >>>> On 2017/08/02 17:04, Loftus, Ciara wrote: >>>>>> >>>>>> Hi, >>>>>> >>>>>> I heard that, about vhost-user interface, >>>>>> 0 copy rx is under development, >>>>>> but 0 copy tx from a vm is already supported with both vhost-user and >>>>>> ovs-dpdk. >>>>>> >>>>>> However, I couldn't find out how to enable that zero copy feature from >>>>>> the ovs document (/ovs/Documentation/topics/dpdk/vhost-user.rst) >>>>>> >>>>>> Could you inform me how to enable it or where I should refer about >> the >>>>>> feature ? >>>>> >>>>> Try this: >>>>> >>>>> diff --git a/lib/netdev-dpdk.c b/lib/netdev-dpdk.c >>>>> index ea17b97..9fdae46 100644 >>>>> --- a/lib/netdev-dpdk.c >>>>> +++ b/lib/netdev-dpdk.c >>>>> @@ -944,6 +944,7 @@ netdev_dpdk_vhost_construct(struct netdev >>>> *netdev) >>>>> dpdk_get_vhost_sock_dir(), name); >>>>> >>>>> dev->vhost_driver_flags &= ~RTE_VHOST_USER_CLIENT; >>>>> + dev->vhost_driver_flags |= >> RTE_VHOST_USER_DEQUEUE_ZERO_COPY; >>>>> err = rte_vhost_driver_register(dev->vhost_id, dev- >>>>> vhost_driver_flags); >>>>> if (err) { >>>>> VLOG_ERR("vhost-user socket device setup failure for socket >> %s\n", >>>>> >>>>> Thanks, >>>>> Ciara >>>>> >>>>>> >>>>>> Thanks >>>>>> >>>>>> -- >>>>>> Tetsuro Nakamura >>>>>> >>>>>> _______________________________________________ >>>>>> discuss mailing list >>>>>> discuss at openvswitch.org >>>>>> https://mail.openvswitch.org/mailman/listinfo/ovs-discuss >>>>> >>>>> >>>> >>>> -- >>>> Tetsuro Nakamura >>>> NTT Network Service Systems Laboratories >>>> TEL:0422 59 6914(National)/+81 422 59 6914(International) >>>> 3-9-11, Midori-Cho Musashino-Shi, Tokyo 180-8585 Japan >>>> >>> >> >> -- >> Tetsuro Nakamura >> NTT Network Service Systems Laboratories >> TEL:0422 59 6914(National)/+81 422 59 6914(International) >> 3-9-11, Midori-Cho Musashino-Shi, Tokyo 180-8585 Japan >> > -- Tetsuro Nakamura NTT Network Service Systems Laboratories TEL:0422 59 6914(National)/+81 422 59 6914(International) 3-9-11, Midori-Cho Musashino-Shi, Tokyo 180-8585 Japan From james.page at ubuntu.com Tue Aug 29 09:41:50 2017 From: james.page at ubuntu.com (James Page) Date: Tue, 29 Aug 2017 09:41:50 +0000 Subject: [ovs-discuss] [openvswitch 2.8.0 dpdk] testsuite: 1211 1212 1213 1214 1215 1217 1218 1219 1220 1221 1222 1224 1225 1226 2338 failed In-Reply-To: <20170808230851.GW6175@ovn.org> References: <328530F9-3E9F-43F5-81C4-E35052A9B54F@vmware.com> <20170808230851.GW6175@ovn.org> Message-ID: On Wed, 9 Aug 2017 at 00:08 Ben Pfaff wrote: > On Tue, Aug 08, 2017 at 04:26:38PM +0000, Darrell Ball wrote: > > > > > > From: on behalf of James Page < > james.page at ubuntu.com> > > Date: Tuesday, August 8, 2017 at 2:49 AM > > To: "bugs at openvswitch.org" > > Subject: [ovs-discuss] [openvswitch 2.8.0 dpdk] testsuite: 1211 1212 > 1213 1214 1215 1217 1218 1219 1220 1221 1222 1224 1225 1226 2338 failed > > > > Hi > > > > I'm cutting builds from branch-2.8 in preparation for the ovs 2.8.0 > release for Ubuntu; we build and test two sets of binaries - a vanilla one > and one with dpdk enabled. > > > > I see test failures on all of the "ofproto-dpif - conntrack" tests with > the DPDK build and with the ovn ACL test (see attached logs). Vanilla > build is fine. > > > > James > > > > These are generic tests and should not be run with-dpdk set. > > If you run these tests --with-dpdk, some tests will consider the packets > coming an actual dpdk interface, which they are not. > > In this case, the packets will be marked with a bad checksum. > > All of the tests in the testsuite should always pass, or be skipped, > regardless of configuration, so if some of the tests are inappropriate > for a given configuration then they need AT_SKIP_IF([...]) to ensure > that they get skipped. > Glad to hear that - as part of the vanilla and DPDK binary builds, we run the complete test suite with both sets of binaries; the smaller the sauce we have to apply in the execution of the tests for the DPDK build the better! Cheers James -------------- next part -------------- An HTML attachment was scrubbed... URL: From mmichels at redhat.com Tue Aug 29 13:31:32 2017 From: mmichels at redhat.com (Mark Michelson) Date: Tue, 29 Aug 2017 13:31:32 +0000 Subject: [ovs-discuss] OVN + OVS question In-Reply-To: <59a424f5.8335ca0a.b061f.1f27@mx.google.com> References: <59a424f5.8335ca0a.b061f.1f27@mx.google.com> Message-ID: On Mon, Aug 28, 2017 at 9:13 AM Nusrat Atta wrote: > Hi, > > I successfully deployed OVS by compiling it and it works fine. All > commands like ovs- work but the ovn- commands don?t work. > > Any help? > > > Your question is vague. When you say "ovn- commands don't work" does that mean that they're unrecognized ("ovn-nbctl: command not found")? Or do you mean that they don't behave the way you would expect based on your configuration? If it's the first, then you probably are not running the necessary OVN processes (ovn-northd and ovn-controller). I suggest you have a look at the ovn-ctl manpage [1] to see how you can start those processes. I also suggest you look at the ovn-architecture manpage [2] so that you can better understand how the various pieces of OVN fit together. If you do have the OVN processes running but the ovn- commands don't retrieve the information you think they should, then you'll need to provide more information, like what command you are running, what you expect to see, and what you actually see instead. Mark Michelson [1] http://openvswitch.org/support/dist-docs/ovn-ctl.8.html [2] http://openvswitch.org/support/dist-docs/ovn-architecture.7.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From sougol.gheissi at gmail.com Tue Aug 29 14:32:24 2017 From: sougol.gheissi at gmail.com (sougol gheissi) Date: Tue, 29 Aug 2017 19:02:24 +0430 Subject: [ovs-discuss] Q: Using netfilter to classify packets in OVS ? In-Reply-To: <20170712203802.GA1568@labs.hpe.com> References: <20170707222039.GA31272@labs.hpe.com> <20170712203802.GA1568@labs.hpe.com> Message-ID: Hello, I have tried to implement something like the above issue, I want to use netfilter to capture UDP packets, modify them and then send them to the OVS. As you said you tried it and it works. My problem is, I send SIP packets to the OVS, but when I try to print the destination port, as it is 5060, I get 53, which is a DNS port. How did you do that? Here is my code. Your help would be really appreciated. #include #include #include #include #include #include #include #include #include static struct nf_hook_ops nfho; struct iphdr *iph; struct udphdr *udp_header; struct sk_buff *sock_buff; unsigned int sport, dport; unsigned int hook_func(unsigned int hooknum, struct sk_buff **skb, const struct net_device *in, const struct net_device *out, int (*okfn)(struct sk_buff *)) { sock_buff = skb; if (!sock_buff) { return NF_ACCEPT; } iph = (struct iphdr *)ip_hdr(sock_buff); if (!sock_buff) { return NF_ACCEPT; } if (!iph) return NF_ACCEPT; if(iph->protocol==IPPROTO_UDP) { udp_header = (struct udphdr *)udp_hdr(sock_buff); printk(KERN_INFO "UDP PKT\n"); sport = htons((unsigned short int) udp_header->source); dport = htons((unsigned short int) udp_header->dest); printk(KERN_INFO "UDP ports: source: %d, dest: %d \n", sport, dport); return NF_ACCEPT; } return NF_ACCEPT; } static int __init initialize(void) { nfho.hook = hook_func; nfho.hooknum = 0; // I use pre-routing hook to have the packets first in the netfilter and then in the ovs nfho.pf = PF_INET; nfho.priority = NF_IP_PRI_FIRST; nf_register_hook(&nfho); printk(KERN_INFO "my netfilter module!\n"); return 0; } static void __exit teardown(void) { nf_unregister_hook(&nfho); } module_init(initialize); module_exit(teardown); On Thu, Jul 13, 2017 at 1:08 AM, Jean Tourrilhes wrote: > On Wed, Jul 12, 2017 at 10:54:34AM -0700, Joe Stringer wrote: > > > > Hi Jean, > > > > There's no native integration, but I could imagine that if Netfilter > > ran on the packets first then modified the skb mark field, then OVS > > ran later on that packet then plausibly you could match on the > > pkt_mark. > > I tried it, and it works great. > Thanks a lot ! > > Jean > _______________________________________________ > discuss mailing list > discuss at openvswitch.org > https://mail.openvswitch.org/mailman/listinfo/ovs-discuss > -------------- next part -------------- An HTML attachment was scrubbed... URL: From joe at ovn.org Tue Aug 29 18:18:59 2017 From: joe at ovn.org (Joe Stringer) Date: Tue, 29 Aug 2017 11:18:59 -0700 Subject: [ovs-discuss] Q: Using netfilter to classify packets in OVS ? In-Reply-To: References: <20170707222039.GA31272@labs.hpe.com> <20170712203802.GA1568@labs.hpe.com> Message-ID: On 29 August 2017 at 07:32, sougol gheissi wrote: > Hello, > I have tried to implement something like the above issue, I want to use > netfilter to capture UDP packets, modify them and then send them to the OVS. > As you said you tried it and it works. My problem is, I send SIP packets to > the OVS, but when I try to print the destination port, as it is 5060, I get > 53, which is a DNS port. How did you do that? It sounds like you're received DNS traffic as well as your SIP traffic. From sougol.gheissi at gmail.com Tue Aug 29 19:46:08 2017 From: sougol.gheissi at gmail.com (sougol gheissi) Date: Wed, 30 Aug 2017 00:16:08 +0430 Subject: [ovs-discuss] Q: Using netfilter to classify packets in OVS ? In-Reply-To: References: <20170707222039.GA31272@labs.hpe.com> <20170712203802.GA1568@labs.hpe.com> Message-ID: Thanks for the reply. In the kernel log, I just receive packets with destination port number 53. Does netfiler pre rouing hook really capture all packets before ovs? On 29 Aug 2017 22:49, "Joe Stringer" wrote: > On 29 August 2017 at 07:32, sougol gheissi > wrote: > > Hello, > > I have tried to implement something like the above issue, I want to use > > netfilter to capture UDP packets, modify them and then send them to the > OVS. > > As you said you tried it and it works. My problem is, I send SIP packets > to > > the OVS, but when I try to print the destination port, as it is 5060, I > get > > 53, which is a DNS port. How did you do that? > > It sounds like you're received DNS traffic as well as your SIP traffic. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From knight_leb at yahoo.com Tue Aug 29 23:27:29 2017 From: knight_leb at yahoo.com (N F) Date: Tue, 29 Aug 2017 23:27:29 +0000 (UTC) Subject: [ovs-discuss] Traffic Isolation with OVS References: <396782980.5165951.1504049249397.ref@mail.yahoo.com> Message-ID: <396782980.5165951.1504049249397@mail.yahoo.com> Greetings all,? I have a little challenge?and I can't seem to work around it, ?I am certain it's my limited OVS skills. Assuming I have a single bridge with two interfaces, eth0 and eth1, and assuming I have a VM guest with two VLANs 100 and 200. ?Is it possible to pin VLAN100 to eth0 and VLAN200 to eth1? ? My challenge is I can't have more than one OVS bridge, the bridge must steer the traffic based on the VM's interface or VLAN. ? Ideally, I would love to have separate broadcast domains for a set of VLANs, or a concept like VRF. Any suggestions? Thank you, Gibran -------------- next part -------------- An HTML attachment was scrubbed... URL: From joo.yongseok at gmail.com Tue Aug 29 23:55:15 2017 From: joo.yongseok at gmail.com (Joo Yong-Seok) Date: Tue, 29 Aug 2017 16:55:15 -0700 Subject: [ovs-discuss] Traffic Isolation with OVS In-Reply-To: <396782980.5165951.1504049249397@mail.yahoo.com> References: <396782980.5165951.1504049249397.ref@mail.yahoo.com> <396782980.5165951.1504049249397@mail.yahoo.com> Message-ID: How about this? ovs-vsctl set port eth0 tag=100 vlan_mode=native-untagged ovs-vsctl set port eth1 tag=200 vlan_mode=native-untagged eth0 and eth1 is on br0. Best regards, On Tue, Aug 29, 2017 at 4:27 PM, N F via discuss < ovs-discuss at openvswitch.org> wrote: > Greetings all, > > I have a little challenge and I can't seem to work around it, I am > certain it's my limited OVS skills. > > Assuming I have a single bridge with two interfaces, eth0 and eth1, and > assuming I have a VM guest with two VLANs 100 and 200. Is it possible to > pin VLAN100 to eth0 and VLAN200 to eth1? > > My challenge is I can't have more than one OVS bridge, the bridge must > steer the traffic based on the VM's interface or VLAN. > > Ideally, I would love to have separate broadcast domains for a set of > VLANs, or a concept like VRF. > > Any suggestions? > > Thank you, > > Gibran > > _______________________________________________ > discuss mailing list > discuss at openvswitch.org > https://mail.openvswitch.org/mailman/listinfo/ovs-discuss > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hschoi at os.korea.ac.kr Wed Aug 30 02:03:30 2017 From: hschoi at os.korea.ac.kr (Heung Sik Choi) Date: Wed, 30 Aug 2017 11:03:30 +0900 Subject: [ovs-discuss] How can I OVS run in multi-core? Message-ID: Hi, I want to measure the performance of OVS in multi core. I have a server on two Xeon 2630 v2 (NUMA) with 8 dual port 10GbE NIC. the server run OVS. Also there are other two server, which are that one is DPDK pktgen TX, the other is DPDK pktgen RX. Pktgen TX send to OVS server on 40G line(4* 10G Line), and then OVS send the traffic to the Pktgen RX machine.the OVS' rule is as below: ovs-ofctl add-flow ovs-br1 ip,nw_src=192.160.110.101,ip,nw_dst=192.160.110.115,tcp,tp_src=42349,tcp,tp_dst=42349,actions=output:5 ovs-ofctl add-flow ovs-br1 ip,nw_src=192.160.110.101,ip,nw_dst=192.160.110.116,tcp,tp_src=42349,tcp,tp_dst=42349,actions=output:5 ovs-ofctl add-flow ovs-br1 ip,nw_src=192.160.110.101,ip,nw_dst=192.160.110.117,tcp,tp_src=42349,tcp,tp_dst=42349,actions=output:5 ovs-ofctl add-flow ovs-br1 ip,nw_src=192.160.110.101,ip,nw_dst=192.160.110.118,tcp,tp_src=42349,tcp,tp_dst=42349,actions=output:5 ovs-ofctl add-flow ovs-br1 ip,nw_src=192.161.110.114,ip,nw_dst=192.161.110.119,tcp,tp_src=42349,tcp,tp_dst=42349,actions=output:6 ovs-ofctl add-flow ovs-br1 ip,nw_src=192.161.110.114,ip,nw_dst=192.161.110.120,tcp,tp_src=42349,tcp,tp_dst=42349,actions=output:6 ovs-ofctl add-flow ovs-br1 ip,nw_src=192.161.110.114,ip,nw_dst=192.161.110.121,tcp,tp_src=42349,tcp,tp_dst=42349,actions=output:6 ovs-ofctl add-flow ovs-br1 ip,nw_src=192.161.110.114,ip,nw_dst=192.161.110.122,tcp,tp_src=42349,tcp,tp_dst=42349,actions=output:6 ovs-ofctl add-flow ovs-br1 ip,nw_src=192.162.110.114,ip,nw_dst=192.162.110.123,tcp,tp_src=42349,tcp,tp_dst=42349,actions=output:7 ovs-ofctl add-flow ovs-br1 ip,nw_src=192.162.110.114,ip,nw_dst=192.162.110.124,tcp,tp_src=42349,tcp,tp_dst=42349,actions=output:7 ovs-ofctl add-flow ovs-br1 ip,nw_src=192.162.110.114,ip,nw_dst=192.162.110.125,tcp,tp_src=42349,tcp,tp_dst=42349,actions=output:7 ovs-ofctl add-flow ovs-br1 ip,nw_src=192.162.110.114,ip,nw_dst=192.162.110.126,tcp,tp_src=42349,tcp,tp_dst=42349,actions=output:7 ovs-ofctl add-flow ovs-br1 ip,nw_src=192.163.110.114,ip,nw_dst=192.163.110.127,tcp,tp_src=42349,tcp,tp_dst=42349,actions=output:8 ovs-ofctl add-flow ovs-br1 ip,nw_src=192.163.110.114,ip,nw_dst=192.163.110.128,tcp,tp_src=42349,tcp,tp_dst=42349,actions=output:8 ovs-ofctl add-flow ovs-br1 ip,nw_src=192.163.110.114,ip,nw_dst=192.163.110.129,tcp,tp_src=42349,tcp,tp_dst=42349,actions=output:8 ovs-ofctl add-flow ovs-br1 ip,nw_src=192.163.110.114,ip,nw_dst=192.163.110.130,tcp,tp_src=42349,tcp,tp_dst=42349,actions=output:8 Each port(1,2,3,4) process 4 different flows, and I thought that it makes OVS run using full CPU core. However, it didn't!! Please let me know if you have any insights about how OVS runs on multi-core(also all CPU cores full utilization). -------------- next part -------------- An HTML attachment was scrubbed... URL: From blue at veracity.io Wed Aug 30 02:50:19 2017 From: blue at veracity.io (Blue Lang) Date: Tue, 29 Aug 2017 22:50:19 -0400 Subject: [ovs-discuss] How can I OVS run in multi-core? In-Reply-To: References: Message-ID: Do you have 40+gbs of bandwidth on the bus available? On Tue, Aug 29, 2017 at 10:03 PM, Heung Sik Choi wrote: > Hi, > > I want to measure the performance of OVS in multi core. > > I have a server on two Xeon 2630 v2 (NUMA) with 8 dual port 10GbE NIC. the > server run OVS. Also there are other two server, which are that one is DPDK > pktgen TX, the other is DPDK pktgen RX. Pktgen TX send to OVS server on 40G > line(4* 10G Line), and then OVS send the traffic to the Pktgen RX > machine.the OVS' rule is as below: > > ovs-ofctl add-flow ovs-br1 ip,nw_src=192.160.110.101,ip, > nw_dst=192.160.110.115,tcp,tp_src=42349,tcp,tp_dst=42349,actions=output:5 > ovs-ofctl add-flow ovs-br1 ip,nw_src=192.160.110.101,ip, > nw_dst=192.160.110.116,tcp,tp_src=42349,tcp,tp_dst=42349,actions=output:5 > ovs-ofctl add-flow ovs-br1 ip,nw_src=192.160.110.101,ip, > nw_dst=192.160.110.117,tcp,tp_src=42349,tcp,tp_dst=42349,actions=output:5 > ovs-ofctl add-flow ovs-br1 ip,nw_src=192.160.110.101,ip, > nw_dst=192.160.110.118,tcp,tp_src=42349,tcp,tp_dst=42349,actions=output:5 > > ovs-ofctl add-flow ovs-br1 ip,nw_src=192.161.110.114,ip, > nw_dst=192.161.110.119,tcp,tp_src=42349,tcp,tp_dst=42349,actions=output:6 > ovs-ofctl add-flow ovs-br1 ip,nw_src=192.161.110.114,ip, > nw_dst=192.161.110.120,tcp,tp_src=42349,tcp,tp_dst=42349,actions=output:6 > ovs-ofctl add-flow ovs-br1 ip,nw_src=192.161.110.114,ip, > nw_dst=192.161.110.121,tcp,tp_src=42349,tcp,tp_dst=42349,actions=output:6 > ovs-ofctl add-flow ovs-br1 ip,nw_src=192.161.110.114,ip, > nw_dst=192.161.110.122,tcp,tp_src=42349,tcp,tp_dst=42349,actions=output:6 > > ovs-ofctl add-flow ovs-br1 ip,nw_src=192.162.110.114,ip, > nw_dst=192.162.110.123,tcp,tp_src=42349,tcp,tp_dst=42349,actions=output:7 > ovs-ofctl add-flow ovs-br1 ip,nw_src=192.162.110.114,ip, > nw_dst=192.162.110.124,tcp,tp_src=42349,tcp,tp_dst=42349,actions=output:7 > ovs-ofctl add-flow ovs-br1 ip,nw_src=192.162.110.114,ip, > nw_dst=192.162.110.125,tcp,tp_src=42349,tcp,tp_dst=42349,actions=output:7 > ovs-ofctl add-flow ovs-br1 ip,nw_src=192.162.110.114,ip, > nw_dst=192.162.110.126,tcp,tp_src=42349,tcp,tp_dst=42349,actions=output:7 > > ovs-ofctl add-flow ovs-br1 ip,nw_src=192.163.110.114,ip, > nw_dst=192.163.110.127,tcp,tp_src=42349,tcp,tp_dst=42349,actions=output:8 > ovs-ofctl add-flow ovs-br1 ip,nw_src=192.163.110.114,ip, > nw_dst=192.163.110.128,tcp,tp_src=42349,tcp,tp_dst=42349,actions=output:8 > ovs-ofctl add-flow ovs-br1 ip,nw_src=192.163.110.114,ip, > nw_dst=192.163.110.129,tcp,tp_src=42349,tcp,tp_dst=42349,actions=output:8 > ovs-ofctl add-flow ovs-br1 ip,nw_src=192.163.110.114,ip, > nw_dst=192.163.110.130,tcp,tp_src=42349,tcp,tp_dst=42349,actions=output:8 > > > Each port(1,2,3,4) process 4 different flows, and I thought that it makes > OVS run using full CPU core. However, it didn't!! > > Please let me know if you have any insights about how OVS runs on > multi-core(also all CPU cores full utilization). > > _______________________________________________ > discuss mailing list > discuss at openvswitch.org > https://mail.openvswitch.org/mailman/listinfo/ovs-discuss > > -- Blue Lang PM *| *Veracity 3423 Piedmont Rd NE Suite 350 Atlanta, GA 30305 Cell: (770) 265-1381 <+17702651381> https://www.linkedin.com/in/bluelang/ blue at veracity.io www.veracity.io -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Veracity-horizontal-logo-tiny_sig.png Type: image/png Size: 5372 bytes Desc: not available URL: From hschoi at os.korea.ac.kr Wed Aug 30 05:27:53 2017 From: hschoi at os.korea.ac.kr (Heung Sik Choi) Date: Wed, 30 Aug 2017 14:27:53 +0900 Subject: [ovs-discuss] How can I OVS run in multi-core? In-Reply-To: References: Message-ID: Do you have 40+gbs of bandwidth on the bus available? Yes. First, I'm sorry to confuse you, because I misrepresented my server specification. I have a server on two Xeon 2630 v2 (NUMA) with* 4 (not 8)* dual port 10GbE NIC. This machine used for measuring linux and DPDK forwarding performance on 40G Line. In addition, 29Gbps was achived on the machine in some experiment. It is weird that when OVS' server receive overall 4 type flows(per port only 1 flow), OVS runs using 4 cores. However, the server receive overall 16 type flows( per port 4 type flows), OVS can not use even four cores. It is very weird. If you have some experience running multi core on OVS, please let me know about how to set or some insights. 2017-08-30 11:50 GMT+09:00 Blue Lang : > Do you have 40+gbs of bandwidth on the bus available? > > On Tue, Aug 29, 2017 at 10:03 PM, Heung Sik Choi > wrote: > >> Hi, >> >> I want to measure the performance of OVS in multi core. >> >> I have a server on two Xeon 2630 v2 (NUMA) with 8 dual port 10GbE NIC. >> the server run OVS. Also there are other two server, which are that one is >> DPDK pktgen TX, the other is DPDK pktgen RX. Pktgen TX send to OVS server >> on 40G line(4* 10G Line), and then OVS send the traffic to the Pktgen RX >> machine.the OVS' rule is as below: >> >> ovs-ofctl add-flow ovs-br1 ip,nw_src=192.160.110.101,ip,n >> w_dst=192.160.110.115,tcp,tp_src=42349,tcp,tp_dst=42349,actions=output:5 >> ovs-ofctl add-flow ovs-br1 ip,nw_src=192.160.110.101,ip,n >> w_dst=192.160.110.116,tcp,tp_src=42349,tcp,tp_dst=42349,actions=output:5 >> ovs-ofctl add-flow ovs-br1 ip,nw_src=192.160.110.101,ip,n >> w_dst=192.160.110.117,tcp,tp_src=42349,tcp,tp_dst=42349,actions=output:5 >> ovs-ofctl add-flow ovs-br1 ip,nw_src=192.160.110.101,ip,n >> w_dst=192.160.110.118,tcp,tp_src=42349,tcp,tp_dst=42349,actions=output:5 >> >> ovs-ofctl add-flow ovs-br1 ip,nw_src=192.161.110.114,ip,n >> w_dst=192.161.110.119,tcp,tp_src=42349,tcp,tp_dst=42349,actions=output:6 >> ovs-ofctl add-flow ovs-br1 ip,nw_src=192.161.110.114,ip,n >> w_dst=192.161.110.120,tcp,tp_src=42349,tcp,tp_dst=42349,actions=output:6 >> ovs-ofctl add-flow ovs-br1 ip,nw_src=192.161.110.114,ip,n >> w_dst=192.161.110.121,tcp,tp_src=42349,tcp,tp_dst=42349,actions=output:6 >> ovs-ofctl add-flow ovs-br1 ip,nw_src=192.161.110.114,ip,n >> w_dst=192.161.110.122,tcp,tp_src=42349,tcp,tp_dst=42349,actions=output:6 >> >> ovs-ofctl add-flow ovs-br1 ip,nw_src=192.162.110.114,ip,n >> w_dst=192.162.110.123,tcp,tp_src=42349,tcp,tp_dst=42349,actions=output:7 >> ovs-ofctl add-flow ovs-br1 ip,nw_src=192.162.110.114,ip,n >> w_dst=192.162.110.124,tcp,tp_src=42349,tcp,tp_dst=42349,actions=output:7 >> ovs-ofctl add-flow ovs-br1 ip,nw_src=192.162.110.114,ip,n >> w_dst=192.162.110.125,tcp,tp_src=42349,tcp,tp_dst=42349,actions=output:7 >> ovs-ofctl add-flow ovs-br1 ip,nw_src=192.162.110.114,ip,n >> w_dst=192.162.110.126,tcp,tp_src=42349,tcp,tp_dst=42349,actions=output:7 >> >> ovs-ofctl add-flow ovs-br1 ip,nw_src=192.163.110.114,ip,n >> w_dst=192.163.110.127,tcp,tp_src=42349,tcp,tp_dst=42349,actions=output:8 >> ovs-ofctl add-flow ovs-br1 ip,nw_src=192.163.110.114,ip,n >> w_dst=192.163.110.128,tcp,tp_src=42349,tcp,tp_dst=42349,actions=output:8 >> ovs-ofctl add-flow ovs-br1 ip,nw_src=192.163.110.114,ip,n >> w_dst=192.163.110.129,tcp,tp_src=42349,tcp,tp_dst=42349,actions=output:8 >> ovs-ofctl add-flow ovs-br1 ip,nw_src=192.163.110.114,ip,n >> w_dst=192.163.110.130,tcp,tp_src=42349,tcp,tp_dst=42349,actions=output:8 >> >> >> Each port(1,2,3,4) process 4 different flows, and I thought that it makes >> OVS run using full CPU core. However, it didn't!! >> >> Please let me know if you have any insights about how OVS runs on >> multi-core(also all CPU cores full utilization). >> >> _______________________________________________ >> discuss mailing list >> discuss at openvswitch.org >> https://mail.openvswitch.org/mailman/listinfo/ovs-discuss >> >> > > > -- > Blue Lang > PM *| *Veracity > > 3423 Piedmont Rd NE > > Suite 350 > > Atlanta, GA 30305 > Cell: (770) 265-1381 <+17702651381> > https://www.linkedin.com/in/bluelang/ > blue at veracity.io > www.veracity.io > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Veracity-horizontal-logo-tiny_sig.png Type: image/png Size: 5372 bytes Desc: not available URL: From coldd.hott at yahoo.com Wed Aug 30 12:27:48 2017 From: coldd.hott at yahoo.com (Gibran Gibran) Date: Wed, 30 Aug 2017 12:27:48 +0000 (UTC) Subject: [ovs-discuss] Traffic Isolation with OVS In-Reply-To: References: <396782980.5165951.1504049249397.ref@mail.yahoo.com> <396782980.5165951.1504049249397@mail.yahoo.com> Message-ID: <798931140.321293.1504096068223@mail.yahoo.com> Thank you Joo, this is a really good starting point to try out. Let's me pose a more challenging scenario since you solved this one quick :) Assuming I have two bridges, br-in, and br-ex, and the VM guest supports only VLAN tagging, is it somehow possible?on KVM to steer traffic to br-in?or br-ex depending on the VLAN tag? ?I realize this is more of KVM question, but I am hoping you or someone on the list knows something about it. ????????????????????????????????VM Guest????????????????????????????????? ? ||? ?????????????????????????????????/ ?\?????????????????????????????????/ ? ? \????????????????????????????V10 ? ? ?V20? ? ? ? ? ? ? ? ? ? ? ? ? ? ? / ? ? ? ? ?\? ? ? ? ? ? ? ? ? ? ? ? ?br-ex ? ? ? ? ?br-in? ? ? ? ? ? ? ? ? ? ? ? ? ? / ? ? ? ? ? ? ? \? ? ? ? ? ? ? ? ? ? ? ? eth0 ? ? ? ? ? ?eth1 Thank you, Gibran?? ? ? From: Joo Yong-Seok To: N F Cc: "ovs-discuss at openvswitch.org" Sent: Tuesday, August 29, 2017 7:55 PM Subject: Re: [ovs-discuss] Traffic Isolation with OVS How about this? ovs-vsctl set port eth0 tag=100 vlan_mode=native-untagged ovs-vsctl set port eth1 tag=200 vlan_mode=native-untagged eth0 and eth1 is on br0. Best regards, On Tue, Aug 29, 2017 at 4:27 PM, N F via discuss wrote: Greetings all,? I have a little challenge?and I can't seem to work around it, ?I am certain it's my limited OVS skills. Assuming I have a single bridge with two interfaces, eth0 and eth1, and assuming I have a VM guest with two VLANs 100 and 200.? Is it possible to pin VLAN100 to eth0 and VLAN200 to eth1? ? My challenge is I can't have more than one OVS bridge, the bridge must steer the traffic based on the VM's interface or VLAN. ? Ideally, I would love to have separate broadcast domains for a set of VLANs, or a concept like VRF. Any suggestions? Thank you, Gibran ______________________________ _________________ discuss mailing list discuss at openvswitch.org https://mail.openvswitch.org/ mailman/listinfo/ovs-discuss -------------- next part -------------- An HTML attachment was scrubbed... URL: From sara.gittlin at gmail.com Wed Aug 30 15:42:17 2017 From: sara.gittlin at gmail.com (Sara Gittlin) Date: Wed, 30 Aug 2017 18:42:17 +0300 Subject: [ovs-discuss] Fwd: udpif_upcall_handler In-Reply-To: References: Message-ID: Hello, Few questions: 1. There are 3 calls to udpif_upcall_handler to create 'revalidator' and 'handler' threads - why is that ? 2. Is there a code API (other than cli) to retrieve all OpenFlow entries from ofproto tables ? get first , get next etc .. 3. When an openflow entry/flow is retrieved - how can i identify/understand the **form** of the entry i.e. what are the fields/keys to match on ? e.g. ETH + VLAN , ETH+IP , ETH_IP+ TCP port etc.. Thank in advance, -Sara From joo.yongseok at gmail.com Wed Aug 30 16:29:29 2017 From: joo.yongseok at gmail.com (Joo Yong-Seok) Date: Wed, 30 Aug 2017 09:29:29 -0700 Subject: [ovs-discuss] Traffic Isolation with OVS In-Reply-To: <798931140.321293.1504096068223@mail.yahoo.com> References: <396782980.5165951.1504049249397.ref@mail.yahoo.com> <396782980.5165951.1504049249397@mail.yahoo.com> <798931140.321293.1504096068223@mail.yahoo.com> Message-ID: Not sure whether I understand your intention properly, but it sounds like routing rather than switching. If you want, you can enable routing on OVS - Routing is nothing but changing DMAC and sending the packet to right egress port (or hand-over pkts to bridge/switch) after looking up routing table. Best regards, On Wed, Aug 30, 2017 at 5:27 AM, Gibran Gibran wrote: > Thank you Joo, this is a really good starting point to try out. > > Let's me pose a more challenging scenario since you solved this one quick > :) > > Assuming I have two bridges, br-in, and br-ex, and the VM guest supports > only VLAN tagging, is it somehow possible on KVM to steer traffic to > br-in or br-ex depending on the VLAN tag? I realize this is more of KVM > question, but I am hoping you or someone on the list knows something about > it. > > VM Guest > || > / \ > / \ > V10 V20 > / \ > br-ex br-in > / \ > eth0 eth1 > > Thank you, > > Gibran > > > > ------------------------------ > *From:* Joo Yong-Seok > *To:* N F > *Cc:* "ovs-discuss at openvswitch.org" > *Sent:* Tuesday, August 29, 2017 7:55 PM > *Subject:* Re: [ovs-discuss] Traffic Isolation with OVS > > How about this? > > ovs-vsctl set port eth0 tag=100 vlan_mode=native-untagged > ovs-vsctl set port eth1 tag=200 vlan_mode=native-untagged > > eth0 and eth1 is on br0. > > Best regards, > > On Tue, Aug 29, 2017 at 4:27 PM, N F via discuss < > ovs-discuss at openvswitch.org> wrote: > > Greetings all, > > I have a little challenge and I can't seem to work around it, I am > certain it's my limited OVS skills. > > Assuming I have a single bridge with two interfaces, eth0 and eth1, and > assuming I have a VM guest with two VLANs 100 and 200. Is it possible to > pin VLAN100 to eth0 and VLAN200 to eth1? > > My challenge is I can't have more than one OVS bridge, the bridge must > steer the traffic based on the VM's interface or VLAN. > > Ideally, I would love to have separate broadcast domains for a set of > VLANs, or a concept like VRF. > > Any suggestions? > > Thank you, > > Gibran > > ______________________________ _________________ > discuss mailing list > discuss at openvswitch.org > https://mail.openvswitch.org/ mailman/listinfo/ovs-discuss > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hschoi at os.korea.ac.kr Thu Aug 31 07:04:22 2017 From: hschoi at os.korea.ac.kr (Heung Sik Choi) Date: Thu, 31 Aug 2017 16:04:22 +0900 Subject: [ovs-discuss] How can I OVS run in multi-core? Message-ID: Hi, I want to measure the performance of OVS in multi core. I have a server on two Xeon 2630 v2 (NUMA) with 4 dual port 10GbE NIC. the server with 12 cores and 8 physical ports run OVS. 4ports are for receiving 40Gbps traffic and the other 4 ports are for sending 40Gbps traffic. I use DPDK pktgen on other machine to make intensive traffic. using this maching, I sent 12 type flow traffic to OVS server. At this experiment I expected that OVS run in using 12 cores fully. However, It didn't work . I can not find any information(such as slide, pdf and so on) that any one do experiment of OVS performance using multi core. Please let me know if you have any insights about how OVS runs on multi-core. -------------- next part -------------- An HTML attachment was scrubbed... URL: From muthurajan.jayakumar at intel.com Thu Aug 31 07:12:43 2017 From: muthurajan.jayakumar at intel.com (Jayakumar, Muthurajan) Date: Thu, 31 Aug 2017 07:12:43 +0000 Subject: [ovs-discuss] quad port X710 rNDC (Dell) make KVM host br0 OVS (2.5.0) port lose connection Message-ID: <5D695A7F6F10504DBD9B9187395A21797EA3F8D1@ORSMSX112.amr.corp.intel.com> Dear team, Can I please request if any one of you have seen similar observation please. Kindly requesting to share your suggestion please. Following is the observation: quad port X710 rNDC (Dell) make KVM host br0 OVS (2.5.0) port lose connection Background: We are introducing quad port Intel X710 rNDC to all Dell 14G platform. We make all eth0-eth3 of X710 (i40e driver 2.0.23, FW 6.00) as br0 uplink bond of KVM OVS, and we have observed periodic network connection loss (ping unreachable) on the br0 interface. Attached is one of node's OVS config & network port info. The AHV KVM host is: CentOS release 6.8 (Final) 4.4.26-1.el6.nutanix.20160925.83.x86_64 From ovs-vsctl, eth0 is active OVS upstream port, eth1 is standby OVS port. Bridge "br0" Port "br0" Interface "br0" type: internal Port "br0-dhcp" Interface "br0-dhcp" type: vxlan options: {key="1", remote_ip="10.211.56.93"} Port "br0-up" Interface "eth1" Interface "eth3" Interface "eth0" Interface "eth2" Port "tap0" tag: 0 Interface "tap0" Port "vnet0" Interface "vnet0" Port "br0-arp" Interface "br0-arp" type: vxlan options: {key="1", remote_ip="192.168.5.2"} ovs_version: "2.5.0" ---- br0-up ---- bond_mode: active-backup bond may use recirculation: no, Recirc-ID : -1 bond-hash-basis: 0 updelay: 0 ms downdelay: 0 ms lacp_status: off active slave mac: 24:6e:96:47:6d:0c(eth1) slave eth0: enabled may_enable: true slave eth1: enabled active slave may_enable: true slave eth2: disabled may_enable: false slave eth3: disabled may_enable: false However, eth1 (port 1) has much more tx/rx traffic than eth0 (port3) per ovs-ofctl dump, why? And pkt drop is on br0 uplink bond port & tap0 VM vnic port: ovs-ofctl dump-ports-desc br0 ----------------------------- OFPST_PORT_DESC reply (xid=0x2): 1(eth1): addr:24:6e:96:47:6d:0c config: 0 state: 0 current: 10GB-FD advertised: FIBER supported: 10GB-FD FIBER AUTO_PAUSE speed: 10000 Mbps now, 10000 Mbps max 2(eth3): addr:24:6e:96:47:6d:10 config: 0 state: LINK_DOWN advertised: 1GB-FD 10GB-FD AUTO_NEG supported: 1GB-FD 10GB-FD AUTO_NEG AUTO_PAUSE speed: 0 Mbps now, 10000 Mbps max 3(eth0): addr:24:6e:96:47:6d:0a config: 0 state: 0 current: 10GB-FD advertised: FIBER supported: 10GB-FD FIBER AUTO_PAUSE speed: 10000 Mbps now, 10000 Mbps max 4(eth2): addr:24:6e:96:47:6d:0e config: 0 state: LINK_DOWN advertised: 1GB-FD 10GB-FD AUTO_NEG supported: 1GB-FD 10GB-FD AUTO_NEG AUTO_PAUSE speed: 0 Mbps now, 10000 Mbps max 5(vnet0): addr:fe:6b:8d:80:5c:a8 config: 0 state: 0 current: 10MB-FD COPPER speed: 10 Mbps now, 0 Mbps max 6(br0-arp): addr:a6:3e:f0:db:76:c6 config: NO_FLOOD state: 0 speed: 0 Mbps now, 0 Mbps max 7(br0-dhcp): addr:62:4d:cc:2f:33:b4 config: NO_FLOOD state: 0 speed: 0 Mbps now, 0 Mbps max 37(tap0): addr:4a:37:5e:99:48:b7 config: 0 state: 0 current: 10MB-FD COPPER speed: 10 Mbps now, 0 Mbps max LOCAL(br0): addr:24:6e:96:47:6d:0a config: 0 state: 0 speed: 0 Mbps now, 0 Mbps max ovs-ofctl dump-ports br0 ------------------------ OFPST_PORT reply (xid=0x2): 9 ports port LOCAL: rx pkts=2908711, bytes=942823314, drop=3031, errs=0, frame=0, over=0, crc=0 tx pkts=2527350, bytes=909830850, drop=0, errs=0, coll=0 port 37: rx pkts=7, bytes=412, drop=0, errs=0, frame=0, over=0, crc=0 tx pkts=16, bytes=1666, drop=50414, errs=0, coll=0 port 5: rx pkts=69363971, bytes=32991240945, drop=0, errs=0, frame=0, over=0, crc=0 tx pkts=69705117, bytes=36274599187, drop=0, errs=0, coll=0 port 1: rx pkts=85268869, bytes=37284065534, drop=0, errs=0, frame=0, over=0, crc=0 tx pkts=83538302, bytes=33877468309, drop=0, errs=0, coll=0 port 4: rx pkts=0, bytes=0, drop=0, errs=0, frame=0, over=0, crc=0 tx pkts=0, bytes=0, drop=0, errs=0, coll=0 port 6: rx pkts=0, bytes=0, drop=0, errs=0, frame=0, over=0, crc=0 tx pkts=18, bytes=756, drop=0, errs=0, coll=0 port 7: rx pkts=0, bytes=0, drop=0, errs=0, frame=0, over=0, crc=0 tx pkts=0, bytes=0, drop=0, errs=0, coll=0 port 2: rx pkts=0, bytes=0, drop=0, errs=0, frame=0, over=0, crc=0 tx pkts=0, bytes=0, drop=0, errs=0, coll=0 port 3: rx pkts=483827, bytes=47188768, drop=0, errs=0, frame=0, over=0, crc=0 tx pkts=16, bytes=1296, drop=0, errs=0, coll=0 Please help to advise what's the next step to root cause this blocking issue. Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: From nanda.siddharth99 at gmail.com Thu Aug 31 21:01:44 2017 From: nanda.siddharth99 at gmail.com (Siddharth Nanda) Date: Fri, 1 Sep 2017 02:31:44 +0530 Subject: [ovs-discuss] Power Consumption Calculation Message-ID: Hi Sir/Madam, Can you kindly help me find out the method to monitor the power of a particular Open vSwitch with management interface in GNS3. Thanks in advance. Regards, Sid -------------- next part -------------- An HTML attachment was scrubbed... URL: