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:[email protected]]
Sent: Monday, February 29, 2016 7:28 PM
To: Zoltán Balogh
Cc: [email protected]
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 <[email protected]>
> Co-authored-by: László Sürü <[email protected]>
> Signed-off-by: László Sürü <[email protected]>
> Co-authored-by: Jan Scheurich <[email protected]>
> Signed-off-by: Jan Scheurich <[email protected]>
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
[email protected]
http://openvswitch.org/mailman/listinfo/dev
