[ovs-dev] [PATCH] ofproto-dpif : propagate may_enable flag as link aliveness

Ben Pfaff blp at ovn.org
Wed Mar 16 23:13:24 UTC 2016


OK, now I understand.

I see why the LIVE bit change gets sent when the port gets enabled as a
result of port carrier status going up or down.  It's because
ofproto-dpif will report the port as changed via port_poll(), and thus
ofproto_run() will pass it to process_port_change().  But the other
reasons why a port might become LIVE or not-LIVE, such as CFM or BFD or
LACP reporting a change in status, do not get reported via port_poll(),
and I suspect that these will thus not get reported through an
OFPT_PORT_STATUS message.  I don't think any of the existing tests check
this behavior, so adding a test that shows that (at least one of these)
works as expected would be reassuring.

Thanks,

Ben.

On Wed, Mar 16, 2016 at 10:06:44AM +0000, Zoltán Balogh wrote:
> Hi Ben,
> 
> Sorry, there was no question in my e-mail.
> 
> The thing is, that I sent a patch on 11th of February. Then you replied:
> "This seems like a good start but I don't see anything that generates 
> an OFPT_PORT_STATUS message when the LIVE bit gets set or unset"
> 
> So, I tried to explain how the OFPT_PORT_STATUS message will be generated after the LIVE bit is set/cleared. That was the purpose of the e-mail I sent on 1st of March.
> 
> Based on the explanation, is the patch acceptable? Is there something missing?
> 
> Best regards,
> Zoltán
> 
> -----Original Message-----
> From: Ben Pfaff [mailto:blp at ovn.org] 
> Sent: Friday, March 11, 2016 6:56 PM
> To: Zoltán Balogh
> Cc: dev at openvswitch.org
> Subject: Re: [ovs-dev] [PATCH] ofproto-dpif : propagate may_enable flag as link aliveness
> 
> Can you briefly state the question you're asking?  I didn't know how to respond to the previous email.
> 
> On Fri, Mar 11, 2016 at 10:42:26AM +0000, Zoltán Balogh wrote:
> > Hi,
> > 
> > Could someone please respond to this e-mail or give any feedback?
> > 
> > Thank you,
> > Zoltan
> > 
> > -----Original Message-----
> > From: dev [mailto:dev-bounces at openvswitch.org] On Behalf Of Zoltán 
> > Balogh
> > Sent: Tuesday, March 01, 2016 1:41 PM
> > To: Ben Pfaff
> > Cc: dev at openvswitch.org
> > Subject: Re: [ovs-dev] [PATCH] ofproto-dpif : propagate may_enable 
> > flag as link aliveness
> > 
> > Hi Ben,
> > 
> > This small patch modifies the port_run( ) function in ofproto_dpif. This function is invoked indirectly from ofproto_run() when ofproto_class->run() is called.
> > Sending of OFPT_PORT_STATUS message can be triggered by invoking update_port() in ofproto.
> > 
> > I tried to create a 'call tree' that shows where the LIVE bit is set/cleared and where OFPT_PORT_STATUS message can be sent to a controller. 
> > We start from the main loop, that invokes bridge_run(), xxx_run(), xxx_wait(), poll_block() and so on.
> > I used exclamation mark (!) to indicate where LIVE bit can be updated if needed and asterisk (*) to show where OFPT_PORT_STATUS can be sent via update_port().
> > So, here comes the tree. It looks quite ugly in my outlook. It can be copy-pasted to an editor with fixed width character set to get a better look.
> > 
> >    main()
> >     -> bridge_run()
> >          +-> bridge_run__()
> >          |     -> ofproto_run()
> >          |          +-> ofproto_class->run() 
> >  !       |          |     -> port_run() # updates OFPUTIL_PS_LIVE bit if needed !!!
> >          |          |
> >          |          +-> process_port_change()
> >          |          |     +-> reinit_ports()
> >  *       |          |     |     -> update_port()
> >          |          |     |
> >  *       |          |     +-> update_port()
> >          |          |
> >  *       |          +-> update_port()  
> >          |
> >          +-> bridge_reconfigure() 
> >                +-> bridge_delete_or_reconfigure_ports()
> >                |     -> ofproto_port_del()
> >  *             |          -> update_port()
> >                |
> >                +-> bridge_add_ports()
> >                |     -> bridge_add_ports__()
> >                |          -> iface_create()
> >                |               +-> iface_do_create()
> >                |               |     -> ofproto_port_add()
> >  *             |               |          -> update_port()
> >                |               |          
> >                |               +-> ofproto_port_add()
> >  *             |                     -> update_port()
> >                |                    
> >                +-> bridge_run__()
> >                      -> ofproto_run()
> >                           +-> ofproto_class->run() 
> >  !                        |     -> port_run() # updates OFPUTIL_PS_LIVE bit if needed !!!
> >                           |    
> >                           +-> process_port_change()
> >                           |     +-> reinit_ports()
> >  *                        |     |     -> update_port()
> >                           |     |
> >  *                        |     +-> update_port()
> >                           |
> >  *                        +-> update_port()
> > 
> > 
> > So, you can see that LIVE bit is updated before update_port() can be called in each cycle of the main loop. When update_port() is called, it verifies if any properties of the port has changed. If it has then calls ofport_modified() which sends port status message to the controller.
> > 
> > I did a test with ovs-testcontroller in verbose mode. I created a bridge, added a physical port to it, then changed the port's state to up. 
> > This is the controller ouput:
> > 
> > 2016-03-01T08:40:58Z|00050|vconn|DBG|tcp:192.168.2.145:42767: received: OFPT_PORT_STATUS (OF1.3) (xid=0x0): MOD: 1(eth3): addr:aa:55:aa:55:00:07
> >      config:     0
> >      state:      LINK_DOWN
> >      speed: 0 Mbps now, 0 Mbps max
> > 2016-03-01T08:40:58Z|00051|learning_switch|DBG|00006e81cdce5141: OpenFlow packet ignored: OFPT_PORT_STATUS (OF1.3) (xid=0x0): MOD: 1(eth3): addr:aa:55:aa:55:00:07
> >      config:     0
> >      state:      LINK_DOWN
> >      speed: 0 Mbps now, 0 Mbps max
> > 2016-03-01T08:40:58Z|00052|poll_loop|DBG|wakeup due to [POLLIN] on fd 
> > 8 (192.168.2.145:6653<->192.168.2.145:42767) at lib/stream-fd.c:155
> > 2016-03-01T08:40:58Z|00053|vconn|DBG|tcp:192.168.2.145:42767: received: OFPT_PORT_STATUS (OF1.3) (xid=0x0): MOD: 1(eth3): addr:aa:55:aa:55:00:07
> >      config:     0
> >      state:      LIVE
> >      speed: 0 Mbps now, 0 Mbps max
> > 2016-03-01T08:40:58Z|00054|learning_switch|DBG|00006e81cdce5141: OpenFlow packet ignored: OFPT_PORT_STATUS (OF1.3) (xid=0x0): MOD: 1(eth3): addr:aa:55:aa:55:00:07
> >      config:     0
> >      state:      LIVE
> >      speed: 0 Mbps now, 0 Mbps max
> > 
> > 
> > This is what ovs-ofctl shows before and after port state modification:
> > 
> > # ovs-ofctl show br
> > OFPT_FEATURES_REPLY (xid=0x2): dpid:00006e81cdce5141 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(eth3): addr:aa:55:aa:55:00:07
> >      config:     PORT_DOWN
> >      state:      LINK_DOWN
> >      speed: 0 Mbps now, 0 Mbps max
> >  LOCAL(br): addr:6e:81:cd:ce:51:41
> >      config:     PORT_DOWN
> >      state:      LINK_DOWN
> >      speed: 0 Mbps now, 0 Mbps max
> > OFPT_GET_CONFIG_REPLY (xid=0x4): frags=normal miss_send_len=0
> > 
> > # ovs-ofctl mod-port br eth3 up
> > 
> > # ovs-ofctl show br -OOpenFlow11
> > OFPT_FEATURES_REPLY (OF1.1) (xid=0x2): dpid:00006e81cdce5141 
> > n_tables:254, n_buffers:256
> > capabilities: FLOW_STATS TABLE_STATS PORT_STATS GROUP_STATS 
> > QUEUE_STATS ARP_MATCH_IP
> >  1(eth3): addr:aa:55:aa:55:00:07
> >      config:     0
> >      state:      LIVE
> >      speed: 0 Mbps now, 0 Mbps max
> >  LOCAL(br): addr:6e:81:cd:ce:51:41
> >      config:     PORT_DOWN
> >      state:      LINK_DOWN
> >      speed: 0 Mbps now, 0 Mbps max
> > OFPT_GET_CONFIG_REPLY (OF1.1) (xid=0x4): frags=normal miss_send_len=0
> > 
> > 
> > Well, the strange thing is that the vswitch sends two OFPT_PORT_STATUS messages. The first one indicates LINK_DOWN, the second one LIVE state. I'm not sure if this we should see.
> > 
> > Best regards,
> > Zoltan
> > 
> > -----Original Message-----
> > From: Ben Pfaff [mailto:blp at ovn.org]
> > Sent: Monday, February 29, 2016 7:28 PM
> > To: Zoltán Balogh
> > Cc: dev at openvswitch.org
> > Subject: Re: [ovs-dev] [PATCH] ofproto-dpif : propagate may_enable 
> > flag as link aliveness
> > 
> > On Thu, Feb 11, 2016 at 02:29:07PM +0000, Zoltán Balogh wrote:
> > > Hi,
> > > 
> > > The idea is to use OFPPS_LIVE bit to propagate link aliveness state towards the controller also when sending port status.
> > > The ofport->may_enable flag could be used for this purpose. I updated some unit tests according to the changes of ofproto-dpif.
> > > 
> > > Signed-off-by: Zoltán Balogh <zoltan.balogh at ericsson.com>
> > > Co-authored-by: László Sürü <laszlo.suru at ericsson.com>
> > > Signed-off-by: László Sürü <laszlo.suru at ericsson.com>
> > > Co-authored-by: Jan Scheurich <jan.scheurich at ericsson.com>
> > > Signed-off-by: Jan Scheurich <jan.scheurich at ericsson.com>
> > 
> > Thank you for working on this!
> > 
> > This seems like a good start but I don't see anything that generates an OFPT_PORT_STATUS message when the LIVE bit gets set or unset.  OpenFlow requires that behavior:
> > 
> >    All port state bits are read-only and cannot be changed by the
> >    controller. When the port flags are changed, the switch must send an
> >    OFPT_PORT_STATUS message to notify the controller of the change.
> > 
> > _______________________________________________
> > dev mailing list
> > dev at openvswitch.org
> > http://openvswitch.org/mailman/listinfo/dev



More information about the dev mailing list