By the way, I'm still starting vswitchd with valgrind and detected some memory errors after using "sudo ovs-appctl exit". Is there other way to exit/stop ovs?
To run I used: valgrind --tool=memcheck --leak-check=full ovs-vswitchd --pidfile --detach -v --log-file ==2344== HEAP SUMMARY: ==2344== in use at exit: 168,557 bytes in 478 blocks ==2344== total heap usage: 1,098,675 allocs, 1,098,197 frees, 2,428,965,580 bytes allocated ==2344== ==2344== 8 bytes in 1 blocks are possibly lost in loss record 31 of 378 ==2344== at 0x4C2BBCF: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==2344== by 0x4EC244: xmalloc (util.c:112) ==2344== by 0x4EC2A4: xmemdup0 (util.c:142) ==2344== by 0x47F6F1: netdev_open (netdev.c:378) ==2344== by 0x4E8939: insert_ipdev (tnl-ports.c:355) ==2344== by 0x4E8F7A: tnl_port_map_insert_ipdev (tnl-ports.c:423) ==2344== by 0x4C36DF: ovs_router_insert__ (ovs-router.c:150) ==2344== by 0x507C8D: route_table_handle_msg (route-table.c:301) ==2344== by 0x507C8D: route_table_reset (route-table.c:186) ==2344== by 0x507E71: route_table_run (route-table.c:135) ==2344== by 0x47D65E: netdev_vport_run (netdev-vport.c:376) ==2344== by 0x47F209: netdev_run (netdev.c:183) ==2344== by 0x404FC3: main (ovs-vswitchd.c:122) ==2344== ==2344== 40 bytes in 1 blocks are possibly lost in loss record 316 of 378 ==2344== at 0x4C2BBCF: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==2344== by 0x4EC244: xmalloc (util.c:112) ==2344== by 0x52ED76: nln_notifier_create (netlink-notifier.c:129) ==2344== by 0x507DAE: name_table_init (route-table.c:327) ==2344== by 0x507DAE: route_table_init (route-table.c:114) ==2344== by 0x462887: dp_initialize (dpif.c:126) ==2344== by 0x462ADD: dp_enumerate_types (dpif.c:246) ==2344== by 0x418104: ofproto_enumerate_types (ofproto.c:470) ==2344== by 0x408BA4: bridge_run__ (bridge.c:2877) ==2344== by 0x40E513: bridge_run (bridge.c:2940) ==2344== by 0x404FB4: main (ovs-vswitchd.c:120) ==2344== ==2344== 64 bytes in 1 blocks are possibly lost in loss record 331 of 378 ==2344== at 0x4C2BBCF: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==2344== by 0x4EC244: xmalloc (util.c:112) ==2344== by 0x4DCFD9: seq_wait__ (seq.c:156) ==2344== by 0x4DCFD9: seq_wait_at (seq.c:189) ==2344== by 0x4C340B: ovsrcu_postpone_thread (ovs-rcu.c:286) ==2344== by 0x4C41C3: ovsthread_wrapper (ovs-thread.c:340) ==2344== by 0x4E3F6A9: start_thread (pthread_create.c:333) ==2344== by 0x566CE9C: clone (clone.S:109) ==2344== ==2344== 160 bytes in 2 blocks are possibly lost in loss record 347 of 378 ==2344== at 0x4C2DB95: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==2344== by 0x4EC1E2: xcalloc (util.c:95) ==2344== by 0x4E8999: insert_ipdev (tnl-ports.c:366) ==2344== by 0x4E8F7A: tnl_port_map_insert_ipdev (tnl-ports.c:423) ==2344== by 0x4C36DF: ovs_router_insert__ (ovs-router.c:150) ==2344== by 0x507C8D: route_table_handle_msg (route-table.c:301) ==2344== by 0x507C8D: route_table_reset (route-table.c:186) ==2344== by 0x507E71: route_table_run (route-table.c:135) ==2344== by 0x47D65E: netdev_vport_run (netdev-vport.c:376) ==2344== by 0x47F209: netdev_run (netdev.c:183) ==2344== by 0x404FC3: main (ovs-vswitchd.c:122) ==2344== ==2344== 456 bytes in 1 blocks are possibly lost in loss record 354 of 378 ==2344== at 0x4C2DB95: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==2344== by 0x4EC1E2: xcalloc (util.c:95) ==2344== by 0x4FB42D: netdev_linux_alloc (netdev-linux.c:765) ==2344== by 0x47F6AD: netdev_open (netdev.c:374) ==2344== by 0x4E8939: insert_ipdev (tnl-ports.c:355) ==2344== by 0x4E8F7A: tnl_port_map_insert_ipdev (tnl-ports.c:423) ==2344== by 0x4C36DF: ovs_router_insert__ (ovs-router.c:150) ==2344== by 0x507C8D: route_table_handle_msg (route-table.c:301) ==2344== by 0x507C8D: route_table_reset (route-table.c:186) ==2344== by 0x507E71: route_table_run (route-table.c:135) ==2344== by 0x47D65E: netdev_vport_run (netdev-vport.c:376) ==2344== by 0x47F209: netdev_run (netdev.c:183) ==2344== by 0x404FC3: main (ovs-vswitchd.c:122) ==2344== ==2344== 576 bytes in 1 blocks are possibly lost in loss record 360 of 378 ==2344== at 0x4C2DB95: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==2344== by 0x4013504: allocate_dtv (dl-tls.c:322) ==2344== by 0x4013504: _dl_allocate_tls (dl-tls.c:544) ==2344== by 0x4E400D2: allocate_stack (allocatestack.c:588) ==2344== by 0x4E400D2: pthread_create@@GLIBC_2.2.5 (pthread_create.c:537) ==2344== by 0x5059068: __aio_create_helper_thread (aio_misc.h:59) ==2344== by 0x5059068: __aio_enqueue_request (aio_misc.c:431) ==2344== by 0x505968D: aio_write (aio_write.c:29) ==2344== by 0x50819A: async_append_write (async-append-aio.c:144) ==2344== by 0x4F3065: vlog_valist (vlog.c:1124) ==2344== by 0x4F28BE: vlog (vlog.c:1148) ==2344== by 0x40F9E8: bridge_run (bridge.c:3011) ==2344== by 0x404FB4: main (ovs-vswitchd.c:120) ==2344== ==2344== 576 bytes in 1 blocks are possibly lost in loss record 361 of 378 ==2344== at 0x4C2DB95: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==2344== by 0x4013504: allocate_dtv (dl-tls.c:322) ==2344== by 0x4013504: _dl_allocate_tls (dl-tls.c:544) ==2344== by 0x4E400D2: allocate_stack (allocatestack.c:588) ==2344== by 0x4E400D2: pthread_create@@GLIBC_2.2.5 (pthread_create.c:537) ==2344== by 0x4C4DDA: ovs_thread_create (ovs-thread.c:389) ==2344== by 0x4C33BE: ovsrcu_quiesced (ovs-rcu.c:111) ==2344== by 0x4E6F63: time_poll (timeval.c:295) ==2344== by 0x4D3B1B: poll_block (poll-loop.c:364) ==2344== by 0x43724E: udpif_upcall_handler (ofproto-dpif-upcall.c:725) ==2344== by 0x4C41C3: ovsthread_wrapper (ovs-thread.c:340) ==2344== by 0x4E3F6A9: start_thread (pthread_create.c:333) ==2344== by 0x566CE9C: clone (clone.S:109) ==2344== ==2344== 3,484 (144 direct, 3,340 indirect) bytes in 2 blocks are definitely lost in loss record 371 of 378 ==2344== at 0x4C2BBCF: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==2344== by 0x4EC244: xmalloc (util.c:112) ==2344== by 0x52CE3C: vconn_stream_new (vconn-stream.c:60) ==2344== by 0x52CF9D: pvconn_pstream_accept (vconn-stream.c:350) ==2344== by 0x4F0909: pvconn_accept (vconn.c:1263) ==2344== by 0x44756C: connmgr_run (connmgr.c:365) ==2344== by 0x41A0A5: ofproto_run (ofproto.c:1762) ==2344== by 0x408C53: bridge_run__ (bridge.c:2885) ==2344== by 0x40E513: bridge_run (bridge.c:2940) ==2344== by 0x404FB4: main (ovs-vswitchd.c:120) ==2344== ==2344== LEAK SUMMARY: ==2344== definitely lost: 144 bytes in 2 blocks ==2344== indirectly lost: 3,340 bytes in 10 blocks ==2344== possibly lost: 1,880 bytes in 8 blocks ==2344== still reachable: 163,193 bytes in 458 blocks ==2344== suppressed: 0 bytes in 0 blocks ==2344== Reachable blocks (those to which a pointer was found) are not shown. ==2344== To see them, rerun with: --leak-check=full --show-leak-kinds=all ==2344== ==2344== For counts of detected and suppressed errors, rerun with: -v ==2344== ERROR SUMMARY: 8 errors from 8 contexts (suppressed: 0 from 0) André Mantas <andremant...@gmail.com> escreveu no dia quarta, 9/03/2016 às 00:35: > You want config=0 mask=1, I believe. >> > > Oh, that was it. It worked as expected. > > The test was also successful. A snoop extract is below, but basically what > I've done is: send port mod to bring down port 2; create bundle with 2 > messages - port mod to bring up port 2 and packet out to port 2; host > connected to port 2 receives the packet out (confirmed with tcpdump on host > xterm). > > From Jarno's reply, I think the last problem to address is: "Group and > meter validation is part of the action validation for packet_out. While the > bundles can’t currently include group or meter mods, I’d like to see that > adding packet_out to a bundle does not unnecessarily complicate adding > group and meter mods to bundles." > > Not sure what to do about this one... > > -- > > snoop extract: > > OFPT_PORT_MOD (OF1.4) (xid=0x46): port: 2: addr:9e:15:f7:8d:6f:df > config: PORT_DOWN > mask: PORT_DOWN > advertise: UNCHANGED > OFPT_PORT_STATUS (OF1.4) (xid=0x0): MOD: 2(s1-eth2): addr:9e:15:f7:8d:6f:df > config: PORT_DOWN > state: LINK_DOWN > current: 10GB-FD COPPER > speed: 10000 Mbps now, 0 Mbps max > > OFPT_BUNDLE_CONTROL (OF1.4) (xid=0x57): > bundle_id=0xb type=OPEN_REQUEST flags=ordered > OFPT_BUNDLE_CONTROL (OF1.4) (xid=0x57): > bundle_id=0xb type=OPEN_REPLY flags=0 > OFPT_BUNDLE_ADD_MESSAGE (OF1.4) (xid=0x55): > bundle_id=0xb flags=ordered > OFPT_PORT_MOD (OF1.4) (xid=0x55): port: 2: addr:9e:15:f7:8d:6f:df > config: 0 > mask: PORT_DOWN > advertise: UNCHANGED > OFPT_BUNDLE_ADD_MESSAGE (OF1.4) (xid=0x56): > bundle_id=0xb flags=ordered > OFPT_PACKET_OUT (OF1.4) (xid=0x56): in_port=1 actions=output:2 data_len=20 > > vlan_tci=0x0000,dl_src=00:00:00:00:00:01,dl_dst=0a:ae:d4:f6:70:30,dl_type=0xffff > OFPT_BUNDLE_CONTROL (OF1.4) (xid=0x5a): > bundle_id=0xb type=CLOSE_REQUEST flags=ordered > OFPT_BUNDLE_CONTROL (OF1.4) (xid=0x5a): > bundle_id=0xb type=CLOSE_REPLY flags=0 > OFPT_BUNDLE_CONTROL (OF1.4) (xid=0x5b): > bundle_id=0xb type=COMMIT_REQUEST flags=ordered > OFPT_BUNDLE_CONTROL (OF1.4) (xid=0x5b): > bundle_id=0xb type=COMMIT_REPLY flags=0 > OFPT_PORT_STATUS (OF1.4) (xid=0x0): MOD: 2(s1-eth2): addr:9e:15:f7:8d:6f:df > config: 0 > state: 0 > current: 10GB-FD COPPER > speed: 10000 Mbps now, 0 Mbps max > _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
